Book review: To Engineer Is Human: The Role of Failure in Successful Design, by Henry Petroski

originally posted elsewhere: June 27, 2003

tl;dr: Instructive for those interested in the engineering process...

I read this book right after having read Samuel Florman's The Existential Pleasures of Engineering, and it suffers somewhat in comparison. Both writers give themselves the same basic thesis: as Petroski states in the Preface, "this book is my answer to the questions `What is engineering?' and `What do engineers do?'"

While Florman's brilliant work truly does explain the role of engineering among man's intellectual pursuits, as well the passion that drives engineers (the "what" and "why" of the profession), Petroski has produced a work much more focused on the "how" or process of engineering, in particular structural / civil engineering. In this book, Petroski answers best a somewhat more mundane question posed to him by a neighbor: how could the skywalks in the Kansas City Hyatt Regency collapse in 1981?

Petroski does a decent job explaining why engineering, like any other profession performed by human beings in a universe with non-zero entropy and finite time and money, cannot achieve perfection. He fills his book with many examples of infamous structural engineering failures, from the pyramids of Egypt to present day. Almost all of these are enthralling to anyone with a modicum of interest in the subject matter; the one exception is Petroski's postulate as to the failures of his aged kitchen knives. After having read Petroski's book, the reader will understand why there will continue to be engineering failures far into the future (this is not to say that the rate of failures cannot be decreased).

Besides not achieving as broad a thesis as he may have intended, the other main problem with Petroski's book is its repetitiveness of his major lessons, namely that engineers can learn more from failures than successes, and are duty-bound to analyze failures for learning opportunities. While valuable, these lessons are repeated in almost every chapter, such that any one chapter could stand alone as an individual essay on the topic. A final issue for readers to consider is how much of Petroski's book is relevant to other branches of engineering besides structural / civil. Certainly not every engineer is designing objects whose failure could endanger human life, and many in the software profession would say that most of their lessons on how to design software come from studying algorithms and the designs of successful programs. However, by erring on the side of caution, one can claim Petroski's book applies to all engineering as well as other professions, particularly medicine.

I would recommend Petroski's book foremost to structural / civil engineers, and next to all engineers and others interested in the engineering design process.