The end of summer for me marks the beginning of another academic year. This semester offers another opportunity to teach software engineering to undergraduates. It also continues to present a challenge about discussing software quality.
I employ a number of case studies in my teaching. Some are extended treatments of classics such as Therac 25, the London Ambulance Service, and Ariane 5. Others are brief, very topical instances ripped from the headlines. As I have observed before, it is certainly dramatic to demonstrate quality concerns by means of counterexamples, of spectacular failures caused by oversights or human perversity. I quite naturally draw upon my own personal war stories to illustrate how NOT to perform requirements review or configuration management or test planning.
It seems far easier to use these failures than to find substantial successes. Often the success stories lack the flair for the dramatic. Sometimes they are almost unnoticed. Its somewhat like the Sherlock Holmes story where the famous detective notes the curious behavior of the dog in the nightthe lack of any barking. The lack of failure might be a subtle clue, but is it capable of illustrating good software quality practices?
After reading articles with titles like Why Software Is So Bad, (Technology Review July/August 2002) I want to write Why Software Has Been So Good for Us. But what would I say?
In one sense, most of the failures represent activities where we had come to expect or rely on software successes. We wouldnt be trying to perform such demanding rocketry or emergency response or medical procedures without having computerized systems. The abnormality of the failure is that the successes are far more common. In effect, we have taken for granted accomplishments that are only possible because of the successful operation of software-based systems.
Our lives are safer (automobile antilock brakes), more comfortable (home and office environmental controls), and enriched (graphic arts, music) thanks to advances in computer technology. We can communicate, learn, relax, and explore in ways undreamed of by earlier generations. Somebodymany somebodiesmust be doing something right, must have repeatedly done things well enough to bring about such technological advances.
How can such successes be unearthed and publicized? Why cant the success stories become a part of our professional folklore?
Perhaps compare-and-contrast would be an effective technique. I recall that IBM was hugely embarrassed by shortcomings in its computerized scoring systems at the 1996 Atlanta Olympics. I dont know that I saw any publicity about such systems at the next games in 2000. Was this a dog that didnt bark in the night? Could the absence of publicity have come from an absence of failurein other words, was this a success story that is waiting to be told?
The recent midair collision of jets under Swiss air traffic control yielded up the interesting fact that this was the first such collision involving commercial jets in more than 25 years. Is this a success story for both ground and airborne (collision avoidance) software?
I would welcome other nominees for a Software Hall of Fame. Dont just limit your examples to functionality, either. How about grand counterexamples to the Denver airport baggage handling system? There are certainly major systems that were acceptably completed on schedule and within budget.
Lets try to assemble these stories for the next generation of software developers and quality practitioners. Lets have some case studies that stress success and not failure.
As the journal completes its fourth year of publication, I will take the opportunity to again state my appreciation for the fine work done by our staff at ASQ headquarters and by the many volunteers around the world. I am especially thankful for the long history of support by Deependra Moitra, who is leaving SQPs Editorial Board, as well as his duties as regional councilor for ASQs largest geographical subdivision, the International Region. Best wishes to Deependra, as well as a number of reviewers and friends whose career trajectories are taking them into other professional concerns.
No one, as a citizen of the world today, can be far removed from concern about the quality of software-dependent systems. Those of us who daily work directly on applying quality principles to the development and use of software may be a bit more sensitivewe may know somewhat more of both the promise and the potential downside of entrusting more of our lives to computerized systems. It is our challenge and our opportunity to help fulfill the promise while helping avoid the downside.