5 ms·

Hands-on Assignment – Therac-25 (2007)

106 points by luu 2y ago

doormatt 2y ago
http://web.mit.edu/6.033/2007/wwwdocs/assignments/handson-liability.html http://web.mit.edu/6.033/2007/wwwdocs/assignments/handson-li... >I fully recognize that there are dangers and risks to which I may be exposed by participating in Reproduction of Therac-25 accidents . The following is a description and/or examples of significant dangers and risks associated with this activity Acute gullibility, Failure to understand April Fool's jokes, Night terrors associated with medical radiation machines .
mrandish 2y ago
Because the linked page doesn't include a description of what a Therac-25 is: > "The Therac-25 is a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited in 1982. The Therac-25 was involved in at least six accidents between 1985 and 1987, in which some patients were given massive overdoses of radiation. Because of concurrent programming errors (also known as race conditions), it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury. These accidents highlighted the dangers of software control of safety-critical systems." https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
- whycome 2y ago
  You're missing one critical aspect of this nightmare. After an incident: "The AECL responded in two pages detailing the reasons why radiation overdose was impossible on the Therac-25, stating both machine failure and operator error were not possible."
  - pmalynin 2y ago
    RBMK Reactors Do Not Explode
- sky2224 2y ago
  There's another massive thing to highlight with this. Atomic Energy had a death and "fixed" the issues. Then they had more deaths. It really highlights the fact that proper and adequate testing is absolutely and unquestionably required for a system like this, and that if you don't have testing and issues do occur, then you're essentially just going to keep creating issues for yourself while fixing the issues you created in the first place. Therac-25 is genuinely horrifying.
  - dreamcompiler 2y ago
    Not just testing. Any modern system this safety critical should be proven with formal methods.
sho_hn 2y ago
Leveson's fantastic Therac-25 paper is probably the most important document in the formative years of my young sweng career. I still re-read it every couple of years, and it's held up a lot better than one of my other early favorites, which was Feynman's appendix to the Challenger report. In the sense that I still draw new thoughts and realizations from it as I re-read it with additional experience in some of the engineering and organizational disciplines it touches. Sad as it is, it's got a little bit of everything. It's definitely got my vote for the I Ching of critical systems engineering. Spend the time. Chances are you'll remember it.
- _peeley 2y ago
  Do you mind specifying the title of the paper? It appears there's quite a few papers[1][2][3] published concerning Therac-25 by an author named Leveson. [1] http://sunnyday.mit.edu/papers/therac.pdf http://sunnyday.mit.edu/papers/therac.pdf [2] https://ieeexplore.ieee.org/document/274940 https://ieeexplore.ieee.org/document/274940 [3] https://ieeexplore.ieee.org/document/8102762 https://ieeexplore.ieee.org/document/8102762
  - sho_hn 2y ago
    Gladly! It's the second of these, "An investigation of the Therac-25 accidents" (1993) w/ DOI 10.1109/MC.1993.274940. #1 is a later version that was an appendix to her book Safeware (which I have not read), and [3] is a nice second read that follows up on [2] many years later but isn't quite the relentless engineering detective story that makes the original so poignant.
    - _peeley 2y ago
      Thank you!
      - stavros 2y ago
        https://sci-hub.st/https://ieeexplore.ieee.org/document/274940 https://sci-hub.st/https://ieeexplore.ieee.org/document/2749...
aaron695 2y ago
[dead]
dkulchenko 2y ago
Every time I read the story of Therac-25 I feel incredibly frustrated AECL never faced real consequences or (criminal) liability for it. Maybe I'm retroactively imposing modern day safety culture, but reading the timeline and history, it feels like AECL was completely negligent in waving off the issue as more and more fatalities kept piling up. Can't believe the devices weren't pulled offline to definitively solve the issue after the first death. Instead, they basically went "can't repro, oh well".
- favorited 2y ago
  They should have faced consequences for their response, as much as for their error-prone device. Multiple patients had complained of extreme burns during their treatment, and autopsies later confirmed the cause of death to have been radiation exposure, yet AECL was still saying thing like, "damage could not have been produced by any malfunction of the Therac or by any operator error." Sure, they were laying under our radiation cannon and then died of extreme radiation exposure, but they probably got it somewhere else.
NegativeLatency 2y ago
Struggling to trigger either of the malfunction cases from therac.c, any tips?
- deleted 2y ago
  [deleted]
- probably_wrong 2y ago
  I got both malfunctions by running the machine successfully once, changing the Beam Type and then running again.
