Podcast: Play in new window | Download
Subscribe: Apple Podcasts | RSS
In this episode, Chris and Jeff discuss the role of failure in advancing engineering knowledge.
- All things fail at some point. Engineers advance their own knowledge, and that of the profession, by analyzing these failures.
- As a guideline for our discussion, we reference the book, “To Engineer is Human: The Role of Failure in Successful Design,” authored by Duke University professor Henry Petroski.
- Well-known engineering failures include:
- A DC-10 crash in 1979 that was eventually attributed to maintenance issues.
- Collapse of a suspended walkway in 1981 at the Hyatt Regency hotel in Kansas City, Missouri.
- Space station Skylab falling out of orbit prematurely in 1979.
- Various missions to Mars failing to reach their intended destinations.
- A partial meltdown of the Three Mile Island nuclear reactor in 1979.
- The 1940 wind-driven collapse of the Tacoma Narrows bridge. (video)
- Design of the Ford Pinto fuel tank in the late 1970’s.
- Loss of NASA’s space shuttle Challenger in 1983 due to an O-ring failure.
- Unintended acceleration in Toyota cars from 2009 to 2011.
- Nuclear disaster at Japan’s Fukushima Daichi power plant in 2011.
- Electronic failures, such as the XBox red ring of death, don’t usually endanger human life.
- Chris makes the case that improved tools (CAD, FEA, etc.) and methodologies (six-sigma) have served to reduce the number and frequency of engineering failures.
- Jeff counters that good tools don’t necessarily produce good results.
- Even with powerful tools for analysis, engineers can be surprised by black swan events.
- A 2009 report card from the American Society Civil Engineers gives the nation’s infrastructure a grade of “D.”
- Failure often teaches lessons that cannot be learned from textbooks.
- A single problem denotes an engineering failure, while an absolute engineering success requires a complete lack of problems.
- Chris has been working on mean time between failure (MTBF) calculations.
- Because of the wide number of possible avenues for engineering failure, it is important that engineers be open to outside review of their work, and to reviewing the work of others.
- It is important that engineers remain humble when designing a complex system.
- Chris and Jeff discuss whether engineers should consider themselves the most likely source of design errors.
- Innovative design requires stepping outside the security of known procedures and methods.
- A myriad of options are available when designing a system, but the number of unexpected interactions go up with system complexity.
- We learn about the nature of a design problem by iteratively moving from design concept to analysis, then back to concept as we discover what works and what doesn’t work.
- Keeping track of “bugs” is an important part of improving a design.
- Safety factors for aerospace design may be in the range of 1.2 to 1.4, while elevator cables are designed with a safety factor of 11.
- Testing is an important part of reducing uncertainty.
- Accelerating failure can be a competitive advantage.
- Construction of the Crystal Palace is given as an example of engineering success, housing the Great Exposition of 1851 in London, England.
- Joseph Paxton, designer of the Crystal Palace, was inspired by the shape and structure of giant lily pads.
- Accepting the concerns of critics, Mr. Paxton conducted public testing of his structures.
- Metal fatigue problems caused several crashes of the de Havilland Comet aircraft. This was a case where state-of-the-art analysis proved insufficient.
- Learning from failure is an important part of the engineering profession.
Photo of the Challenger explosion provided by NASA. Podcast theme music provided by Paul Stevenson
2 thoughts on “Episode 18 — Failure”
Interesting podcast. I actually did a small internal company talk on this a few years ago. Regarding the Toyota unintended acceleration issue. The last I read about this was that after +/- 6 months of investigation by NASA engineers, several other bugs were found, but the root cause of the unintended acceleration was never found and not proven to be software. Makes you wonder what the root cause was afterall?
Comments are closed.