Studies suggest that typical code gets shipped with 0.5 to 1% defectrate. That is, the code in a 100KLOC product probably has 500 to 1000bugs. Yes, some organizations do very much better, but the norm is justnot acceptable.
There are many reasons for poor quality. One is managementexpectations. Software engineering is viewed as an intrinsicallychaotic process with unpredictable and non-repeatable results. The bossand sales department are so exhausted by the development process thatwhen the product finally appears they're happy to ship, no matter whatproblems still lurk.
Software engineering is indeed hard. But it doesn't have to beeither chaotic or unpredictable. If management doesn't hold engineersto high standards, if they don't routinely expect products to be donecorrectly, odds are they won't.
Engineers should be expected to deliver high quality, well-tested,maintainable code.
The corollary, of course, is that engineers should expect adequateresources from management, be they personal, tools, requirements andtime.
Users of the SPARK language, forinstance, have reported incredibly low bug rates, in some cases zero ondelivery of a product. That's due to several reasons including the useof a safe language (it's a subset of Ada) with tools that do formalproof checks against annotations provide in the comments.
Those tools are important, but success in SPARK comes from anexpectation that developers will use them correctly and all of thetime. Shortcuts aren't allowed. There are no exceptions. Cdevelopers can benefit from the same philosophy.
Yet in too many outfits bugs are considered normal.
Perfection is impossible in any human endeavor, so bugs will occur.But this is the only industry on the planet where companies can deliverproducts full of known defects and not get sued. Someday no one willsmoke and all of the asbestos will be buried. Who do you think thelawyers will go after?
Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systems and helpscompanies with their embedded challenges. Contact him at . His website is .