- OptionOfT 2y ago
  Set up your whole setup, and fire a beam. Then within 8 seconds change the beam to the other type and fire it again.
johnwheeler 2y ago
I fully recognize that there are dangers and risks to which I may be exposed by participating in Reproduction of Therac-25 accidents . The following is a description and/or examples of significant dangers and risks associated with this activity Acute gullibility, Failure to understand April Fool's jokes, Night terrors associated with medical radiation machines .
mbStavola 2y ago
Recently I had to get a panoramic dental x-ray and I was making small talk with the person who was running the machine. I joked that I'm always cautious about machines like this, even knowing the dosage of radiation is low, simply because of the history of software safety controls and the story of Therac-25. She hadn't heard of it before and I gave her the gist of it, that an issue with the programming made it so it was possible to accidentally dose a patient considerably more than the intended amount (in a few different ways). It was interesting to her but I then had to pause so she could run the machine. I shut up and she did her thing. Then, after a few minutes of scanning, she sucked her teeth a bit and apologized, saying she needed to run it once more. No worries, let's get it done! She starts it again and as I'm getting scanned she explains that "for whatever reason I was getting an error so I just had to restart it, this happens sometimes and I'm not really sure why." I give a little half-nervous chuckle and then the scan completes. Once I pull my head out of the machine, I finally get to finish my lovely Therac-25 story wherein I explain that one of the issues was... a combination of non-descriptive error codes, insufficient failsafes, and operator error resulting in patient casualties as the procedure was restarted one or more times. We shared a little laugh and discussed other things, cost of living primarily. I'm still alive so I'm at least 63% sure I didn't get megadosed or anything but its been a funny conversation to revisit now and then.
- sho_hn 2y ago
  Noticed any new abilities lately?
  - LelouBil 2y ago
    I guess fast dividing cells is a kind of ability ?
- emchammer 2y ago
  I would not consider it operator error. Hitting backspace and re-typing the mode? That should be as obvious a change for that kind of thing as shifting between 1st and 4th gear.
  - 2y ago
haddonist 2y ago
Well There's Your Problem Podcast (with slides) Episode 121: Therac-25 https://www.youtube.com/watch?v=7EQT1gVsE6I https://www.youtube.com/watch?v=7EQT1gVsE6I
JohnBooty 2y ago
Question 4: How many rads did you receive in doing this project? Best question ever.
thangalin 2y ago
From my blog[1]: "In 2017, Leveson revisited those lessons[2] and concluded that modern software systems still suffer from the same issues. In addition, she noted: * Error prevention and detection must be included from the outset. * Software designs are often unnecessarily complex. * Software engineers and human factors engineers must communicate more. * Blame still falls on operators rather than interface designs. * Overconfidence in reusing software remains rampant." [1]: https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ [2]: https://ieeexplore.ieee.org/document/8102762 https://ieeexplore.ieee.org/document/8102762
- userbinator 2y ago
  It took several decades to finally admit "unnecessarily complex" software was a problem? No wonder.
userbinator 2y ago
I remember reading --- and vehemently disagreeing --- with the report on the incidents, which danced around the matter but didn't point directly at the underlying cause: excessive complexity in the software, which easily created bugs and hid them. For example, they used multiple threads and a whole OS, when a simple loop would've been sufficient, perhaps in a misguided attempt at trying to keep the UI "responsive"; there would not be any race conditions if everything ran in the same thread. As Tony Hoare says: "There are two ways to develop software: Make it so simple that there are obviously no bugs, or so complex that there are no obvious bugs."
- AlotOfReading 2y ago
  Having written a lot of safety critical code, I don't think you could ever convince me that multithreading was the most important safety issue. It was a safety critical system written by a single anonymous person in assembly without adequate testing. The process was fundamentally broken. Changing one technical decision would have simply exposed another failure somewhere else.
  - MarkusWandel 2y ago
    It's been a while since I read the detailed analysis, but wasn't it basically this? 1. A bug in the software that was prevented from doing harm (not necessarily masked but reduced to a minor irritant) by a hardware safety interlock. 2. The hardware safety interlock being removed in a cost-reduction. I know that "field mileage" is a powerful indicator of quality. Even if the code is awful and full of workarounds - if you have a lot of field experience you'd be loath to mess with it. So by the time the cost reduction came along the software would be fully trusted.
    - AlotOfReading 2y ago
      Yes, that's essentially the story. It misses a lot of safeguards that should have existed (from a hindsight is 20/20 perspective). There's no "fully trusted" in safety critical code, so the software should have gone through a complete review when the safety model changed from hardware based to software based, including a HARA analysis and single point of failure analysis. The software should have had a specification and testing that included things like counter rollover and variable race conditions. The single developer should have had someone else to review their work and catch mistakes. This is standard practice these days, in large part specifically to prevent disasters like therac-25. While it's a little unfair to judge them by standards that didn't exist yet, it was still a broken process.
