Learning from Failure: The Case of Petroski, Pû, and Pooh

INTRODUCTION

Henry Petroski, professor of civil engineering and of history at Duke, and prolific author of books on the history and philosophy of engineering notes:

Case studies of failure should be made a part of the vocabulary of every engineer so that he or she can recall or recite them when something in a new design or design process is suggestive of what went wrong in the case study.

There are many interesting instances of failures in engineering systems that have something to teach us about, or at least warn us, regarding design. Including failures that are invisible and go on and on, occasionally ending with a firm going out of business, but most often, just continuing to lose money.

AVOIDING HUBRIS IN THE DESIGN PROCESS 

One important part of some of Petroski’s cases is cautioning engineers to avoid hubris in the design process. Especially because this blinds us to potential failures from extending known practice to new, unprecedented applications. When speaking of hubris, it is not just arrogance, but more often the use of what has always worked in the past without realizing new effects that might come from extending existing practice just a bit too far. (Jeff Bezos recently noted in a similar sense that the innovator had to combine expertise with a “beginner’s mind”; highly knowledgeable and very open minded.)

There are many examples of this in the literature, recounting numerous paths from hubris to failure, (every engineer has seen the films of the Tacoma Narrows Bridge – “Galloping Gertie” – falling), but one important lesson was particularly telling. A large object involved in offshore operations needed to be floated out of a drydock. There were some flotation pontoons available attached to the object to give it additional buoyancy. When the crane supporting them during installation took off tension, the pontoons ripped loose the attachments. The crane lowered them back down to the drydock floor, fortunately without injury or damage except to the connections. The designer had been contacted by a foreman shipfitter who was concerned that the connections “didn’t look right” prior to the failure and the designer had dismissed his concerns, noting that the calculations showed the design to be adequate.

The problem was that the connections were carefully designed and optimized to sustain the upward force of buoyancy and transverse and longitudinal forces due to waves and motions. The designer had not remembered that prior to going to sea, and the pontoons would hang from the object until the drydock was flooded. The shipfitter was not necessarily smarter than the designer, but he saw the connections from the drydock floor, where their function holding up the pontoons was obvious. This gives us a number of procedural lessons in design that speak to many other failures, as shown next.

THE FIRST TASK OF ENGINEERING ANALYSIS IS IDENTIFING ALL POSSIBLE FAILURE MODES

For structures, this can be interpreted as looking at fatigue, corrosion, elastic deflection, and vibration as well as simple overstress based on ultimate failure or code requirements. We should also recall that an object might see unusual loads when initially placed into service, or due to accidents or other special circumstances and look carefully at the entire life cycle of the system. Nowadays it is often also important to look at the portion of a system’s lifecycle when it is removed from service. This especially speaks to removing platforms when the wells are closed and when breaking ships into scrap.

An example from the offshore industry is production modules installed on platforms. During barge transport to the platform, they commonly see lateral accelerations close to a gravity or more from the barge motions, that they will never see once installed. Another example that can even dictate the basic type of installation early on is seismic loads. This is also important when hauling a ship or storing it ashore. Some drydocking codes cover this, but many do not. Another important example, this regarding accidental loads, to consider in drydocking is redundancy in support; will a ship fall over when a forklift knocks a support loose? In small craft, one common structural code, NVIC 11-80, is regarded to result in excessive scantlings, but small craft are often subject to unexpected loads such as grounding, being dropped, being hoisted onto a ship and striking the ship’s topsides, falling off trailers and other cases beyond loads produced while running in the ocean. Most NVIC 11-80 boats survive many of these incidents whereas other codes produce lighter scantlings. It may be a valid excuse to say that a given accident was beyond the envisioned use of the boat, but that does not give the owner the best service.

Though various complicated analytic tasks such as Finite Element Analysis (FEA) are regarded as challenging engineering tasks, they are preceded by this identification of failure modes; you can’t analyze what you didn’t anticipate, and it is easy to become blinded to ignoring alternative failure modes by the details of FEA or other sophisticated techniques.

