There are many reasons for poor quality. One is management expectations. Software engineering is viewed as an intrinsically chaotic process with unpredictable and non-repeatable results. The boss and sales department are so exhausted by the development process that when the product finally appears they're happy to ship, no matter what problems still lurk.

Software engineering is indeed hard. But it doesn't have to be either chaotic or unpredictable. If management doesn't hold engineers to high standards, if they don't routinely expect products to be done correctly, 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 adequate resources from management, be they personal, tools, requirements and time.

Users of the SPARK language, for instance, have reported incredibly low bug rates, in some cases zero on delivery of a product. That's due to several reasons including the use of a safe language (it's a subset of Ada) with tools that do formal proof checks against annotations provide in the comments.

Those tools are important, but success in SPARK comes from an expectation that developers will use them correctly and all of the time. Shortcuts aren't allowed. There are no exceptions. C developers 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 deliver products full of known defects and not get sued. Someday no one will smoke and all of the asbestos will be buried. Who do you think the lawyers will go after?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.