August 21, 2006
Quality FalsehoodsI grow weary of listening to managers talking about the need to "strike a balance" between quality and schedule. It's very unfashionable, and in some organisations it's career suicide, to argue with this point of view.
It's built upon two falsehoods that pervade the software industry at all levels:
1. You have to trade quality with productivity like they were on opposite ends of the same scale
2. That their organisation is in any immediate danger of taking quality too far
The first falsehood is built on the common wisdom that "quality costs", and that it takes longer to deliver something of a higher quality. And this is true - if you tackle quality after you've delivered it. Our view of the cost of quality is built largely on our experience of achieving it. Most projects deliver buggy software to a testing team, or to the customer, and then expend enormous amounts of effort to fix those bugs and bring the quality of the software up to an acceptable level. If the same bugs had been spotted when the developers were writing the code, or even earlier in the design or the requirements definition process, they would have been much easier to fix. Once the code's out there in the hands of the customer you have to go through the release process to get the fix back into the code. That's what costs the really big bucks!
If anything, industry data suggests that - to a point - productivity actually improves if you catch more bugs earlier in development. If you practice defect prevention, then higher quality and high productivity can be simultaneously achieved - to a point.
And it's that point that brings us to the second falsehood. It is completely true - born out by various studies - that you can take quality too far. It is equally true that you can have too much sex. I have yet to meet a software development team who were in any real danger of either.
The part of quality that costs dearly - apart from the code-and-fix approach I described above, which is by far the most expensive way to achieve quality - is the gap between perfect software and almost perfect software. Perfect software would cost so much to deliver that, to my knowledge, nobody has ever achieved it - not provably so, at any rate.
Almost perfect software, on the other hand, is entirely achievable. Indeed, almost perfect software can cost significantly less to deliver than average software. When I say "almost perfect", I mean in the ballpark of 1 bug found by the customer or testers for every 10,000 lines of code, as opposed to the average of 5-10 bugs per 1000 lines of code. In other words, 1% of the average bug count.
What sort of space age, Buck Rogers-style advanced practices could we use to achieve that sort of quality? Well, how about these for starters?
Posted 14 years, 4 months ago on August 21, 2006