Review: To Engineer is Human

To print a PDF copy of this article, click here.

arj-76-book-reviewAuthor: Henry Petroski

Publisher: Vintage

Copyright Date: 1992

Hard/Softcover/Digital: Both, 272 pages,

ISBN: 978-0679734161

Reviewed by: Aileen Sedmak, Deputy Director for Systems Engineering Policy, Guidance, and Workforce, Office of the Deputy Assistant Secretary of Defense for Systems Engineering, Pentagon, Washington, DC.


Henry Petroski’s 1982 classic is relevant today given the Department of Defense’s challenge to develop and deliver highly effective and reliable defense systems that are increasingly integrated and complex. A natural result of this increased complexity is increased risk and probability of failure. However, efforts to eliminate all risk would impede the Department’s ability to provide the warfighter with the technological superiority to dominate the battlefield in an economical and timely manner. Instead, Petroski challenges us to understand and learn from our failures, which allows us to push the technical edge of our defense capabilities even further.

As an example, Petroski cites the case of Washington state’s Tacoma Narrows Bridge, which shook apart in high winds just a few months after opening in 1940. The engineer, Leon Moisseiff, based the bridge design on the designs of several successful bridges of the time, but he did not consider the wind-related problems that had damaged other bridges. All structures have a natural resonance, and the bridge design did not account for this resonance. When the wind hit 42 miles per hour, it caused the motion that ultimately led to failure. As a result of this disaster, modern structural engineers now factor in wind flow. They use simulation programs to better understand and design for the natural resonance of bridges, buildings, and other structures.

Sharing this and other classic examples of engineering failures—a 1979 DC-10 crash in Chicago, a 1981 Kansas City Hyatt Regency walkway collapse, and more—Petroski shows that a failure-proof design does not exist, that innovation involves risk, and that studying failures contributes more to advancing technology than copying successes. “One of the paradoxes of engineering is that successes don’t teach you very much. A successful bridge teaches you that that bridge works,” Petroski says. This success does not prove that the same bridge, built at a different location or made longer or taller, would also be successful. “It’s all theory until it’s completed,” Petroski explains. Yet engineering curricula often focus on successful designs and neglect unsuccessful ones, which, ironically, could lead to future failures.

Petroski stresses we need to understand how failures happened and incorporate this learning into the design process. Failure analyses influence the way engineers hypothesize, push the limits, and develop new systems and structures. Petroski says, “I believe that the concept of failure…is central to understanding engineering, for engineering design has as its first and foremost objective the obviation of failure. Thus the colossal failures that do occur are ultimately failures of design, but the lessons learned from these disasters can do more to advance engineering knowledge than all the successful machines and structures in the world.”

This brings Petroski to another point, that Moisseiff’s reliance on engineering successes and exclusion of engineering failures has a modern-day counterpart: computer simulation. “There is clearly no guarantee of success in designing new things on the basis of past successes alone, and this is why artificial intelligence, expert systems, and other computer-based design aids whose logic follows examples of success can only have limited application,” Petroski writes. Interestingly, Petroski points out that mistakes are more easily made because it still requires the human to ask the correct questions, to provide the correct scope, and to install checking mechanisms.

This book is a valuable read for program managers, engineers, and other acquisition professionals. It helps put into perspective how the complex systems demanded by today’s warfighter cannot necessarily be developed and delivered in a fail-proof manner. It illustrates that our ability to learn from mistakes through risk reduction prototypes and “failing fast” during our development process can increase our ability to solve complex problems and deliver a safer capability in a more efficient and cost-effective manner.



To print a PDF copy of this article, click here.

Reading Program: