"Snefru's Bent Pyramid in Dahshur" by Ivrienen at en.wikipedia. Licensed under CC BY 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Snefru%27s_Bent_Pyramid_in_Dahshur.jpg#mediaviewer/File:Snefru%27s_Bent_Pyramid_in_Dahshur.jpg
“Snefru’s Bent Pyramid in Dahshur” by Ivrienen at en.wikipedia.
This is the ‘Bent Pyramid‘ – a 4600 year old monument to engineering failure. From the base, the sides set off at an alarmingly steep 54-degree incline, before abruptly switching to a gentler 43 degree slope about halfway up. It’s believed that the design was altered during construction following the catastrophic collapse of the Meidum Pyramid — another steep-sided pyramid — about 60 kilometres to the south. Of course, it’s hard to blame the ancient pyramid builders. They were effectively inventing engineering as much as they were learning it. One thing hasn’t changed since that time: when structural engineers mess up, people get hurt. We can’t know for sure, but it seems unlikely that the Meidum collapse could take place without a human cost. By comparison, ‘software engineer’ can seem like a fluffier flavor of the engineering sciences. A mistake might prevent a user from accessing their account or entering information, but it surely isn’t life threatening? No-one gets hurt, right? Or that’s what we think. The truth is, every year our systems — from power to traffic to agriculture to emergency services — become more dependent on us all creating high quality software to support them. And when we fail — like those ancient Egyptians — people can actually get hurt. Surprisingly, as the sad case of the Therac-25
shows us, this isn’t even a 21st century problem.

Software Can Kill

By the late 1970’s, Atomic Energy of Canada Limited (AECL) had earned a good reputation for building radiation therapy machines. These machines used targeted electron beams to attack tumours in patients. Make no mistake, these beams are high-intensity and potentially lethal. AECL had previously enjoyed great success with their Therac-6 and Therac-20 models. These units needed to be manually controlled by a trained operator, and used mechanical switches and hard-wired circuits to ensure high levels of safety. The Therac-25 was to be their ‘dream-machine’. The Therac-25 machine Smaller and cheaper, yet more efficient than its predecessors, the new machine incorporated two different beams technologies — an x-ray and a high-energy electron. The different beams allowed operators to target tumours at different depths without damaging nearby healthy tissue. The Therac-25 was both ambitious and sophisticated — and for the first time all this hardware was controlled by a software layer. Unfortunately, though AECL’s intentions were good, their software design was tragically bad, incorporating a series of horrendous design flaws. Later investigations carefully documented these flaws and they still make chilling reading today. In one instance, during a treatment one machine continuously shut itself down reporting a cryptic ‘H-tilt‘ and ‘no dose
‘ error message each time. The baffled operator attempted to deliver the treatment six times before giving up. It was only later that it was determined that the machine had indeed delivered the full dose every time — a catastrophic overdose. From its launch in 1982 till its withdrawal in 1986, six patients received ultimately fatal injuries from Therac-25 treatments. It’s particularly horrendous when you consider that these poor people were already sick. Today AECL exists not as a company, but as a tragic textbook example to us all of how poorly-designed and untested software can impact lives. To this day, the Therac-25 tragedy still informs a lot of the ideas we have on systems design and safety testing.
Ancient pharaoh statue
photo: kmf164
Even if you’re a front-end designer, and don’t consider yourself a ‘serious engineer’, Therac-25 has important lessons. While some flaws were caused by poorly coded processes, at least as much damage was caused by inadequate documentation, useless feedback and incomprehensible errors messages. These are areas that everyone — designers, coders, managers, UX people and testers — should have influence over. Looking back at those ancient egyptians, it’s clear that they learned from their early mistakes and went on to build some of the most breathtaking structures that have ever existed. Software engineering is still a comparatively young field — let’s hope we’ve already built our Bent Pyramids. Originally published in the January 29th issue of the SitePoint Design Newsletter. Subscribe here.

Frequently Asked Questions about Therac-25

What was the main cause of the Therac-25 accidents?

The primary cause of the Therac-25 accidents was a combination of software bugs and inadequate safety mechanisms. The software was designed in such a way that it could override the hardware safety mechanisms, leading to the delivery of lethal doses of radiation. The lack of independent safety checks and the reliance on software for safety functions were significant contributing factors.

How many people were affected by the Therac-25 accidents?

Six known accidents involved the Therac-25, resulting in patients receiving massive overdoses of radiation. These accidents led to severe injuries and the deaths of at least three people. However, the exact number of people affected may be higher as some cases might not have been reported or recognized.

What were the consequences for the manufacturer of Therac-25?

The manufacturer, Atomic Energy of Canada Limited (AECL), faced significant backlash following the accidents. They were criticized for their slow response, lack of transparency, and failure to take immediate corrective action. The accidents led to a loss of trust in the company and significant legal and financial implications.

How did the Therac-25 accidents impact the medical and software industries?

The Therac-25 accidents had a profound impact on both the medical and software industries. They highlighted the potential dangers of relying heavily on software for safety-critical functions. As a result, they led to increased scrutiny and regulation of medical devices and a greater emphasis on software safety and reliability.

What measures were taken to prevent similar incidents in the future?

In response to the Therac-25 accidents, several measures were taken to improve the safety of medical devices. These included stricter regulations, more rigorous testing and validation of software, and the implementation of independent safety systems. The accidents also led to a greater emphasis on training for operators of such devices.

What were the design flaws in the Therac-25?

The Therac-25 had several design flaws, including a reliance on software for safety functions, a lack of independent safety checks, and the ability for the software to override hardware safety mechanisms. Additionally, the user interface did not provide clear and immediate feedback, which could have alerted operators to problems.

How did the Therac-25 accidents come to light?

The Therac-25 accidents came to light after several patients reported symptoms of radiation overexposure following their treatments. Investigations into these incidents revealed that the patients had received massive overdoses of radiation due to errors in the Therac-25 machine.

What lessons were learned from the Therac-25 accidents?

The Therac-25 accidents highlighted the importance of rigorous testing and validation of software, especially in safety-critical systems. They also underscored the need for independent safety checks and clear, immediate feedback from user interfaces. Additionally, they demonstrated the potential dangers of relying too heavily on software for safety functions.

What was the response of the medical community to the Therac-25 accidents?

The medical community responded to the Therac-25 accidents with shock and concern. The incidents led to increased scrutiny of medical devices and a greater emphasis on safety. Many hospitals and clinics reviewed their procedures and implemented additional safety measures to prevent similar incidents.

How did the Therac-25 accidents influence the development of software safety standards?

The Therac-25 accidents played a significant role in shaping software safety standards. They highlighted the need for rigorous testing and validation of software, especially in safety-critical systems. As a result, they led to the development of stricter regulations and standards for software safety.

Alex WalkerAlex Walker
View Author

Alex has been doing cruel and unusual things to CSS since 2001. He is the lead front-end design and dev for SitePoint and one-time SitePoint's Design and UX editor with over 150+ newsletter written. Co-author of The Principles of Beautiful Web Design. Now Alex is involved in the planning, development, production, and marketing of a huge range of printed and online products and references. He has designed over 60+ of SitePoint's book covers.

AECLAlexWsoftware engineeringTestingTherac-25
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week