Car Crash Software

There’s no such thing as a free software lunch is there? No I’m not talking about freeware or even shareware, but quality. We’re told in every other walk of life that we are what we eat and you get what you pay for – so why shouldn’t we use the same mindset when we consider software development, implementation and usage?

You don’t have to Google too far with terms like “software quality” or even “software quality management” to find a list of vendors lining up to help you analyse your code and produce a less error prone final product.

We know that a Citroen 2-CV is probably the most dangerous car to be in if you plan to be involved in a car crash, so why don’t we adopt the same approach to software development? All too often we hear about users bouncing along inside unstable and robust applications likely to spew them out the moment they hit a bump in the road.

'

Image source: Wikimedia

Don’t get me wrong, I’m not about to list the purported benefits of xyz company’s “ground-breaking” new release assessment toolset, but the prevalence of these products seems only to be matched by the correspondingly high number of increasingly online applications (even at the forms-based end of the spectrum) that are simply, well, rubbish.

OK sorry, they suffer from bone-crushingly poor functionality given their importance. You might guess that I’m eluding to governmental or public sector originated applications that operate with all the power and effectiveness of a beaver with dentures.

The New Economist reported around a year ago that China’s explosive growth could harbour software failures that lead to, “A flaw in governance that creates frequent widespread social disorders that disrupt production economy-wide and discourage private investment. This situation is similar to a car crash that resulted from a fight among the people inside the speeding car.”

Perhaps I’m not alone in drawing this analogy then?

The very fact that there exists a layer of software application development specifically tasked with quality of release must surely draw us to ask more questions as to why it needs an additional layer or support. The responsibility for this role typically falls to ‘release managers’ and/or ‘configuration managers’ who themselves are usually relying on purpose-built software tools to help steer the deployment out a head on car crash and at best get the passengers through with a mild case of trauma and whiplash. OK, it’s not quite that bad – but you get this gist of what I am saying here I’m sure.

It may be the case that critical data from a multiplicity of sources needs to be combined and brought into concert to make the final application work properly – and that this is no small task. But does this give us an excuse for car crash software? Surely not?

According to Forrester Research, Inc., “Software has become not just employee-facing, but also partner-facing and even customer-facing. There is far less room for error in such applications or in any of the applications with which they integrate. If you nail the release on the first try, you avoid the outrageous expense of fixing problems in production, and you can devote those funds to delivering new business functions.” Best Practices In Release Management, Forrester Research, Inc., December 2007.

Giving them their due, I was prompted to start talking about this subject as a result of looking at a company in this area – namely, Coverity. The company’s CTO Ben Chelf has been quoted as saying that areas such as code complexity, pace of change and constrained resources form the real speed bumps and potholes in the software deployment road trip today.

Although Coverity has sponsored an admirably investigative survey with IDC available on its web site to examine the problems, the results are nothing that new. Increasing complexity felt by programmers, debugging problems, geographically distributed teams, outsourcing, legacy code – you name it, it’s in there.

More interesting is the prioritisation process the company prescribes for repairing code branches that pose the greatest risk of failure. Coverity's answer is to provide intelligence about key readiness factors such as code complexity, violation of best practices, architectural integrity, interdependencies and test coverage.

Buy a Citreon 2CV and you better hope you don’t get into a car crash. Buy a Range Rover and you can probably bounce along as fast as you like, but can you afford it in the first place as it’s a pricey motor?

When it comes to software – perhaps we should all be driving the competitively priced ‘surprisingly spacious’ family saloon. Or would that be just boring?