Slashdot Mirror
History's Worst Software Bugs
bharatm writes "Wired has an article on the 10 worst sofware bugs.. From the article 'Coding errors have sparked explosions, crippled interplanetary probes -- even killed people. Here's our pick for the 10 worst bugs ever, but the judging wasn't easy.'"
Wonderful article. Twenty years ago I believed that writing software would soon become a licensed profession. (Need a
license to own a compiler, for instance.) I thought that the event that would inevitably trigger this is when a software
bug caused a human death.
I still believe that programming will eventually require a license, but I now think that lobbying by the big media
companies will be the cause. Depressing, huh?
I wouldnt say they are the 10 worst bugs ever... more like the 10 most widely known media announced bugs. Okay I have no examples of any others but I'm sure there must be worse bugs out there...
anyone think of any others?
why?
Bringing down the company's intranet countless times over the years almost seems like an amusing little distraction. No one died, nothing blew up, and I've even managed to keep my job. It must be that people are getting used to these "software bug" excuses for the various problems that pop up with computers. I'll have to remember that for next time.
Caller: "My computer exploded and I'm bleeding profusely!"
911 Operator: "Must be a software bug."
So nobody's hit on the really big one yet.
Deleted
The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."
Why would they say that, if the term "bug" didn't exist? I mean, you wouldn't find a rat in your car and say "First actual case of a car 'rat' being found" if you didn't use it as a term to indicate something. You'd just say "this bug caused computing errors". I smell a car rat.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
1995/1996 -- The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed "ping" packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called "blue screen of death" when they receive these packets. But the attack also affects many Macintosh and Unix systems as well.
===
WinNuke made it...
MoM++ - A Classic Expanded - [Master of Magic 1.5]
http://mompp.sourceforge.net/
The last one on the list is this
... to me that sounds like a user not using the software correctly..
"Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.
The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.
At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder. "
why?
Yes, I saw that too and I guess they have forgotten the most devastating MS bug which is present in all releases from NT 3.1 and at least up to 2k. I haven't tested XP.
I couldn't find the description right now, but I'm sure others know the bug. The one were you can basically type a special textfile using type-command or similar and will basically BSOD the machine. The file consists of tabs, spaces and newline/carriage return pairs and nothing else. MS never fixed the bug.
If you mod me down, I *will* introduce you to my sister!
Why do they have the Intel Pentium floating point divide error listed as a bug? That was a hardware design error in the circuit, it was not a software bug. Of course it caused software to behave unexpectedly, but still I'm surprised that Wired put that one in there.
Hero of Allacrost, a FOSS RPG for *NIX/*BSD/OS X/Win
July 28, 1962 -- Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket's trajectory.
1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.
1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.
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.
1988 -- Buffer overflow in Berkeley Unix finger daemon. The first internet worm (the so-called Morris Worm) infects between 2,000 and 6,000 computers in less than a day by taking advantage of a buffer overflow. The specific code is a function in the standard input/output library routine called gets() designed to get a line of text over the network. Unfortunately, gets() has no provision to limit its input, and an overly large input allows the worm to take over any machine to which it can connect.
Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day.
1988-1996 -- Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly "seed" the program's random number generator with a truly random seed. As a result, for eight years it is possible to trivially break into any computer that relies on Kerberos for authentication. It is unknown if this bug was ever actually exploited.
January 15, 1990 -- ATT Network Outage. A bug in a new release of the software that controls ATT's #4ESS long distance switches causes these mammoth computers to crash when they receive a specif
Something about their latest toy... ahm, ship that had to be towed back to port because Windows NT they used to run everything on the ship keep blue screening.
ELOI, ELOI, LAMA SABACHTHANI!?
Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better. If continuing education for programmers was a priority, quality would be better. If a couple of decades of experience was properly appreciated, quality would be better.
Hehehe.... This reminds me of a Dilbert cartoon. Here is what I can remember:
Some guy: And here is our random number generator.
Another guy: 2 2 2 2 2 2 2 2 2 2 2 2.
Dilbert: That isn't very random though.
Some guy: He is randomly getting the same number.
Anyone actually know which comic I am thinking of.
Ooo man the floppy drive is broken. No wait. The computer is just upside down.
I've read about this instance before, and I think it's attributable to ignorance on both the user and the developer. The software developer in this case knows the life of a human being is resting on his code, so it should have been nigh impossible to "trick" the software into allowing anything other than what the specs said it could do.
Proud member of the American Non Sequitur Society. We might not make much sense, but boy do we love pizza!
I found it a hard subject in school and have never used it practically, but it seems to be the only SURE way of proving the correctness of a program. Shouldn't we be using it, at least in real-time mission-critical applications now. I think it needs to be stressed a lot more in school from the start, as compared to topics like web development and java and all other pragmatic things that can be learned more easily.
Life is about being a Phoenix!
Jeuss Christ. I'd somehow never heard of this bug, and I've been developing for Windows machines for years.
How on earth was such a basic and low-level bug ignored for so long? It doesn't seem like rocket-science to fix it with a small bounds-checking if statement!
Everything in moderation, including moderation itself
Do people just open an article, do a Ctrl+F and type microsoft to find something 'juciy'? If you would have RTFA you would have seen that the 'Ping Of Death' was mentioned which did impact Windows machines.
- what is the definition of simultanagnosia?! I've been meaning to look it up!
Its intent was not to cause terror, but to inflict economic damage. I heard about a similar incident where a Japanese shipbuilder was stealing blueprints from a UK shipyard tendering for a contract and undercutting them. The UK shipbuilder deliberately designed a ship that would capsize on launch, which the Japanese duly stole, built, and launched. I don't know if anyone was killed, but ethically it's a tricky one.
Indeed. Causing a *NON FATAL* explosion in a country that imprisoned as many as 2.5 million political prisoners in Gulags at one time, and is estimated to have murdered upwards of 60 MILLION of its own citizens. Terrorism?
Terrorism is an act of mayhem designed to terrorize. This did not.
Sabotage? Yes.
Act of war? Probably.
Terrorism? Not even close.
Your statement is just a display of anti-American rhetoric with no basis in reality.
http://www.alexisparkinn.com/photogallery/Videos/A irbus320_trees.mpg/
(Let the slashdotting begin! (poor servers))
All things considered, I don't know if the pilots survived.
----------
Any problem can be made unsolvable if there are enough meetings made to discuss it.
Because it was actually implemented as microcode and stored into the CPU, whether as mask rom or some other means of storing, but it was indeed software either way you look at it.
That is wrong. This is a myth that has been disproved several times. See for example the "IEEE Annals of Computer History" where Adm. Grace Hopper said that that the term "bug" was used at least since the 30s, and maybe earlier, to describe an electrical problem in a system. See also here.
In interview, Hopper confirmed that the notebook moth's caption, "First actual case of bug being found", clearly shows that it was a joke referring to a term that was already in use at the time.
Any idiot researching this anecdote for five minutes could have found about it. I guess Wired couldn't be bothered. At this level of laziness and incompetence, one wonders why they just don't start publishing printouts of slashdot laced with ads. At least, this place contains occasional nudgets of truth.
Once again, Wired blew it. Nice jobs, guys.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
And i suppose if I had a "broken" gun in my basement and you broke in and stole it, then tried to use it and injured yourself, you could sue me right?
Sorry, i am having a hard time seeing the correlation to Terrorism here. It seems that you have a predisposition to the US's stance on terror and are desparately trying to make a connection for a political statement. Unfortunately, typical slashdot readers will agree with you =)
This would be very different if the US broke in to USSR and altered their software to malfunction. That definitely would be a criminal act, but more perhaps importantly and act of War. I doubt the Soviets ever figured out what happened until they were told.
Are you intolerant of intolerant people?
Remember when the LA air traffic control tower crashed, due to a bug in MS software after 49 days. I would think that this would make it up there. http://www.itgarage.com/node/459
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
When you are writing software for life-critical applications, there is various software and techniques that ensures bug-free code. Just look at all the airplanes, powerplants, car computers, etc. It's not very usual at all to see one fail critically.
When you are writing software for life critical systems, there are methods you can follow that allow you much greater assurance of correct code and drastically reduce the testing burden (byt being abel to prove that certain classes of errors don't exist in the code). It's akin to static types, which allow you to statically catch a lot of type errors obviating reducing the need to spend time testing for possible type errors.
The languages and methods used are things like SPARK and B-method The beauty of systems like SPARK is that they provide a degree of flexibility in how much work you go to depending on how much extra assurance you want. It is quite possible to simply specify critical portions of code with a little extra formality (basically extended static checks beyond what type checing alone can give you) through to fully specifying everything and doing formal proofs for the whole system. You can tailor the effort and assurance to the needs of the project.
(This time without that dangling link - that'll teahc me not to preview)
Jedidiah
Craft Beer Programming T-shirts
I designed and build a diagnostic radiology workstation (in 1997, in Java 1.1, 4x5 megapixel monitors, still in use today). During the development effort we were regaled with stories of software glitches in medical systems resulting in disaster. It really keeps you focused.
In one case, a radiation treatment system had a bug where if you used the backspace key when entering the dose a patient received, the display would show you deleted the last digit, but internally you hadn't. So the patient would recieve 10^backspace times the intended dose of radiation. Not a big deal normally, since the techs would typically shut the machine off between treatments. Until one day when they had two patients needing treatment back to back. The tech knew something was wrong when the machine was running for an unusually long time. The patient knew something was wrong when he died.
On our team a defect that crashed the system was considered severity 2. Severity 1 was reserved for defects that could result in a mis-diagnosis, which most patients agree is worse than a crash.
There are software engineers in Canada now. They can legally sign off on a software project. The problem is, is that you don't want to have every one of your programmers be licensed software engineers, all signing off on their own code. It would be too expensive to try and hire that many engineers, and managing all the signatures for all the code, when different people work on the same piece of code would be a nightmare to manage. Basically you'd have to have one engineer, or team thereof, overseeing the entire project to be sure that proper methods are being followed to ensure that there aren't any bugs. What you're asking for is more like saying that everyone who in building a bridge be licensed, and that they should all have to sign off on every rivet they put in.
The problem is, is that most companies producing software do not want to pay for an engineer to oversee their project. Also, the way most software operations are run, you wouldn't see an engineer, signing off on the projects. The engineer would force things to be much more tested in order to be ensure that things were actually worthy to be signed off on. There is lots of this kind of software being built for planes, and other situations where it really matters if there is bugs. I don't think this kind of situation will ever happen with off the shelf software. For one thing, software would cost too much, and most people aren't willing to pay $2000 to run an operating system on their home computer, and also because most engineers wouldn't sign off on a system, in which they didn't know the computer their software would run under. There's too many variables on a home computer to be able to garauntee, at that level, that your software will operate completely as expected.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
For potential severity, this one's worse than a few they listed.
Basically, the Navy was running critical ship systems on a Windows NT platform, and a divide-by-zero in a database caused a buffer overrun that resulted in a shutdown of the engines, leaving the ship dead in the water for 2.5 hours.
Fortunately, it was on maneuvers off of Cape Charles, and not at war off the coast of Yemen or something. Scratch a billion-dollar destroyer and most of her crew because of an NT bug, in that case.
Actually, you're confusing the title "P.E." (professional engineer) with the generally accepted term "engineer." One (the P.E.) is a licensed engineer, and others are used traditionally and arbitrarily with no legal recourse. For example, I and my co-workers are bona fide engineers, and most of us have engineering or engineering technology degrees. None of what we do requires a P.E. to sign off on anything, although there are other aspects of our business (and many other businesses) that do require a P.E.
Of course, there are all kinds of "engineers" that have that title but don't truly merit it -- customer service engineer; field service engineer; applications engineer; and so on. Most of these don't hold engineering degrees. For many of them, I don't begrudge them their title, either. But we also know that they're not P.E.'s.
--Jim (me)
2004 Luxembourg blackout
Patriot Missle - Missles had to be shut down once a day because targeting system would cycle every minute and change the internal cordinating system a fraction of a degree. Over the course of a few days the targeting system would be completely useless.
PS/2 shutdown bug - Analog copiers at the time fuser componants worked athe same frequency as the processor's shutdown signal.
Minus World - Super Mario Brother - A hidden water glitch
ErMac - Mortal Combat
You say things that offend me and I can deal with it. Can you?
The bug was about missing data in a lookup table. Intel said the problem was caused by a bug in the script designed to populate that table when the CPU was being designed, though legend has it that someone erronously "proved" that the data wasn't needed. So, I guess, either way you look at it, be it the script, the table, or the alleged logic flaw, it's a software, not a hardware bug (or at least, it's a bug caused by software.)
You are not alone. This is not normal. None of this is normal.
Why isn't Outlook Express in here? Early versions basically changed unopened e-mail viruses from a hoax to reality, when Microsoft decided it was a *good* idea to automatically run any VB script that was recieved. That's cluelessness like trusting everyone to be good and decent human beings while you walk through a prison shower with "Please rape me" painted on your back.
Later versions tried to fix the problem while keeping the functionality, as if somehow the bad guys would intentionally include the Evil Bit in their code.
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
And what makes you think that phone network software isn't peer reviewed?
regards,
treefrog
I used to work with the lead programmer on this software package from Multidata. We worked together at two different companies for a total of about four years.
Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.
This is also made very clear in the documentation. This isn't a bug at all, the dosimitrists misused the software.
The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.
Exactly. They tried to create a feature that the software did not support, and they did so in a manner that broke the software.
At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder.
It's not a software bug, it's a user error. This isn't a bug any more than it's a "bug" that your Linux box stops working properly if you do sudo rm -rf /. The users of the product knew better.
To be fair, Multidata was not a great shop from a procedural standpoint - the guy who ran it was insane, but the software was rock solid. I actually worked with a number of former Multidata employees who jumped ship and went to a rival shop that builds similar software, and they were all fairly competant and intelligent.
"I have never won a debate with an ignorant person." -Ali ibn Abi Talib
From Wiki page:
It also found that FirstEnergy did not take remedial action or warn other control centers until it was too late because of a bug in the Unix-based General Electric Energy's XA/21 system that prevented alarms from showing on their control system, and they had inadequate staff to detect and correct the software bug. The cascading effect that resulted ultimately forced the shutdown of more than 100 power plants.
Read the best of all of Slash: seenonslash.com
"1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligence Agency allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline"
can this really be considered a bug? It was an intentional software error..
It is inherently broken by design. You pass it a buffer of indeterminate size (selecting one large enough for your purposes), but you don't have any way of telling the function how big the buffer is. If you read more data than the buffer can handle, bad things happen.
No, the size of the buffer cannot reliably be determined from inside the function. Not even if you make it a macro.
Why do they retain it? Because dropping it would break a LOT of existing code. So they have been modifying the compilers to generate warning messages when it sees them.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
You keep using that word, 'terror'. Are you sure you know what it means?
The fact that there was an explosion of such magnitude doesn't bother me a bit. And I bet the majority of the citizens of the USSR weren't shaken a bit by this explosion, because (drum roll) they never knew such an accident had happened (and that's, for me, the scary part). And nothing spells success better than an act of terror noone finds out about, now does it?
Man is a slave because freedom is difficult, whereas slavery is easy.
My dad tells this story from time to time. I don't know if it's true, but it makes a good story. Back in the early days of computers when only big corporations had them, most software was written in-house by staff programmers. One of the major soda manufacturers had a new mainframe and had one of their top programmers write an accounting package for them. It so happens that the manufacturer was a major competitor of 7-Up. Well for whatever reason the programmer left the company on not-too-good terms. The very next time the manufacturer when to print out a report from the accounting package, every 7th page contained the phrase "Drink 7-Up" in big block letters. They had their remaining programmers go back through the code and try to remove this new "feature" but they were unable to. This guy was so good that he'd embedded the logic for this nastygram right into the actual logic of the accounting package. Supposedly there was code that would dynamically generate other instructions that, when executed would generate other instructions, etc. They were supposedly unable to get rid of the 7-Up message without breaking other parts of the program, so they ended up having to go back to square one and write a whole new accounting package.
So the story goes...
I think the two worst computer bugs of all time are the two that quite possibly could have wiped us all out. More inforation here.
(Copied from the article:)
* November 9, 1979, when the US made emergency retaliation preparations after NORAD saw on-screen indications that a full-scale Soviet attack had been launched. No attempt was made to use the "red telephone" hotline to clarify the situation with the USSR and it was not until early-warning radar systems confirmed no such launch had taken place that NORAD realised that a computer system test had caused the display errors. A Senator at NORAD at the time described an atmosphere of absolute panic. A GAO investigation led to the construction of an off-site test facility, to prevent similar mistakes subsequently. A fictionalized version of this incident was filmed as the movie WarGames, in which the test system is inadvertantly triggered by a teenage hacker believing himself to be playing a video game.
* September 26, 1983, when Soviet military officer Stanislav Petrov refused to launch ICBMs, despite computer indications that the US had already launched.
If it weren't for two humans who said "fuck what the computer says!", we might be in a very different place right now.
She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF
I looked at this a while back because many millenia ago, I worked at the company that produced the telemetry/control system for the Trans-Sib pipeline. It was a specialised outfit based in Warwickshire, UK. It is very doubtdul that their systems could have nobbled by anyone. The network was closed, based on an X.25ish HDLC and the software was blown on to UV erasable EPROMs. The CIA may have modified the s/w at the pump stations, but again it is doubtful.
See my journal, I write things there
From the post:
The resulting event is reportedly the largest non-nuclear explosion in the planet's history.
The actual quote from a hyperlink in the article mentioned in the post:
"The result was the most monumental non-nuclear explosion and fire ever seen from space"
The actual largest non-nuclear explosion occured during World War One in Halifax Harbour when an munitions ship collided with another ship and exploded. It is known as the Halifax Explosion. It was picked up on seismographs and created an 18 metre tsunami.
-- I ignore anonymous replies to my comments and postings.
Years ago, while working on a project for a medical firm, I found out first hand just how horrible things can go wrong with what we eventually agreed was a "bug" but was more of a "human bug" issue that made me sit up and realize that it's not just programmers who will use our programs.
Without getting to detailed, the end users were allowing certain conditions to go unchecked as the software was telling them it was "OK". There was a rather neat explosion (read, small) that hurt nobody and damaged some equipment because instead of being "OK" it was telling the operator that there was exactly "ZERO K" of space available for data storage on a recording device and the test needed to be shutdown.
Now, the operators were told that when the counter got low the would see a warning and be told to stop the tests so, was it a bug, was it my assumption that these 11.95/hour service techs would "understand" what "0K" means from "OK" (that's a zero(0) and an O there)? Either way, there was some damage, we had a bit of a laugh, but at least nobody got irradiated and died.
Why do overlook and oversee mean opposite things?
What about the Y2K bug? I believe that had a greater economic impact than many of the other "worst."
What those who want activist courts fear is rule by the people.
speaking of NASA foulups, Remember this one? "(CNN) -- NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday."
"How many light bulbs does it take to change a person?" --BMcC-->
Right, but back then you had to know how they worked to operate them. In fact I've never seen a modernized steam engine that ran itself. You couldn't even crest a hill too fast, or you'd have a flash in the boiler and blow the thing up, potentially killing people who weren't even in or near the engine at the time since there's a lot of energy involved in phase change and the boiler parts are all heavy. Thus steam engineers actually knew something, or they (and many people around them) were in a lot of trouble.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
However, you have been fooled. The parent comment is competely at odds with the article.
The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred. So, the real lesson from this article is not "you get what you pay for," but rather that "software development is very hard" and perhaps that "by nature of its hardness, we can expect critical flaws to pop up from time to time, even when highly trained, experienced, and monitored programmers are involved."
"That CIA gas plant explosion 'bug' is disgusting and has America == No.1 Terrorist written all over it if true."
I might as well say: "Idiots like you that corrupt the language are worse than terrorists."
Both are absurd exaggerations that have nothing to do with reality, and only degrade the ability of our language to carry meaning.
Get Real. Terrorism is the deliberate use of violence against civilians in order to induce a state of terror in the general population, as a method intended to achieve political, religious or ideological goals.
The CIA were not using violence, they were attempting to cause stolen technology to fail.
The CIA were not targeting civilians. Moreover, AFAIK, not one person was even killed in the explosion, which happened in a very remote area, and the specific explosion was certianly not planned (they had no knowledge of or control over how the Soviets used the stolen technology).
The CIA were certainly neither attempting to induce a state of terror, not cause change by inducing a state of terror.
You want to oppose the US government? Great -- there are many good bases on which to do so. But please, before you speak up next time, get some facts, learn how to use the language, and THINK! You might then have a chance of convincing somebody of your point, instead of just annoying them with your ignorance.
I hate to be pedantic (well no, I love it), but according to the Jargon file's entry on "bug":
But then again, why expect more from Wired.
Actually engineers existed long before the steam engine. The title of Civil Engineer was created to differentiate the practioners from the Military Engineers - the most common and probably the oldest usage of the title of engineer.
...carrier dead.....
Chile
Colin Powell's statement: "With respect to your earlier comments about Chile in the 1970s and what happened with Mr. Allende, it is not a part of American history that we're proud of."
Iran
Guatemala
Greece
There's lots more where those came from -- all democratically elected too. I hope you survive the cognitive dissonance.
Some of the bugs reported in the story were not so much the fault of programmers, but of management. The phone network bug was a misplaced { character in a nested if-else construct. The code had already been though extensive testing, and then a small change was needed. Because it was a "minor" change someone said it didn't need to go through the extensive (expensive) testing again. It's always easy to point at the code or the guy who wrote it. Especially when the boss is the one tasked with finding out what went wrong.
It doesn't matter how highly paid and trained your professionals are, if the environment that produces the software is not conducive to eliminating these types of flaws. Like if they are not given enough resources to test and QA the the projects they are assigned, there is no organizational commitment to take the time and expense to document properly, or leadership overrides technical objections to project timeframes, etc. Most of the cited projects could probably be classified as failures of project management rather than failures of the end product (the software) that these flawed projects produced. Yes, software is hard and the software profession should continue its efforts to improve quality, but that doesn't let the organizational culture, leadership and processes that produced the software in these cases off the hook.
Why is it when the accounting profession makes spectacular mistakes that take down entire Fortune 500 class organizations, there is a critical analysis of the processes that led to these failures, and remedies often comprise prescriptive measures for these processes, but similar analysis for software failures focus upon the software flaw but not the environment that allowed the flaw to emerge? Now sometimes the remedy in the accounting case might not make complete sense (like SOX), but the point here is people don't look at just the end result (the accounting system transactions) of the accounting process.
Some outside observers, however, said they are not convinced NT is blameless.
"It still boggles the mind that any divide by zero error on NT would cause a system to crash, let alone" 27 end-user terminals, said Gil Young, corporate network engineer for a systems integration firm in Orlando, Fla. "I don't care what operating system, computer or application I'm using, I should be able to type in a zero and expect the computer not to crash, especially if that zero is to represent a closed valve."
Look, I write software for control systems (and I design them electrically too). Just because programmers at Microsoft or EA Games have tight schedules where they are just too stressed to write code well doesn't mean all code needs to be written like that.
Back to what you were saying, if you have a system that could cause damage or whatever, then you start by writing your output routines, and you create rules to govern the machine (i.e. outputs A and B can't come on at the same time, or output C can't exceed this value). Then you write another module that monitors the inputs AND outputs looking for fault conditions that shuts down the machine if you do anything dangerous. Only this part of the code needs to be signed off by an engineer. Typically it's simple code, and easy to prove correct, with peer review. Then you write other modules that essentially make requests through the safety checks to do anything. You don't have to review the complex other code so much, because your output stage should catch any mistakes.
That's how you make a machine safe. Unfortunately, most engineers I know just go out and write the software figuring there's no difference, and that's how bad things happen. It comes from believing you won't make a mistake, or believing that testing will catch all problems. If you plan from the start that you're going to be making mistakes, you can catch them before damage is done. It's too bad this isn't taught, even in the software engineering classes I took at a Canadian university.
"I have never let my schooling interfere with my education." - Mark Twain
1. Design reviews, by peers and independents
2. Code reviews, by peers and independents
3. Regulary, organized, unit testing
4. Correctness proving
5. Documentation is about a bazillion forms
6. Defect tracking
7. Effective software process metrics measurement and improvement
8. Continuing education
9. Humility / egoless programming
This list was assembled in about a minute off the top of my head. I work in a CMM3/4 type organization, and although there are processes for these things, most people don't use them, or consider them a hassle.
So my point is, the parent is right -- creating good software, even when done by properly trained experts with great experience -- is hard. But the grandparent is right too -- doing all of the above to 'do it right' takes time and money, and many organizations, and by this I mean software process management as well as the actual engineers, don't understand the value / aren't willing to pay for or aren't willing to do all that work. And occasionally, as the article shows, the piper comes and takes his payment.
In Soviet Russia, us are belong to all your base.
Engines have existed for centuries. Roman engineers, for example, built siege engines (ballistas, and the like).
Dictionary.com
Engineer
[Middle English enginour, from Old French engigneor, from Medieval Latin ingenitor, contriver, from ingenire, to contrive, from Latin ingenium, ability. See engine.]
Engine
n. 1.1. A machine that converts energy into mechanical force or motion.
2.1. A mechanical appliance, instrument, or tool: engines of war.
[Middle English engin, skill, machine, from Old French, innate ability, from Latin ingenium. See gen- in Indo-European Roots.]
My guess is that the operator really wouldn't know either (although, she would probably assure me that it "it's very safe").
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
You mised one..
Item 0: Requirements reviews by peers and independants. If you don't have good requirements you obviously don't know things well enough to be building them. Sure you can catch some requirements issues in 1 and 2 but the longer you wait the costlier it is to fix.
A MSCS is NOT a Software Engineering Degree, so why WOULD you take courses in SE?I'd say that CS and SE are two different professions. There are places to get a MS SE (Texas Tech comes to mind) if you are interested.
Some of the bugs they listed are not truly bugs.
Soviet Gas Pipeline...This was a desired feature working just as intended (unless they CIA didn't want to blow up the pipeline)
Buffer Overflow in Berkley - a worm is not a bug. it is a program designed to infiltrate a system and do something. While the people utilizing the program may not have intended this to happen (duh) the makers of the worm did.
A bug is an unwanted aspect of the code as implemented by the people who wrote (or edited the code) but this does not include something affected by a virus/worm. A program that crashes every six minutes for no apparant, or intended reason has a bug...a program that gets infected by a virus which causes it to crash every six minutes is not a bug. Also, a piece of code that is intentially inserted in the hopes of crashing a system is not a bug...it is a feature. It may be undesirable, but it is a feature.
I mod down so you can mod up. Your welcome.
Some person down the line noticed that the Russians didn't have that many missiles, couldn't have launched them all with such synchronization, and that there were an awful lot of two's in the report ... actually, every digit of every number was a two. It turned out to be a fried chip somewhere, always pumping out the same bit regardless of input (I have no understanding of the technical side of the issue; maybe it hit the 32-bit limit and the int->string function reacted with 2's).
Good thing we were not too automated, and that we employed somebody smart enough to critically examine his printouts.
Disclaimer, this is a favorite tidbit of one of my professors ... I have no real source to refer to.
Use my userscript to add story images to Slashdot. There's no going back.
That works great for the kind of machines you described, and I wasn't saying good code couldn't be written, I'm saying that it isn't usually written, and won't be written in off the shelf software. The problem is, if you look at something like a mars lander, then you can't just shut it down if it gets some bad inputs. Also, even good inputs can result in the the machine not doing what it needs to do. If it has to land on mars, and some input tells it to fire the left rocket for 4 seconds, then the input may fall within proper values, but may push it way off course. There's no GPS in space, so you can't get your position very accurately, and if you go way off course, you may not have enough fuel to get back on course.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Guess what: They don't, although they appear to be hedging their bets with safety critical software.
An interesting read...
"Prepare for the worst - hope for the best."
It really doesn't matter what language you use: bugs can be written in any of them. In this case, the customer wanted a GUI workstation running on Windows, with the possibility of being cross-platform. Java was new and cool (1.1 had been out for six week when we started), and they decided to give it a shot. This is a company with fifty years experience in medical systems, not some dotcom startup, so the procedures are in place to make sure that their products don't kill people.
As it turns out, JDK1.1 (along with a native-C library for quick image processing, and a custom PCI card for doing 30MB/sec image transfers) was just fine for the task. We had a team of seven testers working on the project full time for a year, and were able to ship with zero severity 1-2 defects.
We set a new record for lowest defects/KLOC at the customer (a major player in the medical systems industry), despite running JDK 1.1 on Windows NT 4. Our product was several times faster than the C-based product it replaced, had more functionality, and provided more accurate diagnosis for the patient.
Good design is the most important thing in developing good software. The language/runtime/OS can provide crutches to save you if you screw up, but bad design will result in defects no matter how sturdy the crutches are.
The problem is, if you look at something like a mars lander, then you can't just shut it down if it gets some bad inputs.
True, it's just that in my line of work, off is usually the safe state, but what should be done is to go to some kind of safe state, whatever that may be. Sometimes you revert to a manual operation, for instance.
Also, even good inputs can result in the the machine not doing what it needs to do.
Which is why you need to also hire a mechanical and an electrical engineer to design those aspects so that the mechanical and electrical systems fail in a safe and detectable way.
For instance, it used to be that stoplights were designed with a physical disk inside that rotated creating the "program" of the different lights. You also had interlocked electrical circuits so that both greens could never come on at the same time. These are mechanical and electrical ways to make the system fail to a safe condition. I have recently been at an intersection where I saw the traffic lights had green both ways (during a storm). This is because some vendor is selling a traffic light system on the market that is completely software based, and they hired a bargain basement programmer and/or engineer to design it, and we should find them and shoot them for their incompetence, but I doubt that will happen.
"I have never let my schooling interfere with my education." - Mark Twain
All you really have to do is force everyone at the company to use an include file with this:
#define gets() DONT_USE_GETS_YOU_MORON()
I think the whole thing has to do with the different spheres of knowing (IIRC - the actual title might be different):
1. Knowledge you have that you are aware of
2. Knowledge you have that you are ignorant of
3. Knowledge you are aware you are ignorant of
4. Knowledge you are are not aware you are ignorant of
So, as you move knowledge from the other areas into area 1, you tend to pull things "up" if you will. Knowledge moves from 4 to 3 as well.
2 isn't a contradiction, just that you might not be aware that some "tip" is true, or may not realize at a certain time that certain stuff you know is actually relevant to the situation at hand.
The scary part is area 4 is a default, so the less you move "up", the less you are aware that you don't know things. This is why lots of people say things like you did - the more you learn, the more you learn you don't know.
Opera, Proxomitron-Grypen,GPG 0x0A1C6EE3
"If Engineers built buildings the way computer programmers wrote programs, the first woodpecker that came along would destroy civilization."
If engineers built buildings the way computer programmers wrote programs, an average engineer would be able to build an array of radio telescopes by himself in one evening. A team of 30 engineers would be able to build a ringworld in 3 months.
i.e. it would be nice if software were like designing an office, where there were 3 architects, 5 engineers, a building inspector, and 50 professional workmen to examine a system containing just a few hundred variables, and almost identical to the last 20 buildings they'd constructed.
And in case that didn't start a flamewar, how about...
"Just one unexpected input (of an aeroplane) caused the failure of two of New York's biggest civil engineering projects -- imagine how they'd cope with being attacked every 3 seconds like some internet software"
"Dude, focus here - democractically elected - not sham election"
Right, and you verified the elections of these people how? let me give you an example, Hugo chavez led a military coup to take over his country and then later was "democratically eleced" according to Jimmy carter. I am going to assume you consider his government legitimate.
I can tell you one thing, if the US hadn't intervened in many of those countries, the wouldn't have free democratic govenments today. It is far easier to remove a dictator who is just a man than it is to eliminate an entrenched political party/idea like communism. Compare N. korea to S. korea or taiwan to china... etc etc.
The war with islam is a war on the beast
The war on terror is a war for peace