Fatal Error

As a programmer, this news terrifies me: software glitches in medical linear accelerators caused the deaths of two cancer patients in New York. Unstable software controlling potentially deadly machines is an intensely hazardous mix. These accidents should be of grave concern to the entire software industry—we can be coldly unconcerned when we hear that a buffer overflow attack caused the leak of millions of passwords, but a death is always a more persuasive motivation for improved safety.

In one of the cases mentioned in the Times article, a series of computer crashes apparently failed to save the treatment files for a patient. Between software crashes, the machine operators did not realize that the instructions for the machine were not saved, leaving an aperture wide open for the full dose of radiation.

Unfortunately, this sort of accident is nothing new. Radiation therapy machines have killed people before—the Therac-25 comes to mind—and it’s frightening that the industry has still not come up with stricter safety and security requirements.

The truth is that writing software is hard. I certainly don’t envy the programmers writing software for any system where lives are on the line, but the inevitability of software bugs is a feeble excuse for faulty software. Even though arithmetic overflows and race conditions are notoriously hard to spot, we have tools to minimize them. Static analysis can identify many potential errors before the code is even run. Code written in functional languages can be proved mathematically to be correct.

Accountability, however, is the bottom line. A structural engineer who signs off on a building that collapses after construction will have a difficult time repairing his damaged reputation. If programmers faced similar consequences when lives hung in the balance, there’d be more encouragement to write safe and stable software.