picjamai 2y ago
[dead]
junon 2y ago
Assume from the paper this simulator does not contain the software patch that fixed it? I'd be curious to see the "patch" for this that would, spelled out in more modern code (not sure what the original Therac was written in).
at_a_remove 2y ago
At a Starbucks years ago, a woman next to me requested to plug into my USB charger, which had an open port. Since any interaction of mine with a new person was doomed to awkwardness, of course I ended up with the sadly comical three-try, two-rotation final insertion. She made a crack about Schroedinger's USB port and I smiled, then she began to explain to me that it was a physics thing. After I replied that, yeah, that was my undergrad. It turned out to be hers as well. Then we found out that we had both gone into programming. She was doing programming in medicine, and, when prompted for further details, mentioned working on the software for one of those multi-beam radiation gizmos. I mentioned Therac-25 and we were off to the races. I think we talked for about two hours on programming in high-risk situations, hers in those machines, mine in location services and routing for emergency services. That maniacal technician who irradiated that poor boy (the names escape me) was brought up. At one point we hit on the Challenger disaster. I was comforted to meet another programmer who had certain philosophies about making reliable niche software. I'm not at that level, but I think it is something to which I ought to occasionally aspire.
dang 2y ago
Related. Others? The Therac-25 Incident - https://news.ycombinator.com/item?id=38458448 https://news.ycombinator.com/item?id=38458448 - Nov 2023 (10 comments) Therac-25 - https://news.ycombinator.com/item?id=37480795 https://news.ycombinator.com/item?id=37480795 - Sept 2023 (15 comments) An Investigation of the Therac-25 Accidents (1993) [pdf] - https://news.ycombinator.com/item?id=34636130 https://news.ycombinator.com/item?id=34636130 - Feb 2023 (1 comment) The Therac-25 Incident - https://news.ycombinator.com/item?id=26142432 https://news.ycombinator.com/item?id=26142432 - Feb 2021 (77 comments) A Brief History Of: The Therac-25 (Short Documentary) - https://news.ycombinator.com/item?id=24388735 https://news.ycombinator.com/item?id=24388735 - Sept 2020 (1 comment) The Worst Computer Bugs in History: Race conditions in Therac-25 - https://news.ycombinator.com/item?id=23200759 https://news.ycombinator.com/item?id=23200759 - May 2020 (1 comment) The programmer behind the Therac-25 fiasco was never found - https://news.ycombinator.com/item?id=21679287 https://news.ycombinator.com/item?id=21679287 - Dec 2019 (121 comments) Worst Computer Bugs in History: Therac-25 (2017) - https://news.ycombinator.com/item?id=17740292 https://news.ycombinator.com/item?id=17740292 - Aug 2018 (110 comments) Killed by a Machine: The Therac-25 - https://news.ycombinator.com/item?id=12201147 https://news.ycombinator.com/item?id=12201147 - Aug 2016 (40 comments) Medical Devices: The Therac-25 (1995) - https://news.ycombinator.com/item?id=9643054 https://news.ycombinator.com/item?id=9643054 - June 2015 (18 comments) An Investigation of the Therac-25 Accidents (1993) [pdf] - https://news.ycombinator.com/item?id=8755469 https://news.ycombinator.com/item?id=8755469 - Dec 2014 (1 comment) Therac-25 - https://news.ycombinator.com/item?id=7257005 https://news.ycombinator.com/item?id=7257005 - Feb 2014 (77 comments) Therac-25: When software reliability really does matter - https://news.ycombinator.com/item?id=1143776 https://news.ycombinator.com/item?id=1143776 - Feb 2010 (18 comments) An Investigation of the Therac-25 Accidents (1993) - https://news.ycombinator.com/item?id=202940 https://news.ycombinator.com/item?id=202940 - May 2008 (2 comments)
fifticon 2y ago
They suggest the students should do this exercise in pairs. When doing so, the lucky partner is the one who doesn't have to sit in front of the radiation source.
TomMasz 2y ago
I remember reading about the Therac-25 when the first post-mortem explanations appeared. Those poor patients, they could feel something was wrong but were told everything was fine because the operators didn't see anything out of the ordinary.

