Therac-25: When software reliability really does matter

Re:Therac-25: When software reliability really does matter by jrockway on Monday February 22, 2010 @05:54PM (#1143986)

The industry learned its lesson. Instead of continuing to use unsafe languages like C, they switched to safe, statically-typed languages. The tiny speed hit that checking memory bounds before accessing arrays required turned out to not be a big deal, and the improved programmer productivity more than made up for the need for slightly-more-expensive hardware. And, of course, the number of lives saved was more valuable than a few extra microseconds of execution time and the larger EEPROM needed to store the smarter runtime.

Oh sorry, that was me daydreaming. Of course nothing has changed, people just "try to be more careful". Since people never make mistakes, even when pressed with tight deadlines, this has worked out fine. Asking the computer to double-check your code is just not necessary.

(Hmm, I think I got that backwards. It's just not my day today, is it...)

[ Parent | on HN ]

Re:Therac-25: When software reliability really does matter by jordanb on Monday February 22, 2010 @06:54PM (#1144122)

While some of the newer, more exotic technologies may show some promise, reality is that the use of C is an Industry Best Practice that is Well Tested and has been Proven over many decades. So while perhaps, someday, some of the exotic technologies may become Standard, for now, when dealing with such important tasks, a conservative Wait-and-See approach must be taken.

Translation: Nobody ever got fired for going with C, even when it leaves a stiff on the table.

[ Parent | on HN ]

Re:Therac-25: When software reliability really does matter by gamble on Monday February 22, 2010 @08:03PM (#1144268)

The Therac-25 was much more of a management and engineering failure than a technical problem, though. While the immediate cause of the deaths was a race condition in the software, it was only capable of causing harm because the hardware safety mechanism had been removed as a cost-saving measure, without proper verification that the software was capable of doing the same job. Worse, it was widely known among the Therac's users that the hardware safety would regularly trip during normal operation without apparent cause, yet the problem was never investigated until after the deaths.

Ultimately, the Therac was a failure of software engineering more than a software failure. I don't blame the technology any more than I would blame a girder for buckling because a careless structural engineer didn't realize it was overloaded.

[ Parent | on HN ]

Re:Therac-25: When software reliability really does matter by jrockway on Monday February 22, 2010 @08:14PM (#1144293)

If the software had worked, it would have mattered if the hardware safety was removed. I'm not saying to design without hardware safety mechanisms, of course, but it's nice to know that you'll never need them.

[ Parent | on HN ]

Re:Therac-25: When software reliability really does matter by gamble on Monday February 22, 2010 @09:17PM (#1144406)

The problem is that no one bothered to check whether the software worked when they removed the hardware. It's not a good thing that there was a bug in the first place, but proper procedures could easily have caught it before people were killed. That's why you have multiple systems to prevent catastrophic failures.

What makes the Therac-25 notable is the novelty of a software problem killing people. If it had been a second hardware safety mechanism that had been removed, it wouldn't be as notorious - but the engineering failure would be equivalent.

[ Parent | on HN ]