Slashdot Mirror
Can Software Kill?
mykepredko writes "Eweek has an interesting, if somewhat long article titled Can Software Kill? The article focuses on a programming error that resulted in 28 Panamanian cancer patients receiving many times an expected lethal dose of radiation. The article briefly mentions, but doesn't go into detail, the 1991 Patriot Missile Failure that resulted in the deaths of 28 American service men and women."
Anyone who hasn't read this paper, should.
I've had this sig for three days.
A good book that tells how technology can cause death, destruction, and mayhem entitled "Set Phasers on Stun". Includes the Therac radiation machine accidents, nuclear accidents, and many other odd stories.
42 - So long and thanks for all the fish.
There was a good discussion of this event some months ago; the current issue has blurbs on topics ranging from computer viruses to aircraft cockpit management.
Sadly, this is nothing new.
Every software developer needs to read Peter Neuman's book Computer-Related Risks , and keep up with the Risks digest (comp.risks).
Learning from other's mistakes is much less painful.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
The problem was actually one of training and clueless operators. IIRC. the coordinates of the missile launcher had to be updated several times a day. The technicians went several days without doing so. A Scud flew into the area the Patriot was supposed to be protecting, but the system was so confused as to where it was that it thought it was another batteries' responsibility and did nothing. The Scud crashed into an area with Coalition troops and killed 28, the largest death toll due to a single action in Desert Storm.
If my answers frighten you, stop asking scary questions.
And 64 bit integers converted to 16 bit integers kill, if not people, at least big budgets.
"If you think education is expensive, try ignorance" - Derek Bok
Ha, ha.
It's a serious topic, even more so since the over-radiation shit in Panama happened so recently.
The infamous Therac-25 incidents happened between 1985 and 1987 and should be required reading... too bad the three Panamanian medical physicists cited in the article hadn't paid attention to it.
The Davis-Besse nuclear reactor in Ohio was running its safty monitoring systems on an NT server. And it got infected by Slammer and crashed. Fortunatly, the system had an analog backup, and the reactor had already been offline all year, after inspectors discovered a 6" hole through the cement in the reactor head, which left the core exposed.
ASCII stupid question, get a stupid ANSI
A software glitch caused the crash of the first F-22 prototype (noone died fortunately) and as someone else pointed out, the Patriot missile failure in the first Gulf War (Software wasn't ENTIRELY to blame there. The bug was known and the folks in the field were given instructions on how to avoid it, but didn't follow them)
The trick is who do you hold responsible? The software person who has no training in mission critical software and who's working 80 hour weeks to meet the deadline the idiot managers are shoving down vis throat?
After 10 years in the industry I'm FINALLY starting to see movement towards software creation as a serious engineering discipline. Schools are starting to offer programs in Software Engineering, the ACM and IEEE have agreed on an official code of conduct (tho IHMO it still has SERIOUS problems), and most importantly companies are starting to listen to their technial folks when they say "You can't do that!".
Liability is just another incentive to head down that road. We need to be sure we pin the liability on the right folks.