what have we Learned about
Upon closer examination, everything old appears
to be new again in the realm of software engineering.
In Late 2010, a New York Times headline attracted my atten- tion: “A Pinpoint Beam Strays Invisibly, Harming Instead of Healing—A Radiation Setting
Is Wrong, and Patients are Harmed.”a
I did not immediately learn the cause
of the New York Times-reported incident, particularly if the cause was
software-related, but it sure seemed
a lot like the Therac- 25 story of the
mid-1980s. 2 The Therac- 25 was an
earlier medical device involved in several accidents where some patients
were given fatal instead of therapeutic doses of radiation. I have since
learned the problem reported in the
Times involved passing information
among three incompatible computers. 3 We apparently never learn.
The real message of the Therac- 25
incidents was not that there was a soft-
ware bug, but that software engineers
missed a key engineering principle in
designing that device. Any competent
designer should be able to build soft-
ware that detects a failure and either
corrects it or responds in a safe man-
ner. The problem with the Therac- 25
was that a single error was compound-
ed with a second error, and the device
was not designed to handle multiple
points of failure. Hardware engineers
know how to build using multiple fail-
rect” from the earlier Ariane 4 rocket
were part of the problem.
a New York Times(Dec. 28,2010),A1;http://www.
ure modes, something that was new to
most software designers.
Lesson Learned and unlearned
The messages learned from such examples as these are critical for producing quality software. Software is a
critical component of just about every
device sold today. Even less safety-crit-ical software has problems. The computer I am using to write this column
illustration by andriJ borys associates