Second-Class Software Quality in Major IT Projects

Many years ago, computer author Gerald Weinberg famously said that if builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

I’d like to say that efforts at software quality have improved since he first said that, and in many organizations they have. On the other hand, within the past 10 years I have reviewed more than a few troubled or failed software projects in which software quality was treated more as an afterthought than as an essential aspect of IT project management. You would think, given the dollar amounts at stake in these projects – ranging anywhere from a few million dollars to nearly half a billion dollars – that every effort would be made to ensure the quality of the software. You would be wrong.

My own observation, after nearly 35 years in IT, is that far too often upper management thinks of software quality assurance (SQA or QA) as that annoying (and hopefully brief) phase of testing between the end of coding and actual deployment of the application. As a result, the QA group – assuming there is one – is usually given too little time and money to carry out their tasks.

Beyond that, upper management and, quite frankly, IT management tend to define QA as being simply “testing”. As such, they often view QA as just bringing in some warm bodies to run some test scripts once the coding is all finished. There is actually far more to QA than just testing, and there is far more to testing than just running test scripts.

Back in 1975, Fred Brooks stated that a major software project should plan on spending 1/3 of its time in analysis, 1/6 of its time in coding, and ½ of its time in testing – percentages that would give most managers a heart attack. But Brooks notes that whether or not you plan to spend ½ of our time in testing, in the end you will anyway. I’ve seen that borne out in a number of major IT projects – projects that went months or years late because the organization was unwilling to plan and pay for proper QA up front.

If the organizational challenges to QA were simply lack of time and money, then they could be readily solved by simply allocating more time and money. However, there is a second, more intractable issue. Put simply, an IT engineer who works in QA has less professional status than one who works in actual coding. The old IT joke is that you conjugate the verb “to program” thusly: “I architect, you code, he or she tests.”