I've been watching The History Channel's Modern Marvels Engineering Disasters marathon today and have picked up a few ideas to keep in mind:

• Cost Savings Measures need to be scrutinized left, right, up, down, and then put on the shelf for further thinking before implementing or putting into production.

  With a number of these disasters, someone somewhere decides to change or tweak a design to use a cost savings measure which should have minimal impact on the design. Something which worked in a similar situation or design and easily slides into place with this new design. But what happens is that you're changing one element of a system, you need to analyze reevaluate the entire system with the change you've made.

• Substitutions need similar scrutiny.
• If you're working in or with a system of interconnecting components and dependencies, you need to understand your dependencies and how changes in them can affect your component, whether or not it's supposed to affect your component.
• Too many systems assume optimal conditions and don't account for sub-optimal conditions or just right-out negative conditions. The designers trade off consumer experience or business value against the cost of implementing features to account for possible (probable) sub-optimal conditions.

What amazes me is the failure to learn from past accidents, disasters, and just plain malfeasance. Watching this in marathon style you see the same type of accident or disaster over and over again.

Update 10/Sep/04

Dan Bricklin has written a great essay Learning From Accidents and a Terrorist Attack: Another key point I found in the book is that in order to keep failures from growing into accidents the more an operator knows about what is happening in the system the better. Another point is that independent redundancy can be very helpful. However, back to coupling, redundancy and components that are interconnected in unexpected ways can lead to mysterious behavior, or incorrectly perceived correct behavior.