3 ms·
> There were many things wrong with this project, but one of them was fatally bad code, which this guy took money to write. If I remember correctly, the bug in
by gwd 7y ago
> There were many things wrong with this project, but one of them was fatally bad code, which this guy took money to write.
If I remember correctly, the bug in this case was a race condition between "normally" running code and an interrupt handler. The race was only triggered if an interrupt happened in just the right window between two instructions. I'd be willing to bet that 99% of programmers, if simply given the code and asked, "Is there a bug here?" would have answered "No".
Should people writing operating-system-level medical equipment software be required to have a basic training about race conditions and how to prevent them? Yes. Is it fair to expect a random engineer who was ordered by his company to rewrite the code to work without a hardware interlock to know what he doesn't know? No.
- starfallg 7y ago> Is it fair to expect a random engineer who was ordered by his company to rewrite the code to work without a hardware interlock to know what he doesn't know? No. Looking back at when I did Safety Critical Systems at Uni way back in another era, the most important points that we got out of the Therac-25 case study were not to do with bugs at all, but to do with the deficiencies of the system architecture and methodology, especially the decisions that led up to it.
- mcguire 7y agoIs said "random engineer" an engineer? No. He's a code monkey and should be expected to be paid like a code monkey.
- wpietri 7y agoIt is 100% fair to expect people working on life-critical systems to either a) know that they are competent to work on life-critical code, or b) to not work on life-critical code. The guy wasn't ordered to do this at the point of a gun. His bosses asked him to do something, he said yes because he liked the money, and people died. The bosses are also responsible, but that doesn't mean that his negligence didn't kill people.