106 points by luu 2y ago

http://web.mit.edu/6.033/2007/wwwdocs/assignments/handson-liability.html http://web.mit.edu/6.033/2007/wwwdocs/assignments/handson-li... >I fully recognize that there are dangers and risks to which I may be exposed by participating in Reproduction of Therac-25 accidents . The following is a description and/or examples of significant dangers and risks associated with this activity Acute gullibility, Failure to understand April Fool's jokes, Night terrors associated with medical radiation machines .

mrandish 2y ago

Because the linked page doesn't include a description of what a Therac-25 is: > "The Therac-25 is a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited in 1982. The Therac-25 was involved in at least six accidents between 1985 and 1987, in which some patients were given massive overdoses of radiation. Because of concurrent programming errors (also known as race conditions), it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury. These accidents highlighted the dangers of software control of safety-critical systems." https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25

whycome 2y ago
You're missing one critical aspect of this nightmare. After an incident: "The AECL responded in two pages detailing the reasons why radiation overdose was impossible on the Therac-25, stating both machine failure and operator error were not possible."
- pmalynin 2y ago
  RBMK Reactors Do Not Explode
sky2224 2y ago
There's another massive thing to highlight with this. Atomic Energy had a death and "fixed" the issues. Then they had more deaths. It really highlights the fact that proper and adequate testing is absolutely and unquestionably required for a system like this, and that if you don't have testing and issues do occur, then you're essentially just going to keep creating issues for yourself while fixing the issues you created in the first place. Therac-25 is genuinely horrifying.
- dreamcompiler 2y ago
  Not just testing. Any modern system this safety critical should be proven with formal methods.

sho_hn 2y ago

Leveson's fantastic Therac-25 paper is probably the most important document in the formative years of my young sweng career. I still re-read it every couple of years, and it's held up a lot better than one of my other early favorites, which was Feynman's appendix to the Challenger report. In the sense that I still draw new thoughts and realizations from it as I re-read it with additional experience in some of the engineering and organizational disciplines it touches. Sad as it is, it's got a little bit of everything. It's definitely got my vote for the I Ching of critical systems engineering. Spend the time. Chances are you'll remember it.

_peeley 2y ago
Do you mind specifying the title of the paper? It appears there's quite a few papers[1][2][3] published concerning Therac-25 by an author named Leveson. [1] http://sunnyday.mit.edu/papers/therac.pdf http://sunnyday.mit.edu/papers/therac.pdf [2] https://ieeexplore.ieee.org/document/274940 https://ieeexplore.ieee.org/document/274940 [3] https://ieeexplore.ieee.org/document/8102762 https://ieeexplore.ieee.org/document/8102762
- sho_hn 2y ago
  Gladly! It's the second of these, "An investigation of the Therac-25 accidents" (1993) w/ DOI 10.1109/MC.1993.274940. #1 is a later version that was an appendix to her book Safeware (which I have not read), and [3] is a nice second read that follows up on [2] many years later but isn't quite the relentless engineering detective story that makes the original so poignant.
  - _peeley 2y ago
    Thank you!
    - stavros 2y ago
      https://sci-hub.st/https://ieeexplore.ieee.org/document/274940 https://sci-hub.st/https://ieeexplore.ieee.org/document/2749...

aaron695 2y ago

[dead]

dkulchenko 2y ago

Every time I read the story of Therac-25 I feel incredibly frustrated AECL never faced real consequences or (criminal) liability for it. Maybe I'm retroactively imposing modern day safety culture, but reading the timeline and history, it feels like AECL was completely negligent in waving off the issue as more and more fatalities kept piling up. Can't believe the devices weren't pulled offline to definitively solve the issue after the first death. Instead, they basically went "can't repro, oh well".

favorited 2y ago
They should have faced consequences for their response, as much as for their error-prone device. Multiple patients had complained of extreme burns during their treatment, and autopsies later confirmed the cause of death to have been radiation exposure, yet AECL was still saying thing like, "damage could not have been produced by any malfunction of the Therac or by any operator error." Sure, they were laying under our radiation cannon and then died of extreme radiation exposure, but they probably got it somewhere else.

NegativeLatency 2y ago

Struggling to trigger either of the malfunction cases from therac.c, any tips?

deleted 2y ago
[deleted]
probably_wrong 2y ago
I got both malfunctions by running the machine successfully once, changing the Beam Type and then running again.
OptionOfT 2y ago
Set up your whole setup, and fire a beam. Then within 8 seconds change the beam to the other type and fire it again.

