In the mid-1980s, a state-of-the-art medical marvel promised to cure cancer with pinpoint precision. It was hailed as a triumph of modern technology, a machine that would save countless lives. Instead, it became the centerpiece of one of the most chilling mysteries in the history of software engineering—a silent, invisible killer that could not be reasoned with, bargained with, or stopped.
When we put absolute, unquestioning faith in our creations, the results can be catastrophic. The story of the Therac-25 is a dark, blood-stained chapter in medical history, proving that sometimes, the most dangerous ghost in the machine is the hubris of the humans who built it.
A Silent, Searing Shock
Between 1985 and 1987, a disturbing pattern began to emerge in cancer treatment centers from Tyler, Texas, to Yakima, Washington. Patients coming in for routine radiation therapy were experiencing something impossible.
A typical therapeutic dose of radiation is around 200 rads. It is designed to be completely painless, quietly targeting tumors while leaving the patient relatively comfortable. But several patients treated by the Therac-25 reported feeling an intense, burning heat. Some described it as a “silent shock” vibrating violently through their bodies.
When operators rushed into the treatment rooms, they found their patients in sheer agony. Yet, the computer screens on the operators’ VT100 terminals insisted everything was perfectly fine. The machine had simply paused. There were no alarms, no flashing red lights, no indications of a catastrophic failure.
In the days and weeks that followed, these patients developed severe, unexplainable radiation burns. Tissues became necrotic. Tragically, several of these patients died agonizing deaths. The hospitals were baffled. How could a state-of-the-art, computer-controlled machine, built jointly by Atomic Energy of Canada Limited (AECL) and the French company CGR, be doing this?
Trusting the Code, Scrapping the Hardware
To understand the disaster, you have to look at the Therac-25’s older siblings: the Therac-6 and the Therac-20.
These earlier machines were marvels of their time, but they had a built-in safety net. They utilized physical hardware interlocks to prevent accidental radiation overdoses. If the computer glitched and tried to do something dangerous, a literal, physical piece of metal or a hardwired circuit would stop the machine dead in its tracks.
But the 1980s was the dawn of the software revolution. Hardware was seen as clunky, expensive, and old-school. Software was elegant. It was the future. So, when designing the Therac-25, engineers made a fateful decision: they removed the physical safety locks. They believed their code was flawless, relying entirely on software to keep the patients safe.
They were dead wrong.
The Eight-Second Trap
The Therac-25 was a dual-mode machine. It could shoot a low-energy electron beam directly into the patient, or it could shoot a massive, high-energy electron beam into a heavy metal target, which would convert the energy into X-rays.
The first deadly flaw lurking in the code was what programmers call a “race condition.”
Imagine an operator sitting at the terminal. They are highly experienced, typing at lightning speed. They accidentally set the machine to X-ray mode, realize their mistake, hit the up arrow, and change it to Electron mode. If they made this correction within a brief, eight-second window while the machine’s massive magnets were still swinging into place, the software completely lost its mind.
The computer would register the setup for the high-energy beam, but it would fail to drop the heavy metal X-ray target into the path of the beam.
When the operator hit “fire,” the machine didn’t deliver a safe 200 rads. It blasted the patient with a raw, unshielded, high-intensity electron beam estimated at an unfathomable 15,000 to 20,000 rads. It was a lethal, invisible lightning bolt.
Malfunction 54 and the Arithmetic of Death
If the race condition wasn’t terrifying enough, there was a second, equally lethal bug: an arithmetic overflow.
Deep in the machine’s code was a one-byte counter variable. Its job was to verify that the machine’s physical components were properly positioned before allowing the beam to fire. Because it was one byte, it could only count from 0 to 255.
If the machine was in a specific setup phase, this counter would continuously increment. 1… 2… 3… all the way to 255. But what happens when you add 1 to 255 in a one-byte system? It doesn’t go to 256. It rolls over back to 0.
If an operator happened to press the “Set” button at the exact fraction of a second that the counter rolled over to 0, the software momentarily believed everything was perfectly aligned—even if it wasn’t. The safety checks were bypassed, and the deadly beam fired.
To make matters worse, the user interface was a masterclass in terrible design. The machine frequently threw cryptic errors like “Malfunction 54” or “Treatment Pause.” Because these vague errors popped up dozens of times a day without any actual danger, operators were conditioned to just press ‘P’ to proceed. They had no idea that “Malfunction 54” actually meant they were administering a lethal overdose.
Hubris and the Hard Truth
When hospitals first reported the severe burns, AECL’s response was chillingly arrogant. They dismissed the reports, claiming that the machine was physically incapable of delivering an overdose. They blamed operator error. They trusted the machine over the humans bleeding in front of them.
It took the relentless work of computer scientist Nancy Leveson, whose landmark paper exposed the systemic failures of the Therac-25, to finally bring the truth to light. Her investigation proved that the software was riddled with fatal flaws, and the corporate culture that produced it was dangerously negligent.
The Therac-25 tragedy permanently changed the world of software engineering. It became the ultimate cautionary tale, establishing a golden rule that is still taught to programmers today: safety-critical systems must never rely solely on software interlocks. It birthed the modern standards of rigorous independent code reviews, defensive programming, and human-centric UI design.
We learned the hard way that while software can perform miracles, it is still written by fallible humans. And when we forget that, the ghost in the machine can turn deadly.
