Failure Is Not An Option

A recent article in SD Times(1) well highlighted some alarming software project failures. For example, among the 68% of "failures" was the problem with the laser-guided missile having software not designed for battery hot-swapping and producing the interesting result of resetting the coordinates to origin. Oops! This failure would give new meaning to your boss going ballistic on discovering the error! The Standish Group's 2009 "Chaos" study also included in the 68%, failures due to late completion, over-budget completion or simply non-completion. Completion doesn't always mean success of course. Only after spending $100 million did the FBI discover that the Virtual Case File system was "... not something that we want." How can this happen? Better to ask, how does this continue to happen? If you had Microsoft's money and experience, how could you fail to produce perfect software? Well, they did fail fantastically with Vista which Scott Rosenberg explains was due to "conflicting ambitions and too few resource constraints" leading to an "organizational breakdown". Well that is enormously helpful in explaining my near breakdown trying to tame the Universal Account Control (UAC) which repeatedly insisted I was not to be trusted using my own computer.

Frustration as an end product is certainly more desirable than loss of life under an X-Ray machine or crashing an Airbus because the computer simply 'wouldn't let go of the controls'. I imagine the software developers felt they could stop the pilot and co-pilot from fighting over who did what if they just let the computer decide. Well, the computer couldn’t rise above the occasion and crashed the trees into the plane – according to its flighty calculations.

So far to go. "There are two ways to write error-free programs; only the third one works" said one expert(2). But we will continue to rise to the challenge of taming complex problems into elegant software solutions. The amazing examples David Worthington gives us should definitely caution us to work with care when using our wide sweep of imaginative powers coupled with mathematical precision to produce the best software we can.

(1) David Worthington, Software Development Times, November 1, 2009. www.sdtimes.com
(2) From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams in Programming", by Alan J. Perlis of Yale