johnwheeler 2y ago

I fully recognize that there are dangers and risks to which I may be exposed by participating in Reproduction of Therac-25 accidents . The following is a description and/or examples of significant dangers and risks associated with this activity Acute gullibility, Failure to understand April Fool's jokes, Night terrors associated with medical radiation machines .

mbStavola 2y ago

Recently I had to get a panoramic dental x-ray and I was making small talk with the person who was running the machine. I joked that I'm always cautious about machines like this, even knowing the dosage of radiation is low, simply because of the history of software safety controls and the story of Therac-25. She hadn't heard of it before and I gave her the gist of it, that an issue with the programming made it so it was possible to accidentally dose a patient considerably more than the intended amount (in a few different ways). It was interesting to her but I then had to pause so she could run the machine. I shut up and she did her thing. Then, after a few minutes of scanning, she sucked her teeth a bit and apologized, saying she needed to run it once more. No worries, let's get it done! She starts it again and as I'm getting scanned she explains that "for whatever reason I was getting an error so I just had to restart it, this happens sometimes and I'm not really sure why." I give a little half-nervous chuckle and then the scan completes. Once I pull my head out of the machine, I finally get to finish my lovely Therac-25 story wherein I explain that one of the issues was... a combination of non-descriptive error codes, insufficient failsafes, and operator error resulting in patient casualties as the procedure was restarted one or more times. We shared a little laugh and discussed other things, cost of living primarily. I'm still alive so I'm at least 63% sure I didn't get megadosed or anything but its been a funny conversation to revisit now and then.

sho_hn 2y ago
Noticed any new abilities lately?
- LelouBil 2y ago
  I guess fast dividing cells is a kind of ability ?
emchammer 2y ago
I would not consider it operator error. Hitting backspace and re-typing the mode? That should be as obvious a change for that kind of thing as shifting between 1st and 4th gear.
- 2y ago

haddonist 2y ago

Well There's Your Problem Podcast (with slides) Episode 121: Therac-25 https://www.youtube.com/watch?v=7EQT1gVsE6I https://www.youtube.com/watch?v=7EQT1gVsE6I

JohnBooty 2y ago

Question 4: How many rads did you receive in doing this project? Best question ever.

thangalin 2y ago

From my blog[1]: "In 2017, Leveson revisited those lessons[2] and concluded that modern software systems still suffer from the same issues. In addition, she noted: * Error prevention and detection must be included from the outset. * Software designs are often unnecessarily complex. * Software engineers and human factors engineers must communicate more. * Blame still falls on operators rather than interface designs. * Overconfidence in reusing software remains rampant." [1]: https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ [2]: https://ieeexplore.ieee.org/document/8102762 https://ieeexplore.ieee.org/document/8102762

userbinator 2y ago
It took several decades to finally admit "unnecessarily complex" software was a problem? No wonder.

userbinator 2y ago

I remember reading --- and vehemently disagreeing --- with the report on the incidents, which danced around the matter but didn't point directly at the underlying cause: excessive complexity in the software, which easily created bugs and hid them. For example, they used multiple threads and a whole OS, when a simple loop would've been sufficient, perhaps in a misguided attempt at trying to keep the UI "responsive"; there would not be any race conditions if everything ran in the same thread. As Tony Hoare says: "There are two ways to develop software: Make it so simple that there are obviously no bugs, or so complex that there are no obvious bugs."

AlotOfReading 2y ago
Having written a lot of safety critical code, I don't think you could ever convince me that multithreading was the most important safety issue. It was a safety critical system written by a single anonymous person in assembly without adequate testing. The process was fundamentally broken. Changing one technical decision would have simply exposed another failure somewhere else.
- MarkusWandel 2y ago
  It's been a while since I read the detailed analysis, but wasn't it basically this? 1. A bug in the software that was prevented from doing harm (not necessarily masked but reduced to a minor irritant) by a hardware safety interlock. 2. The hardware safety interlock being removed in a cost-reduction. I know that "field mileage" is a powerful indicator of quality. Even if the code is awful and full of workarounds - if you have a lot of field experience you'd be loath to mess with it. So by the time the cost reduction came along the software would be fully trusted.
  - AlotOfReading 2y ago
    Yes, that's essentially the story. It misses a lot of safeguards that should have existed (from a hindsight is 20/20 perspective). There's no "fully trusted" in safety critical code, so the software should have gone through a complete review when the safety model changed from hardware based to software based, including a HARA analysis and single point of failure analysis. The software should have had a specification and testing that included things like counter rollover and variable race conditions. The single developer should have had someone else to review their work and catch mistakes. This is standard practice these days, in large part specifically to prevent disasters like therac-25. While it's a little unfair to judge them by standards that didn't exist yet, it was still a broken process.

