Examples of Programming Gone Wrong? 674
LightForce3 asks: "I'm a beginning CS student, and in my studies I've come across examples of programmer error causing very large problems, such as the Ariane 5 failure and the Therac-25 accidents, often as tales of caution to beginner programmers such as myself. My (morbid?) curiosity has been piqued, and I'm looking for other examples of programmer error leading to serious problems. After all, it is better to learn from the mistakes of others than from your own, right? ;) What programming-related accidents, incidents, and failures, both well-known and obscure, do Slashdot readers know about, and are there any good resources for researching these?"
On Fox tonight @ 8pm (Score:4, Funny)
Re:On Fox tonight @ 8pm (Score:3, Funny)
Once on TV there was a documtary on a history of computers, talking about Pascal, father of computers, the first programmer, the first vacuum tube computer, and....the first (real)bug found - in closeup shot!
I found this extremely amazing and couldn't even move my eyes away throughtout the show. Then I found my wife and my mother-in-laws fell into deep coma on sofa...
Damn! I should have taped the show!
The book "Fatal Defect" (Score:5, Informative)
Mars Orbiter Lost Over Metric Conversion (Score:4, Informative)
Mars Orbiter Lost Over Metric Conversion (link) (Score:2, Informative)
Here are my Top 4: (Score:5, Informative)
2.) Intel f*cking up floating-point calculations in one of their chips [intel.com]
3.) High-tech toilet glitch (no, really!) [ncl.ac.uk]
4.) Windows ME [microsoft.com]
OT: Scuds and Patriot missile defenses (Score:5, Interesting)
Bottom line: that stuff about the floating point error in the PAC-2 system looks neat on paper but it's not at all clear that the faulty calculation was responsible for the loss of life.
GMD
Re:Toilet glitch (Score:5, Funny)
This appeared in today's (2/17) Seattle Post-Intelligencer:
It was a flush with a rush.
Toilets and urinals in the King County Courthouse exploded yesterday after a worker in Metro's downtown bus tunnel mistakenly connected an air compressor to the building's water line. As soon as hapless individuals flushed the pressurized privies, the plumbing started popping in restrooms throughout the 72-year-old building, said building services manager Bill Kemp. "They started blowing at about 11:30 (a.m.) and it took us awhile to figure it out," he recounted."We knew it had to be air in the system but the Water Department said that was impossible." It wasn't. The source of the problem was finally tracked to the tunnel under Third Avenue, and the errant air compressor was shut down. But not before employees on every floor in the 10-story courthouse had stories to tell about gushing geysers in the john. "We think we've lost about 20 to 25 toilets," said Kemp. "The porcelain is actually cracked." Kemp said no one has admitted being hurt by the unusual blast, although several people were badly drenched. Or very surprised. Explained Kemp, "The urinals acted more like bidets." We had other reports that people were not necessarily on the toilet but close." "This has not exactly been a good day for Metro," he noted. by Mary Rothschild --P-I Reporter
link [netfunny.com](story is near bottom, pun intended.
Re:That is NOTHING -- 10,000 died in Bhopal, India (Score:3, Insightful)
Re:That is NOTHING -- 10,000 died in Bhopal, India (Score:5, Insightful)
"In 1969, as part of its global empire, Union Carbide Corporation set up its pesticide formulation unit in the northern end of the city of Bhopal in central India. Initially it mixed and packaged pesticides imported from the US but was gradually expanded. In December 1979 its Methyl Iso Cyanate (MC) plant with an imtalled capacity of 5000 tonnes went into production.
On the night of December 2, 1984, during routine maintenance operations in the Methyl Iso Cyanate (MC) plant, at about 9.30 p.m., a large quantity of water entered storage tank no. 610 containing over 60 tonnes of AEC.
This triggered off a runaway reaction resulting in a tremendous increase of temperature and pressure in the tank and 40 tonnes of MIC along with Hydrogen Cyanide and other reaction products burst past the ruptured disc and into the night air of Bhopal at around 12.30 a.m. Safety systems were grossly under-designed and inoperative. Senior factory officials knew of the lethal build-up in the tank at least one hour before the leakage, yet the siren to warn neighbourhood communities was sounded more than one hour after the leak started.
By then, the poisons had enveloped an area of 40 sq.kms. killing thousands of people in its immediate wake. Over 500 thousand suffered from acute breathlessness, pain in the eyes and vomiting as they ran in panic to get away from the poison clouds that hung close to the ground for more than four hours."
Nothing to do with programming errors here that I can see. Sounds more like gross negligence and incompetence to me.
-A.
Re:That is NOTHING -- 10,000 died in Bhopal, India (Score:4, Informative)
And yes, this has nothing to do with programming error
Re:That is NOTHING -- 10,000 died in Bhopal, India (Score:3, Insightful)
10,000 dead in Bhopal, India != Concern (Score:3, Funny)
When something like this happens, it's little more than an embarassing public relations problem. If the news can't be completely supressed through advertising, perhaps it can be kept off the evening news and relegated to the back pages. It requires a well-coordinated PR firm, but hey that's what they're around for.
Sure, a few independent news agencies might pick it up and make a big deal about it - until someone goes whaling or starts cutting down redwoods. Few people pay much attention to the independent media anyway. Joe Sixpack doesn't subscribe to The Progressive.
On the local front, shut down the plant, and evacuate your American/European workers. Split them up and transfer them around. If someone makes noise, force them to sign an NDA for their severance packages. Spread liberal bribes on the local front, write the whole venture off, and wait for the hubbub to die down. If you want to stay in the region and resume operations, do so under the umbrella of a subsidiary. If it's too risky, simply relocate to another third-world region. It's not like there's a limited supply.
Unless you stay in the region, you really don't have to worry much about the local population. They're too poor to pursue legal action or be a security threat.
Besides, it's not as if they're white Christians, is it?
</sarcasm>
RTM Worm (Score:5, Interesting)
You forgot the part that went wrong. (Score:3, Interesting)
Had that been the case, it would have been much more widespread and caused much less damage.
Re:RTM Worm (Score:5, Interesting)
RTM had been aware of the possiblilty, and implemented a fix- but he did it wrong. He'd created code so that a new worm, when first arriving at a host, could check if a previous instance of the worm had been there. If so, it could abort its infection process.
However, he was afraid that this would make vaccinating machines too easy (by sysops faking the "already infected" flag), so he created a 12.5% random chance that an incoming worm would ignored the fact that a machine was already compromised and infect it again. That probability had NO rational basis behind it, (in fact the whole idea of using randomizing like this is flawed), and served to postpone the shutdown of the internet by at most an hour.
This was an especially bad blunder because it set a frightening example of what hackers could do. If RTM had used a 100% chance of non-reinfection, (and played his cards right from then on), he'd have been hailed as an innovative security analyst who'd prevented security-compromising violations of the Pentagon's systems. Instead he was tossed in prison for years.
Y2K? (Score:5, Insightful)
Re:Y2K? (Score:4, Funny)
Yeah, we fleeced 'em pretty good, eh. We should do that again in 2038 in order to pad my retirement account!
You just can't win, can you... (Score:4, Insightful)
If the Y2k bugs hadn't been fixed, things would have broken left and right, and we would have been blamed for not fixing them ahead of time.
Since the Y2k bugs were fixed, very few things broke, and we got blamed for wasting tons of money to no effect.
C'est la vie, I guess.
Re:Y2K? (Score:3, Informative)
Re:Y2K? (Score:4, Funny)
Hey we sold you this! Top of the range! But it's broken, even before we sold it to you. If you pay us £500000 we'll fix them all, but if you don't your blood will boil and your head will explode, all your kids will die of pestilence, your wife will sleep around, your plane will try to reach the moon and all your elevators are belong to us.
Look out.... (Score:3, Funny)
Careful. Quoting from a Microsoft EULA like that without proper attribution could get you tossed into jail for a DMCA violation, sport.
How about the AT&T Switch failure in NY? (Score:5, Informative)
It was a bad break in C code (Score:5, Informative)
See RISKS Digest (Score:2, Informative)
This is probably the broadest and best source for this kind of information.
Risks digest (Score:5, Interesting)
As far as other death-inducing systems go, you might be interested in, computer controlled plane accidents (airbus, anyone?), unmanned trains, and nuclear reactors are some classical favorites.
Also on UseNet (Score:3, Informative)
news://comp.risks
Xix.
One time this guy (Score:5, Funny)
tried to write a peice of software called Slashcode. Look at what happened.
Pleanty of examples here: (Score:2)
Shared Source [microsoft.com]
Just fill out the forms, sell your soul, and you can browse programming errors for rest of your natural life - and that's supposing that viewing this code won't make you slit your wrists in dispair.
I had a professor (Score:5, Funny)
Re:I had a professor (Score:5, Funny)
I can't help thinking that a fairly high percentage of current Microsoft employees must be former students of his.
RISKS Digest (Score:4, Informative)
Google's RISKs Archive [google.com]
Why, the world's favorite mail client, (Score:5, Interesting)
Outlook!
Built with the idea that code in attachments should be executable, often automatically. Also full of exploitable bugs, to get even more stuff running automatically, regardless of who who sent it. Responsible for a huge amount of damage by all sorts of worms, trojans, etc.
Someone, somewhere got the idea that email would look better with html; and if it got html, it should get scripting too, that's consistent with web pages! And it's cool if attachments (like pictures) can be opened in their appropriate program automatically - let's run any executables then, that's consistent!
This is oversimplified, but I really feel that this is a case of stupid consistency that caused multi-billion dollar damage. Email should never be executed by the mail client.
Re:Why, the world's favorite mail client, (Score:4, Funny)
Re:Why, the world's favorite mail client, (Score:5, Insightful)
That was an easy setup (Score:5, Interesting)
Oh wait... -1 Redundant
Here's a good site [tu-muenchen.de] though with tons of examples.
My favorite would be the infamous [fas.org] time when NASA did half its calculation in metric and the rest in SI. ;)
F-bacher
Re:That was an easy setup (Score:3, Informative)
Re:Thanks! (Score:3, Funny)
Failures (Score:4, Informative)
Pretty sure this was posted earlier on slashdot (Score:2, Informative)
Anyway, here are a couple of links.
Software horror stories [tau.ac.il]
More horrors [yorku.ca]
A Great Story (Score:5, Interesting)
A company was hired to rewrite the code that was used on one of the models of fighter jets, and they offered to fix an unusual bug.
The details are: apparently they had two altimeters - one was barometric, and the other I don't remember.
Anyway, the programmer was coding along, and was writing code to determine what would happen if the altimeters stopped functioning.
He came to the case where they both weren't working, and couldn't figure out what to do, so called one of the pilots that was acting as an information source for the developers, and asked him what altitude they normally flew at, and he answered, "12,000 feet" or something similar.
So the programmer wrote,
if altimeter1 not working
{
if altimeter2 not working
{
set height = 12000;
}
}
Stupid, but this code could not be changed. The pilots had the following rule deeply ingrained: if the altitude stays at 12,000 for more than a few seconds, pull up, as your altimeters aren't working.
That's kind of silly (Score:4, Insightful)
F-bacher
Re:That's kind of silly (Score:4, Informative)
In most areas of the world (unless you're flying over the Dead Sea, or Death Valley, or New Orleans), if your altimeter reads 0, you're probably already dead. Altimeters used for navigation read MSL (height above mean sea level), not AGL (height above ground). There are radar altimeters that read in AGL, but these are used for close-to-ground maneuvers like landing.
Re:That's kind of silly (Score:4, Interesting)
This isn't variable initialization, but the principal replies. Data that you know are junk should look like junk! Trying to "fake it" or make it "look good" is exactly the wrong thing to do.
-Peter
Re:A Great Story (Score:4, Informative)
Re:Why this cant be right... (Score:4, Insightful)
Re:Why this cant be right... (Score:4, Informative)
Shared download class (Score:5, Funny)
We always had problems with downloading files from the site.... the files kept getting corrupted, and occasionaly, a member would complain that they tried to download a powerpoint presentation and ended up getting 4 way anal porn.
This perplexed the developers, and it was not until 9 months after going online with the site, did they realise that the java class that dealt with the downloads was a single process shared by all users!
So, your download would go ok IF nobody else tried to download at the same time. If two people clicked download at about the same time, you would download the file that the second person wished to download.
No wonder they went bankrupt
Easy, (Score:5, Funny)
Don't be so narrow (Score:5, Insightful)
What about when the construction crew quietly substituted what they thought was an equivalent design to what the computer program came up with for a skywalk over a hotel lobby?
After almost 20 years in this field, I think that at least 80% of the serious "errors" I see are because the user didn't understand the results of the program, and only 20% of them are due to classic development errors.
The lesson to learn from this: the user interface matters. Give some thought to presenting the information in a meaningful manner (e.g., the infamous pre-Challenger graphs showing O-ring erosion vs. the post-Challenger graph that mapped damage by temperature at the time of launch), and allow users to see the information in the way that makes the most sense to them.
Re:Don't be so narrow (Score:4, Insightful)
Train collision (Score:5, Interesting)
Once such accident, in Mexico, was caused by an unexpected combination of several simultaneous failures. One day, for some reason, one of the servers needed to be reset. At the same time, two freight trains were stopped at a switch, in the process of what's called a "pass," where one train turns off onto a side track to let the other train pass by on the main track. Long story short, the status bits of the switch got lost during the server reset (there is a provision for restoring track states when the backup servers take over, but it didn't work for some reason). After asking if the track was clear, the driver for train1 recieved a green light from the dispatch office. The dispatcher, not knowing that train2 hadn't cleared the switch yet, figured everything was ok. The trains collided at very low speed, and not head-on, but nonetheless the collision cost the rail line several million in equipment and downtime. No one was hurt.
The lesson: When writing bullet-proof software, check every possible condition! More extensive field testing would have caught the failover bug.
Re:Train collision (Score:3, Insightful)
Non-life threatening, but interesting bug... (Score:5, Interesting)
Let's just say that two years ago a very large international shipping company suffered two days of worldwide failure in the package routings printed on labels. The bug was caused by an incorrectly placed paren in an index offset calculation, leading to truncation of an intermediate result (to a 16 bit unsigned int, when it should have been 32). The bug sat dormant for five years because the result matrix it was indexing into was smaller than 64kbytes. As soon as it grew over that size - boom! What a way to wake up at 2am when the Asian-Pacific region starts calling...
I didn't make it, but I was definitely involved with the fix. After that we did some very thorough auditing on all of the routing code - and fortunately didn't find any other surprises lurking.
Airbus (Score:5, Interesting)
In the Airbus if the pilot tries to correct (use the flight controls) while the computer is engaged the computer will correct the pilot's correction. Unlike in a car with cruise control where if you hit the breaks it just cuts the cruise control. Many China Airlines planes have crashed due to poor pilot training in this regard. They weren't trained well enough to shut off the computer control before taking control of the plane.
I'm also sure someone can be a little more detailed than this, but it is, IMO, at least a design error that has caused hundreds of deaths.
As a side note, my Software Engineer professor refused to ever fly on a fly by wire plane, and was opposed to SDI simply because he didn't beleive that either had been or ever would be debugged properly. (if there is one error in every 10,000 lines of code, and it has 3 or 4 million Lines of Code, how many errors is that? His answer: too many to trust)
Re:Airbus (Score:3, Informative)
I've got a course for you (Score:3, Interesting)
deep c secrets (Score:5, Informative)
The 1993 $20 million SunSoft Asynchronous I/O bug.
The 1961 Fortran subroutine used to calculate orbital trajectories at NASA for several Mercury flights.
A discussion on the 1988 RTM worm.
Sun's first internationalized Pascal compiler corrupt date strings.
1961 Mercury software failure (. used instead of
1962 Mariner 1 software failure resulting in $12 million rocket and probe destroyed.
among others.
Re:deep c secrets (Score:3, Interesting)
So I looked this one up [ccu.edu.tw]:
Uh, right... bounced on the key. The story is very light on details as to what the problem was, how they found it, how it slipped past QA, etc, but clearly this was a PROCESS error and not a design flaw.
If a software bug is holding up the shipment of $20M worth of hardware, then Sun had some real serious problems besides shoddy programming. You don't commit millions of dllars to building hardware when you know there's a bug somewhere. that's just absurd.
The programmer is really the last person to blame for the $20M backlog. I'd blame QA for signing off on the code, I'd blame the C language and their compiler for letting such a stupid typo slip through without a warning, and I'd blame the suits for trying to fit the software development cycle to their hardware release cycle. If the programmers are to blame at all, it's for structuring the program in such a way that such a bug could easily slip through - the typo itself it forgiveable. With just a few assert()s here and there, this kind of bug is almost impossible to write.
You just DONT build production hardware when the software isn't ready yet. The system needs to be tested as whole. If the hardware works with a previous rev of the software, then that's all you ship, period.
Re:deep c secrets (Score:5, Informative)
This was a real bug in Sun's async I/O library back in 1993. The bug had nothing to do with hardware. It had to do with sales. There was one specific customer who had some software that used the async IO library.
By bad luck, their code tickled this bug (caused it to manifest). As a result, their application failed. By chance, they were on the point of buying $20M of sun servers. Recognizing that they had a huge amount of leverage, they told the salesman "Gee, we'd really like to sign the purchase order, but our app doesn't work, and we
think it's a bug in your library."
The salesman called thru to the kernel group and explained what was happening. The right developer (probably Dan) put aside ten other urgent things, and searched for this problem. It was not easy to find, but he did find it quickly, and issued a patch the same day. This almost never happens, but $20M is $20M.
The customer tested the patch, and everything worked perfectly. The customer was happy. We were happy. And the salesman with the commission on $20M of server hardware was happiest of all.
I don't understand that suggestion that "you just DONT build production hardware when the software isn't ready yet". Software is never ready. The FCS date is just a milestone on the continuum of evolving and improving the software. The truth is that all systems from all computer manufacturers are developed to the hardware schedule, and they ship as soon as the hardware is ready, in whatever state the software is.
One of the biggest sins you can commit as a software developer is to cause a slip in the overall product because the software isn't ready.
There are excellent economic reasons for this, but they are too long to go into here.
I was going to write a new book based on my experience developing OS software for the SunBlade 100 and 1000 workstations. But to my astonishment, Prentice-Hall were wishy-washy on the project.
I still think it would have been a terrific book, but it is such a large amount of work to write a book, that I am not going to take it on unless the publisher is 100% behind the project.
My working title for it was "The Whole of a New Machine - How we built the world's fastest desktop computer" (which it was at the time it launched).
I did develop the book synopsis, and wrote the entire first chapter. I put them on the CD that comes with the 5th Edition of "Just Java" if you want to see them.
---
BTW, "Expert C Programming" gets the failed rocket software details 100% correct, unlike some of the corrections below.
Bye bye credit purchases (Score:3, Interesting)
Unfortunately this was not her first or last mistake of this magnitude. Retailers often see IT as an expense rather than an asset and are as cheap as possible. This has a tendency to cause shoddy programming since they hire as few programmers as possible and overwork them and often software is put into production without being thoroughly tested. At least this was the case when I worked in retail some ten years ago--I don't think I'll do that again.
But I am finding that insurance companies have the same philosophy.
I can't recomend comp.risks too highly (Score:3, Informative)
Risks To The Public In Computers And Related Systems
http://catless.ncl.ac.uk/Risks
On how to be 0wned by other people: Counterpane: Crypto-Gram . Shares with comp.risks the reframe of "I can't belive people don't learn from this"
Counterpane: Crypto-Gram
http://www.counterpane.com/crypto-gr
Don Norman's _The Design of Everyday Things_ and website also offer insight on how to avoid UI failures relating to failures.
http://www.jnd.org/index.html
Also, get a copy of _Code Complete_ and/or _Code Write_ by Steve McConnell [pub: Microsoft Press Which is rich irony) Lots of mistakes and how to avoid them.
The cautionary note might be that most of these failures are human related at some level. Whether it be at the project level, or the UI level -- there are lots of ways to cause a failure.
Finally, avoid any kind of carreer in Software QA. There is no better way to just get kicked around at the expense of the people putting the bugs in the software in the first place.
NASA software bugs (Score:3, Informative)
Regarding the loss of the Mars Climate Orbiter spacecraft [nasa.gov], from nasa.gov: "The 'root cause' of the loss of the spacecraft was the failed translation of English units into metric units in a segment of ground-based, navigation-related mission software"
Also, here are several [nasa.gov] "software bugs" (their words) relating to the Mars Surveyor Lander Vehicle are described. These bugs were detected and fixed in the field (ie, Mars). At least one of the bugs caused a heater failure in the vehicle on Mars. This failure was recovered from.
Anyways, those are just two quickies, but NASA has their share of bugs. (And generally some pretty ingenious ways to reprogram and update vehicle software post-launch.)
On a related note, here's a paper from NASA entitled "The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software" [nasa.gov].
Always Mount a Scratch Monkey (Score:3, Insightful)
http://www.acme.com/jef/netgems/scratch_monkey.htm l [acme.com]
-calyxa
Good site (Score:4, Informative)
http://wwwzenger.informatik.tu-muenchen.de/perso ns/huckle/bugse.html
Insidious bug from the wayback machine (Score:3, Informative)
if(c=='\')
slashfound=1;
++index;
Code similar to this delayed shipment of a commercial product because it caused serious instability.
Re:Insidious bug from the wayback machine (Score:4, Informative)
One of the best resources I've found (Score:5, Informative)
Some of the tips, which may appear obvious to some of us, include:
Airport flight schedules (Score:5, Funny)
Here are some of the best examples of windows crashing on high visibility systems that are relied upon:
in the street [squidly.org]
At the airport [bloomu.edu]
at the atm [piemaster.co.uk]
on CNN [piemaster.co.uk]
At disneyland [piemaster.co.uk]
On your phone [piemaster.co.uk]
In an airplane [pyroxpro.com]
At the bus stop [dropbear.id.au]
Lets Not Forget the Best... (Score:5, Funny)
cause we all know 50 + 1 - 1 = 49!
Ok, that was lame, go ahead and mod me down...
Mars Pathfinder (Score:3, Interesting)
You can read about it from James Gosling's home page [sun.com] (also has info on Arianne 5 [sun.com]).
Luckily the engineers were able to upload a patch to Mars. That's remote debugging/patching for you :-)
F-16 AOA and WOW (Score:4, Interesting)
First, BEFORE YOU LEAVE THE GROUND, pilots are taught that instruments don't lie. Specifically, when the human inner ear is placed in flight, things go wrong (the inner ear canals are static, not dynamic, devices; the fluid has no dampening or rate sensors). When there is no external reference, the inner ear canals adjust to the eye's visual presentation. It's called the 'leans.' Bad joo-joo. Many a perfectly good aircraft has been flown into the ground because the pilot believed his ears and eyes and not his instruments.
Second, IN FLIGHT, angle-of-attack (AOA) is a spectacular indicator of where your airfoil exists within (or outside) the flight envelope for your aircraft. Inside the flight envelope, you can seek best range (mpg) or best endurance (loiter) or best climb.
In most aircraft, the angle-of-attack indicator is a manual instrument (on the skin is a sensor which looks like a big euro-style handle and it runs to an indicator in the cockpit).
Many pilots are correctly taught to 'fly' the angle-of-attack.
Third, ON THE GROUND, when you land, you use the aircraft shape as an airbrake. You hold the aircraft nose off the ground as long as possible to create drag.
Fourth, ON THE GROUND, when you land, you do not want to hold the aircraft nose too far off the ground or the tail will scrape the runway and your fitness report will reflect and you'll be the butt of bad jokes at Snopes for eternity.
The AOA is used to assist in the performance of aerodynmic braking. The aircraft performance manual publishes the tried and true range of AOAs for aerodynamic braking. [It also indicates when too much AOA will ding the aircraft.]
Aerodynamic braking is part art and part science and requires accurate instruments.
Enter the F-16
F-16 pilots were taught to fly the flight direction indicators to land.
However, many old and new pilots fell back on the old AOA once the wheels touched the ground to do aerodynamic braking.
Suddenly, F-16 tails were scraping along the runway at an alarming (and expensive) rate.
[As an aside, the problem was probably ignored until a senior officer ground off a few inches of aluminum THEN there was a problem.]
The programmers who wrote the AOA routines were rightly told that the AOA is used in flight. So, when the AOA detected that the aircraft had placed weight on the wheels (weight-on-wheels - WOW), it was programmed to quit working. Unfortunately, it kept the last AOA reading
Pilot flies, pilot lands, pilot believes instruments, pilot scrapes multi-million dollar aircraft's tail along runway.
The programming solution was simple: when there was WOW, fade the AOA.
This was another case when contracts pit spec wording against spec intent against functional application and understanding of how it's supposed to work
"Why did they call you 'sparky' and why are you driving school buses in North Topeka?"
My favourite quote on the subject (Score:3, Funny)
-- Nathaniel Borenstein
New Slashdot Category? (Score:3, Insightful)
Could we have a new Slashdot category entitled Ask Slashdot To Do My Research/Homework For Me? Then I could mark this category unread and avoid some annoyance.
There is so much information readily available on the subject of software failures online and in scientific and popular publications. (See other responses to this question for examples.) IMHO, the questioner should go look for the answer to this kind of question directly before bugging the entire Slashdot audience; the editors should enforce this policy.
Re:New Slashdot Category? (Score:3, Insightful)
London Ambulance disaster (Score:3, Insightful)
The system did not collapse per se but progressively became bogged down by a series of poor design issues and implementation issues.
What happened was there was a memory leak, in that not all the memory used when a call was processed was released. This meant that each call chewed up a small part of core.
As the day wore on, this loss of memory started to make the system run slower, and created more calls as users started to worry about the non-show of the ambulance.
Meanwhile, back at the control centre, the operators started getting blasted by messages about over-due ambulances, and other system warnings. They were spending time simply dismissing Error dialogues.
By the end of the day, they were still dealing with the emergency issues notified at 12.00.
Of course, in the inquiry, there were many different management and design issues to be addressed, including the reliability and scalability of the software. [It was a Visual Basic program.]
I have seen a number of instances personally, most of these tend to be ignored by management keen to see the system up and running. The most often case for dismissal of problems is "teething problems", and "Luditism".
In practice, the real issue here is the UI. Not so much "flash chrome", but that the buttons and so forth will actually do what the user expects them to do. The user must be able to understand how to process and correct errors in relation to the application data itself. That is, if I enter 1200, and I mean 1130, I should be able to correct that.
The other disaster happening out there is that the program must be useful to the operator. So apart from entering data, the operator must be able to extract useful information from it. What the back end does does not really matter.
For example, a clerk who has to enter data on the screen each sale, in addition to operating the till, would be reluctant to use it. On the other hande, if the program is part of the till operation, and it provides information on how much stock is left, the clerk is more accepting of the change.
Implementing a system is not about plonking a pc with a program on a user's desk. It's about a user process. Users are looking for outcomes, not process. So if you want to go to a shop, you want to buy something, and the clerk wants to sell it to you. All the rest is administrivia.
Software design is important. So is user training.
Computer-Related Risks by Peter G. Neumann (Score:4, Informative)
http://www.amazon.com/exec/obidos/tg/detail/-/0
Sleipner A (Score:3, Informative)
Sleipner A oil platform sank because of a bad design, caused by inaccurate computer based modelling (using an FEA tool inappropriately). In this case it was the data not the software.
Re:Challenger (Score:5, Informative)
Re:Challenger (Score:2)
Re:Challenger (Score:5, Informative)
NASA hasn't ever had a hardware problem. Or a software problem. Ever. Every problem can be directly tied to one specific person being a fscking moron. The closest you could come is that Mars probe that crashed because of mismatched units. And that was just poor communication among the software guys.
Re:Challenger (Score:4, Insightful)
Well, except for Mars Polar Lander, where the failure review board determined that the lander crashed because a flag indocating contact with the ground was not intialized to zero prior to the start of the retro-thruster loop. So the flag got set by the shock of deploying the landing legs, never got reset, and caused the thrusters to switch off as soon as they were on.
I guess maybe you forgot about Apollo 13 as well (hardware)? Or the Galileo High Gain Antenna that failed to deploy (hardware)? Or the serious telemetry system problems they had with one of the Voyagers (hardware)? Or the faulty landing bag on one of the Mercury flights (hardware)? (was it Glenn's? I don't remember) Or that funky glitch in the landing computer during Apollo 11 (software)? You know, there's a reason that most space mission tend to be heavy on redundant hardware, and invest a lot of time and effort in fault protection software.
Every problem can be directly tied to one specific person being a fscking moron.
Well yeah, but that's the case with a lot of bugs, isn't it? Mistakes tend to be people issues.
The closest you could come is that Mars probe that crashed because of mismatched units. And that was just poor communication among the software guys.
You are at least correct about that - the problem was not a software issue. Lockheed Martin Astronautics was on contract to supply everything to NASA in SI units (which is what NASA uses for everything). LMA - or at least the part the caused this problem - uses English (Imperial) units internally, and neglected to perform the appropriate conversion before they sent the data on to NASA.
Re:Apollo 1 / hardware fault (Score:3, Interesting)
I've read in-depth technical analyses of the Apollo fire, and I have an MSc in Physics.
Before that, *no-one* knew that a spark in one place could cause a fire TWO FEET AWAY.
(You get little hot bits of burnt dust floating around in a pure oxygen atmosphere, and they keep themselves hot enough to set something else afire quite a ways away. Of course things are *easier* to set fire to in that atmosphere as well.)
Re:Challenger -- AT&T had the biggest gaff. (Score:2, Interesting)
http://www.soft.com/AppNotes/attcrash.html
Re:already.. (Score:5, Insightful)
You people who say "use google to find it" or "this was already asked" are worse than the people who actualy ask the question.
Their only problem (if it could be said to be a problem) is ignorance, your kind however are a much better example of the problem of self-rightous lazyness.
Re:already.. (Score:4, Funny)
Re:already.. (Score:5, Insightful)
Problem is, the slashdot search engine sucks. I haven't yet been able to query the archives and actually find what I'm looking for without needing to dig through hundreds of irrelevent discussions. Sometimes I think it might be faster to just scroll back through the "Older Stuff" section.
Or we could just have another discussion about it.
Re:already.. (Score:5, Informative)
Using google's serach engine provides better results for slashdot.org that slashdot's own search engine
Re:One Word (Score:5, Informative)
How about citing an actual example of windows code bugs causing big problems? I'll go first. The USS Yorktown [gcn.com] had to be towed back to harbor when the NT system that was automating most of the ship crashed.
not true (Score:4, Informative)
Re:not true (Score:5, Insightful)
Re:not true (Score:5, Informative)
in the navy's case the crashed program was enough to call the computers "down", and that makes sense too. the only thing that doesnt make sense is the attribution of blame to the OS for an app problem.
How is an app the fault of NT? (Score:5, Informative)
Much as I dislike NT, especially in critical environments, this problem [info-sec.com] had nothing to do with NT. It had everything to do with bad coding.
As we all know, information systems are only as smart as people make them. In the case of the USS Yorktown, an admin/operator entered data which caused a divide by zero condition in the application. Because the application did not have any exception handling built into it for a divide by zero condition, it died.
You can't blame the OS for this. The application should have had exception handling built into it in a couple of places. It probably should have checked any new entries before comitting them to ensure the new data would not introduce such a condition, and the app itself should have had appropriate error handling to prevent a panic/dump when a divide by zero condition was encountered.
If the app was coded by the same people on another platform, the end result would have been the same.
Wind was the *cause*. . . (Score:5, Insightful)
An extended bolt puncturing the gas tank during a rear end collision was the *cause* of Ford Pintos exploding. The *fault* was with the design, and hence, the designers.
Both of these items could have been claimed to be perfectly free of design flaws while being used as "intended."
This argument did not help the designers in not being found liable for their design flaws.
The divide by zero error was the *cause* of the operating system's failure. The *fault* was with the operating system. The *operating system* crashed. An operating system failure is *always* the fault of the operating system, and hence, its designers.
Read any textbook on the design of operating systems and in the first page or two you find some sort of statement along the line of, " A faulty app should never cause the operating system to fail." This is correct design.
Let me repeat. If an app fails, it is the fault of the app. If the operating system fails, no matter what an app has done, it is the fault of the operating system. An operating system must *assume* apps badly written by complete incompetents.
It doesn't matter what operating system. Windows, Linux, Mac or just the beads on your abacus.
* It is the responsibiltiy of the operating system not to fail.*
The fact that such failures can be explained away as the fault of the app by people who should know better makes me grieve for the state of engineering these days. It can only result in products being produced with greater and greater "craposity" factors eventually resulting in a culture of complete "crapitude."
KFG
Re:How is an app the fault of NT? (Score:3, Informative)
Re:One Word (Score:3, Insightful)
Re:the harrr-rrrrror (Score:5, Informative)
US shooting down Airbus 320
You're referring to the destruction of Iran Air flight 655 by the USS Vincennes near the Strait of Hormuz, on July 4, 1988. For one thing, it was an Airbus A300 (bigger and older than an A320). The failure there was mostly in human decision making, not in the AEGIS radar system, which faithfully reported that the airliner was travelling at 450 knots on a steady bearing towards Vincennes, roughly four miles outside the commercial air corridor, and not broadcasting IFF information (which of course they wouldn't, as a foreign civilian airliner). It was the officers of Vincennes who interpreted this information as a threat, misidentified the target as an Iranian F14, and destroyed it.
Re:Can We Say Google? (Score:3, Offtopic)
Re:Incorrect function usage. (Score:5, Insightful)
And there's a difference between not being able to code and understanding a particular function. I may read a function's man page 2 or 3 times to make sure I understand correctly what is going on. Not nessesarly because I'm incompetent, but because the wording my be confusing (wow, confusing wording in a manpage? Who would have thought..). That doesn't mean every single function for a particular language requires you to read the documentation for it multiple times. I assume nothing. Assuming something leads to bugs and insecurity. I've been programming in C for many, many, many years. When I do a little PHP programming to create some web interfaces I don't assume that just because both C and PHP have a function called strlen, and the general documentation says it returns the length of a string, that they work identically. So I read the entire strlen documentation for PHP to understand exactly whats happening. It only took less than a minute, but now I'm not assuming. I know. This goes for lots of things. The more complex functions you use, the more important it is to fully understand them.
The point is coding correctly is the most important skill to learn. I have friends that hack together scripts and programs from examples and snipits of other code and a little bit of their own code to glue it together, with little to no understanding of what they are actually doing. Then months later something breaks they can't fix and they act as if it was the author who wrote the example code's problem.
No, it's there fault. Not because they hacked together examples, but because they didn't take to the time to make sure they knew what the examples were doing, that the examples were implemented correctly, and that they understood exactly how the code in the examples worked.
Take a look at OpenBSD's philosphy. [openbsd.org]. You can learn a lot from it.
Re:Code Vaults (Score:3, Funny)
At a previous job , we where having some after work drinks, and I started fking around with a RAD app we had developed for a military contract. In a fit of semi drunken bordeom we whacked in lots of pink fluffy clouds and a "my little pony" logo on the boot up screen.
Forgot to restore it.
Next morning the mil guys came in to look at how the prototype was going, and on boot up, up pops "my little pony" with all the little clouds and all. Extremely campy.
Khaki guy not impressed.