We know our users want high quality software. We know our software, in general, stinks. What’s our problem?
We Claim to value quality
We say we value quality highly. Who will admit to wanting poor quality?
But we value almost everything else more
Who would design a lawn mower without a “dead-man’s” switch – the kind of thing where you have to keep pressing it to keep the lawn mower running; if anything goes wrong, the mower stops and nothing bad is likely to happen. But when software is involved … watch out!
There was a case this year of a person being crushed by an elevator.
The elevator, of course, was controlled by software. The software was written to respond to someone pressing a button to go to a floor, but not to make sure all systems were “go” before sending the signal to start moving. So, while the person was entering the elevator, the bad software started the “go to a floor sequence” without proper checking, and before anyone could react …
The stories at the time blamed the workers for failing to follow procedures. They probably didn’t. But why would software be written to even make this outcome possible???
Why does bad software happen?
Poor quality doesn’t need to be achieved – poor quality happens all on its own, without our having to do anything to make it happen! That’s why it’s so wide-spread! It’s just like when you’re writing natural language. Who thinks that the text of Twelfth Night that we read today was Shakespeare’s first draft?
Beyond the fact that high quality is something that must be achieved, here are the most basic reasons it is so rare:
- High Quality is unrewarding
The typical incentive structure for quality practically guarantees we won’t get much of it. High-quality software doesn’t get kudos – it’s expected. You may get slapped if the quality is stupendously bad. When it’s adequate or better? Yawn.
- Our focus is wrong
There is a long tradition of attempts to improve quality in software. Think test-driven development. Think about all the people preaching how “quality” is different than (and better than) “mere testing.” Decades of effort have resulted in little to no progress, except for spending more time and money. Chief among the errors in focus is the way we put our effort into assuring the quality of the new stuff we’re building instead of what customers mostly care about, which is whether the old stuff continues to work.
- Bad quality is a side-effect of poor development methods
If you are using project-management-style techniques to build software, achieving high quality is nearly impossible. At least if you’re using “grow the baby” techniques, it’s possible to maintain a reasonable level of quality.
Conclusion
Most software stinks. We know it. We give lip service to quality, but little more. When we apply standard methods to achieve higher quality, we are rarely rewarded for our efforts. QA is one of the lowest status jobs in software, and most likely to be cut when there is pressure of any kind.
Given the situation, we get exactly the quality we should expect.
Comments