THE NEXT TASK OF ENGINEERING ANALYSIS IS ENSURING THE MODEL USED PROPERLY REPRESENTS REALITY

In the pontoon case, analysis was probably not a problem, except that not all of reality was represented. There are enough detailed examples to the contrary that we can consider later, especially in FEA, but there are fundamental rules. One is to always do simple hand analyses, including the discipline of sketching out free body diagrams and even doing “old timey” analyses. One interesting example of this is that the Navy now requires lift equipment drawings and weapons foundations drawings for small craft to include old-fashioned force diagrams. Ironically, this technique many of us were never taught in school is now faster and more accurate due to computers; a force diagram is quick to do in CAD and is accurate to more decimal points than you can imagine (and is an interesting challenge the first time). Our predecessors in engineering didn’t have Excel or other more complex tools but had developed powerful graphic techniques (and even physical techniques – see “soap bubble analog” for torsion analysis) for solving computationally intense problems; it is worth studying some older textbooks. It is also wise to always check for unit consistency, especially in cases involving dynamics; you can’t add apples and oranges, nor can you add pounds force and slugs.

ANOTHER CRITICAL TASK OF ENGINEERING ANALYSIS IS TO CAREFULLY RESEARCH AND CONSIDER OTHER OPINIONS

Manufacturing gurus refer to Genchi Genbutsu, literally “real place, real thing” which means “look and see”. Better, add “listen” to this. In the pontoon case, had the designer listened to the foreman shipfitter, and simply gone to the drydock, he would have seen the problem. Many times, operators, tradesmen, and others have wise insights from other experience and from seeing the problem differently. It is critical, and often difficult, to put aside one’s brilliance and expertise, and modestly listen to people who are not engineers, or to engineers from other disciplines, and do further new analyses or whatever research is required to ensure that their concerns are met.

THE TAO OF ENGINEERING

A somewhat earlier philosopher than Petroski, Lao Tse in the Tao Te Ching, suggests that the sage should be pû, the “uncarved block”. An important part of the concept is that a “sage” should strive to be free of preconceptions and hubris, as Bezos remarks, “the beginner’s mind”.

Benjamin Hoff, in The Tao of Pooh, further explains the Taoist concept by reference to Winnie the Pooh. Though a “bear of little brain”, he generally comes to practical solutions where everyone else fails. Pooh, who often refers to himself being not as smart as Owl or Rabbit, is utterly free of intellectual hubris and thereby is the uncarved block when it comes to solving problems.bear of little brain”, he generally comes to practical solutions where everyone else fails. Pooh, who often refers to himself being not as smart as Owl or Rabbit, is utterly free of intellectual hubris and thereby is the uncarved block when it comes to solving problems.

We should all consider Lao Tse’s advice that engineering “sages” become the uncarved block, open to all sources of information, without imposing our own ideas on the data until we have carefully considered it all. We need to become imaginative enough to consider every problem as broadly as possible, rather than simply doing what a code requires or what was done the last time (especially with the Excel spreadsheet that was used last time). We also need to remind ourselves that compared to what is known, and what is unknown in engineering, we are all bears of very little brain. We need to be aware of our limitations when we design systems.

ABOUT THE AUTHOR

Christopher D. Barry, PE, s an experienced naval engineer who has, over the years, gained extensive experience in the maintenance, overhaul, acquisition, design and construction of commercial and military ships and boats, offshore oil platforms and other floating equipment. He is well versed in the areas of hydrostatic, structural, hydrodynamic and mechanical engineering analyses of resistance, motion RAOs in waves, mooring systems and more. See Christopher’s full CV here.

FURTHER READING

Petroski, Henry, To Forgive Design – Understanding Failure, Belnap Press of Harvard University Press, Cambridge MA, ISBN 978-0-674-41682-6, 2012

Hoff, Benjamin, The Tao of Pooh, Penguin Books, New York, NY, ISBN 0-14-00.6747 7, 1983

Lao Tzu, Tao Te Ching (D. C. Lau translation, with commentary), Penguin Classics, New York, NY, ISBN 0-14-044131-X, 1963