Linked by Thom Holwerda on Thu 10th Nov 2005 18:44 UTC, submitted by jayson.knight
Bugs & Viruses This article lists the 10 worst software bugs in computing history. "In 1945, engineers found a moth in Panel F, Relay #70 of the Harvard Mark II system. The computer was running a test of its multiplier and adder when the engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."
Order by: Score:
then vs now...
by hobgoblin on Thu 10th Nov 2005 19:40 UTC
hobgoblin
Member since:
2005-07-06

the important point is this:
"when the engineers noticed something was wrong"

as the stack from software to hardware becomes bigger and bigger one starts to wonder what kind of flaws may hide in there somewhere that can lead to calculations coming out wrong.

the only real way of telling is by taking the same input numbers and do the math manualy. but as the calculations become bigger and the timeframes become smaller we may well risk a flaw going unnoticed until it kills someone...

can we realy trust our new electronic overlords?

Edited 2005-11-10 19:40

Reply Score: 1

RE: then vs now...
by joelito_pr on Thu 10th Nov 2005 23:35 UTC in reply to "then vs now..."
joelito_pr Member since:
2005-07-07

A bit off topic but

can we realy trust our new electronic overlords?

I think you've been too long on /.

Reply Score: 2

RE[2]: then vs now...
by hobgoblin on Thu 10th Nov 2005 23:44 UTC in reply to "RE: then vs now..."
hobgoblin Member since:
2005-07-06

maybe so...

still, can you think of something better to call them?

Reply Score: 1

v Every version of Windows is just ...
by Sabon on Thu 10th Nov 2005 20:03 UTC
tests
by borat on Fri 11th Nov 2005 00:48 UTC
borat
Member since:
2005-11-11

i believe many of these big errors and in some cases, tragedies, could have been avoided with good unit testing. especially things like "The error is in the code that converts a 64-bit floating-point number to a 16-bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5 than in the Ariane 4, triggering an overflow condition that results in the flight computer crashing."

"What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured." As for this one i'm not so sure about, since it deals with interactivity, even good tests could have missed. perhaps this a good case for auditing. someone should have been auditing and maintaining the OS code.

alot of these bugs were long ago, i don't know the history of software testing principles, but theres really no excuse at this point. every class down to simple calculators in mission critical systems like radiation control should have an accompanying unit test. furthermore they should be tested by trained dedicated software testers, not just the developers/programmers that wrote the software.

Reply Score: 1

RE: tests
by daan on Fri 11th Nov 2005 10:38 UTC in reply to "tests"
daan Member since:
2005-07-07

Another example, by the way, was the recent mars explorer, of which the computer crashed due to an American entering something in inches where it should have been cm.

Reply Score: 1

RE[2]: tests
by hobgoblin on Fri 11th Nov 2005 11:14 UTC in reply to "RE: tests"
hobgoblin Member since:
2005-07-06

there was allso a sat that ended up in the wrong orbit based on the same mixup. this was right after nasa moved from inches to cm as a standard...

Reply Score: 1