a little madness

Bertrand Meyer (of Eiffel fame) posted recently on The one sure way to advance software engineering. Meyer’s thesis is that by thorough examination of past software failures, we could learn from those mistakes. This is true enough, but then Meyer goes on to suggest that we:

… pass a law that requires extensive professional analysis of any large software failure. … The law would have to define what constitutes a “large” failure; for example it could be any failure that may be software-related and has resulted in loss either of human life or of property beyond a certain threshold, say $50 million.

Leaving the issue of making this law aside, the fact that this would only apply to such “large” failures necessarily marginalises the utility of the analysis. The truth is that such projects are a small minority of overall software development. Lessons learned from projects where such a large failure is a possibility – particularly where safety is involved – may not apply to the vast majority of software development. This doesn’t make the suggestion useless, but it makes it unlikely to have a significant impact on software engineering as a whole.

Meyer’s post also triggered a resurgence of the age-old debate of whether software development is worthy of the “engineering” label. With bugs so prevalent in mainstream software, people (mostly developers themselves) question the professionalism of our industry. This reminds of the EclipseCon 2007 keynote by Robert Lefkowitz, which draws attention to the EULA used by Microsoft. In particular, Lefkowitz asks why Microsoft¹ should be allowed to disclaim all warranty and liability for damages incurred by the use of their software. Why doesn’t the law protect the market from buggy software?

Source: Kirkam Motorsports

The answer is simple: we aren’t all Larry Ellison, and cost does matter to the rest of us. The market might wish for higher-quality software, but to make this law would lead directly to a huge increase in the cost of software development. Consider the canonical example of software that is made to the highest standard: the code that controls space shuttles. The linked article quotes a figure of $35 million per year to develop and maintain 420,000 lines of code². Consider that Microsoft Windows is about two orders of magnitude larger than this, and that the complexity of a code base grows faster than linearly with respect to the number of lines of code. The cost of bringing Windows up to shuttle-quality is unbearable, even for an 800-pound gorilla.

Does the fact that we need to trade off quality versus cost mean that development should not be considered as engineering? On the contrary, I believe that making sensible trade-offs is one of the very things that defines engineering. Engineering operates in the real world of scarce resources and budget constraints, and great engineers how to strike the right balance. They can also do more with less, by caring about their work and always seeking efficiency. I’ve met and worked with many developers that exhibit these traits, so I believe that there is hope for us yet.

—
¹ I presume as a proxy for the whole industry.
² Lines of code may be a weak metric, but I don’t think it detracts from the main point.

Liked this post? Share it!

This entry was posted on Thursday, September 17th, 2009 at 3:45 am and is filed under Opinion, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.