Therac-25
loreprogramminggovernance & risk
The radiation-therapy machine whose software race conditions delivered massive overdoses in the 1980s, the founding case study of software safety.
Between 1985 and 1987 the Therac-25 gave at least six patients radiation overdoses, some fatal, after its makers removed hardware interlocks and trusted software that harbored race conditions triggered by fast operator input. Nancy Leveson and Clark Turner's investigation became required reading: the failures were systemic, not a single bug, and reused code carried assumptions the new machine no longer honored. Every 'the software will catch it' argument since has had to answer to Therac-25.
Between June 1985 and January 1987 the Therac-25 radiation therapy machine massively overdosed six patients. Three died. The cause was a race condition: if an operator edited the treatment parameters quickly enough during an eight-second window, the magnets that shaped the beam were never repositioned while the interface reported the corrected mode, so the machine fired an unmodulated electron beam at a patient set up for something far gentler.
The decision underneath the bug is the part that matters. Earlier models carried hardware interlocks that physically prevented the beam firing in an unsafe configuration, and the Therac-25 removed them in favour of software checks. The same defect had existed in the previous model's code for years, silently caught every time by the hardware nobody thought was doing anything.
What the case established is that software in a safety-critical role is a different discipline rather than a cheaper implementation of the same one. Nancy Leveson's analysis is still taught because the failures were organizational as much as technical: overconfidence in reused code, no independent review, reports of injury dismissed as impossible because the software said so. Every argument for defence in depth in physical systems traces back through this.