Slashdot Mirror
Ten Technology Disasters
Ant writes "What do a 17th-century Swedish warship, an opulent Chicago theater and a Kansas City hotel "skyway" have in common? All met catastrophic ends and they have important lessons to teach today's innovators."
← Back to Stories (view on slashdot.org)
You can't breed out stupidity or rule out nasty ass-bad luck. This artical seems to infer you can do both.
You need a FREE iPod Nano
Seriously: ten catastrophic goofs, but I don't see anything which really ties them together!
Am I missing something?
Yeah, sure "Don't cut corners" and "Don't trust management who would like to cut corners", but that's pretty obvious and we all still do it, right?
There's also some stuff like "Watch when retrofitting parts of an old system with new technology" and "pay attention to boundry conditions", but really I think this is just a laundry list.
So does anybody know of a good reference work out there which actually has some worthwhile analysis on stuff like this? Didn't Feynmann write something up after Challenger?
Hexayurt - open source refugee shelter,
I don't exactly follow your chain of reasoning.
Shouldn't the first one read
Reason -> Science -> Nuclear Weapons + Nuclear Power
And the airplane one is just 'plane' silly (getit' -- I said plane instead of plain... I'm so clever). Airplanes -> bombing -> death doesn't work because people were bombing each other WELL before the invention of the airplane.
See http://www.brisray.co.uk/misc/mind.htm (scroll down) for more info.
This is what happens when you have a system that allows the corporation to run amuck.
The lowest bidder cannot be trusted to create products that are safe.
In these cases, it is good to still have some government oversight.
"Can of worms? The can is open... the worms are everywhere."
So the code threw an exception when it divided by zero: That's a _wanted_ thing (because technically dividing by zero is an error state. You don't want to just skip over something like that when it could be guiding a missile or steering the ship). From everything I've heard about that Navy ship, the fault had absolutely zero to do with "Windows NT", and everything to do with a proprietary application that didn't wrap a non-deterministic calculation in a try/except : Hardly extraordinary. Unfortunate, yes. Fodder for anti-MSitism, hardly.
There are lots of good articles in comp.risks. Try reading a few more and you'll find them. Your position is like saying "I read a Slashdot article, and the first thing I read said 'FIRST POST! W00T!'. All of Slashdot is crap."
Those are all good points.
:-)
Another problem I have seen was where TWO different bugs mostly functionally cancelled each other out causing new intermittent problems.
I made a realization regarding strict-type checking languages versus dynamic typed languages.
Typically, people who are used to java and c++ complain about languages like python - saying that the compiler should catch static type problems at compile time and that languages that do not do this are inherently unsafe.
Then I realized that ALL of these people must not be running any real tests on their code! If they were running real tests on all your code (every line must be executed in your tests), then these dynamic typing errors would be easily caught ! those would be the easiest bugs to find.
Too often I have seen C and C++ coders compile their project.... No errors! Ship it!
Another issue I have been thinking about is the relationship between code reuse and unexpected behaviours. Code reuse (and object class reuse) is fine as long as all of the functionality and limitations of the object/code are known.
However for more complex class hierarchies I have seen people say '"I'll just inherit from this class publicly and change the public interface to match what I need for this project." - And then they are surprised when other pre-written code interacts funny with it. I'm not saying object-oriented is bad - I'm saying it is so common for programmers to break the basic concepts of OOP.
I had one manager who was adamant that for any medium sized project there ought to be NO time spent on making the code re-usable. Every line of code should be directly related to specific aspects of the customer's requirements/specification document. At first I thought he was crazy.
But after I saw some projects expand into massive class hierarchies just for the sake of the illusion of increasing the reusability of the code in other projects, I am starting to side with him a bit more.
Extreme Programming has at least some very good points about it. ie: don't add features until you know you need them. Otherwise they probably won't be tested properly and won't be a good match for the new use. You can't predict every environment that the code may be reused in. It is harder to do than it sounds.
So for high reliability systems I think one should have simple non abstracted code that can be measured, prodded, and always predictable. Then you can fashion your unit tests accordingly.
--jeff++
P.S.: scary thought/rant for today: How much C++ code do you see that is striving to be exception safe so that memory full errors will be caught properly? How many C++ coders understand that the default linux kernels and libraries will almost NEVER cause malloc() to return 0 and will almost NEVER cause operator new() to throw? Only virtual memory space is allocated. Real memory pages are only allocated as they are being used. Once all physical and swap pages are used, blammo goes your app (and possibly other apps on your system). In semi-critical systems, this is a real problem that is often overlooked.
Where is the real problem in this case? Part of the problem is that the c++ environment running on the default linux kernel does not conform to the standard.
The other part of the problem is that it is little known. If it were commonly known, people would be able to design around it (or change the kernel options). So people rely on what the documentation says, instead of properly testing the software limits.
ipv6 is my vpn
http://www.sciam.com/1998/1198issue/1198techbus2.h tml
"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."
Example:
case ch of
'A': WriteLN('Choice capital A');
'B'..'Z', 'a'..'z': WriteLN('Another letter');
else WriteLN('default case');
end;
No, the original GCN article may have had vague comments on NT's ability to blue screen but these were from different unspecified incidents. In the incident actually described a client app accepted bad input, a server app corrupted it's database, this data was needed by other clients apps that controlled the ship. These later clients were LAN consoles. LAN consoles crashed, not the LAN itself. The client and server apps created the mess, they would have done so regardless of OS. The Chief Engineer on the ship at the time and the developer of the software have both said it was not NT.
h tml
http://www.sciam.com/1998/1198issue/1198techbus2.
Also, the publisher of the original GCN article backed away from the article a little characterizing some of the content as "early speculation" or something like that.
A couple of things about the article:
Firstly, that's not really what "heterodyne" means. Heterodyning is when you mix two signals to produce another at a different frequency. This is how pretty much all radio receivers work (yes, I know there are other ways. Go in a shop and buy a commercial super-regen radio, and I'll change that sentence). It's not a "glitch", it's more a constant physical property.
Also, the problem was not directly caused by the radio equipment, but by what was said. Yup, it's an unpopular view to take, but it was just plain human error. No blaming the machines here. Why? Well, it goes like this...
The day of the accident, there was very heavy fog around Tenerife. Visibility was extremely poor, and it was impossible to see the opposite end of the runway. Another factor was that normally, you only fly off from one end of the runway, depending on wind direction. If the surface winds are calm, it's the tower's call as to which runway is in use (denoted by the heading you're facing when taking off, in 10-degree steps, ie. Runway 25/Runway 07). *Both* runways were in use, so aircraft could line up at both holding points, to help reduce queueing.
Now, the Pan-Am pilot was first out, so lined up at the takeoff point, and began his takeoff run. There was some confusion about whether or not the KLM aircraft was to taxi from the hold to the takeoff point, due to both the controller and the Dutch pilot having english as a second language. This wouldn't have been a problem for the most part, because even if the KLM had been at the takeoff point, the Pan-Am would have cleared it with plenty room, even though it shouldn't have been on the runway.
The key is in what the Dutch pilot said - "We are now at takeoff". This is indeed a common phrase, generally meaning that the aircraft is sitting at the takeoff point and awaiting clearance. However, in Dutch, the prefix "at-" is equivalent to the English "-ing" suffix - the pilot had just effectively said "I am now taking off". It's an easy mistake to make if you speak more than one language. Even a language you don't often use creeps into things you say in your first language. Just watch it doesn't have consequences this serious!