The Therac-25 Incident (2021)

> software quality doesn't appear because you have good developers. It's the end result of a process, and that process informs both your software development practices, but also your testing. Your management. Even your sales and servicing. If you only take one thing away from this article, it should be this one! The Therac-25 incident is a horrifying and important part of software history, it's really easy to think type-systems, unit-testing and defensive-coding can solve all software problems. They definitely…

The featured comment is great, for those who missed it: I am a physician who did a computer science degree before medical school. I frequently use the Therac-25 incident as an example of why we need dual experts who are trained in both fields. I must add two small points to this fantastic summary. 1. The shadow of the Therac-25 is much longer than those who remember it. In my opinion, this incident set medical informatics back 20 years. Throughout…

I first learned of this incident in the early 2000s from a computer book about how to code UML State charts in C/C++ [1]. It included a CD-ROM with a library that implemented a rather clever way of maintaining state using the call stack. Unfortunately, the naive software fix for the Therac-25 is to add a flag (which is additional state) to the system which is to add complexity to the system. [1] https://www.state-machine.com/doc/PSiCC.pdf