Another interesting part of the story is the user element. The issue was most often triggered by fast, experienced technicians who were able to key commands more quickly than Therac engineers anticipated:
> After strenuous work, the physicist and operator were able to reproduce the error 54 message. They determined that speed in editing the data entry was a key factor in producing error 54.
Some years later, I interviewed at Knight Capital, just a couple of weeks before their blowup. (Dreadful interview at which I did dreadfully, being asked to write C _over the phone_ by a supremely uninterested engineer. Quite a red flag in retrospect.)
> Therac-25 is a great case study for software engineers too, recommend reading the Wikipedia article for anyone who hasn't, it's not too long.
I re-read the original paper every few months, more frequently if I'm working on Safety-of-Life-Critical equipment. Which, given my day job, means I'm re-reading it every couple of weeks at most.
> Previous models had hardware interlocks to prevent such faults, but the Therac-25 had removed them, depending instead on software checks for safety.
https://en.wikipedia.org/wiki/Therac-25
Another interesting part of the story is the user element. The issue was most often triggered by fast, experienced technicians who were able to key commands more quickly than Therac engineers anticipated:
> After strenuous work, the physicist and operator were able to reproduce the error 54 message. They determined that speed in editing the data entry was a key factor in producing error 54.