picjamai 2y ago

[dead]

junon 2y ago

Assume from the paper this simulator does not contain the software patch that fixed it? I'd be curious to see the "patch" for this that would, spelled out in more modern code (not sure what the original Therac was written in).

at_a_remove 2y ago

At a Starbucks years ago, a woman next to me requested to plug into my USB charger, which had an open port. Since any interaction of mine with a new person was doomed to awkwardness, of course I ended up with the sadly comical three-try, two-rotation final insertion. She made a crack about Schroedinger's USB port and I smiled, then she began to explain to me that it was a physics thing. After I replied that, yeah, that was my undergrad. It turned out to be hers as well. Then we found out that we had both gone into programming. She was doing programming in medicine, and, when prompted for further details, mentioned working on the software for one of those multi-beam radiation gizmos. I mentioned Therac-25 and we were off to the races. I think we talked for about two hours on programming in high-risk situations, hers in those machines, mine in location services and routing for emergency services. That maniacal technician who irradiated that poor boy (the names escape me) was brought up. At one point we hit on the Challenger disaster. I was comforted to meet another programmer who had certain philosophies about making reliable niche software. I'm not at that level, but I think it is something to which I ought to occasionally aspire.

dang 2y ago

Related. Others? The Therac-25 Incident - https://news.ycombinator.com/item?id=38458448 https://news.ycombinator.com/item?id=38458448 - Nov 2023 (10 comments) Therac-25 - https://news.ycombinator.com/item?id=37480795 https://news.ycombinator.com/item?id=37480795 - Sept 2023 (15 comments) An Investigation of the Therac-25 Accidents (1993) [pdf] - https://news.ycombinator.com/item?id=34636130 https://news.ycombinator.com/item?id=34636130 - Feb 2023 (1 comment) The Therac-25 Incident - https://news.ycombinator.com/item?id=26142432 https://news.ycombinator.com/item?id=26142432 - Feb 2021 (77 comments) A Brief History Of: The Therac-25 (Short Documentary) - https://news.ycombinator.com/item?id=24388735 https://news.ycombinator.com/item?id=24388735 - Sept 2020 (1 comment) The Worst Computer Bugs in History: Race conditions in Therac-25 - https://news.ycombinator.com/item?id=23200759 https://news.ycombinator.com/item?id=23200759 - May 2020 (1 comment) The programmer behind the Therac-25 fiasco was never found - https://news.ycombinator.com/item?id=21679287 https://news.ycombinator.com/item?id=21679287 - Dec 2019 (121 comments) Worst Computer Bugs in History: Therac-25 (2017) - https://news.ycombinator.com/item?id=17740292 https://news.ycombinator.com/item?id=17740292 - Aug 2018 (110 comments) Killed by a Machine: The Therac-25 - https://news.ycombinator.com/item?id=12201147 https://news.ycombinator.com/item?id=12201147 - Aug 2016 (40 comments) Medical Devices: The Therac-25 (1995) - https://news.ycombinator.com/item?id=9643054 https://news.ycombinator.com/item?id=9643054 - June 2015 (18 comments) An Investigation of the Therac-25 Accidents (1993) [pdf] - https://news.ycombinator.com/item?id=8755469 https://news.ycombinator.com/item?id=8755469 - Dec 2014 (1 comment) Therac-25 - https://news.ycombinator.com/item?id=7257005 https://news.ycombinator.com/item?id=7257005 - Feb 2014 (77 comments) Therac-25: When software reliability really does matter - https://news.ycombinator.com/item?id=1143776 https://news.ycombinator.com/item?id=1143776 - Feb 2010 (18 comments) An Investigation of the Therac-25 Accidents (1993) - https://news.ycombinator.com/item?id=202940 https://news.ycombinator.com/item?id=202940 - May 2008 (2 comments)

fifticon 2y ago

They suggest the students should do this exercise in pairs. When doing so, the lucky partner is the one who doesn't have to sit in front of the radiation source.

TomMasz 2y ago

I remember reading about the Therac-25 when the first post-mortem explanations appeared. Those poor patients, they could feel something was wrong but were told everything was fine because the operators didn't see anything out of the ordinary.