To Engineer Is Human: The Role of Failure in Successful Design

This little gem is an analysis of engineering failures, and the learning that occurs due to these failures. While he is himself a professor of engineering, Petroski uses language comprehensible to the layman making this book accessible to almost anyone. During the course of the book he argues that engineering is part art and part science, and that as a discipline engineers focus on building safe, affordable, and reliable things (from paper clips to airliners) to meet a set of requirements. He goes on to elaborate that, being human, engineers make errors and sometimes spectacular failures ensue. The key, he argues, is that once errors are exposed, engineers can glean knowledge from those problems to improve future designs.

He uses accessible examples that most people can readily relate to, from researching failure modes on one of his son's toys (the components used most frequently failed first, just like a frequently used light bulb burns out more quickly due to metal fatigue and subsequent cracking), to the deadly collapse of the Kansas City Hyatt Regency Hotel walkways, which killed over 100 people. He also discusses easy to comprehend failures (suspension bridges in strong wind), and more intricate interactions, such as was revealed in the Chicago DC-10 accident. Throughout, he retains an aura of good humor and approachability, which makes this book far more readable than most books in this field.

My only complaint about the book is not even the fault of Mr. Petroski at all: the font in the book is very small, and combined with small borders, the book is a bit tough to physically read. Small matter, though, as once you start the book, you will not want to put it down. Well done.

With entire books on the pencil and on bookcases, Petroski has established himself as an author who knows how to make anyone look at everyday items in a different light. Whereas these books explain how objects work, in "To Engineer Is Human," Petroski cites why engineers are responsible for design flaws that cause failure. Being a professor of civil engineering, Petroski shows his expertise in this area. This book is for those who are interested in studying engineering, are already engineers, or are just interested in the "why" of accidents. To be able to understand this book, though, you should do some research on these accidents because Petroski assumes you have heard of them. These include the DC-10 accident in 1979 in Chicago, the 1940 Tacoma Narrows Bridge collapse, and the tragic 1981 Hyatt Regency Skywalk disaster, which killed 114 people.

Petroski is clever with his chapter headings, such as "Success Is Foreseeing Failure" and "When Cracks Become Breakthroughs," which could be considered good rules for civil engineers to follow. I think this is a great book for those interested in engineering, if they have done their homework before coming to class.

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.

I am not really sure how I came across this book. I think it was by following relevant links on Amazon. Anyway I bought this as well as The Evolution of Useful Things at the same time. I found this a very insightful reading in light of my occupation as a software engineer. Several of my coworkers recently had an email conversation regarding the quailty of software engineered products vs. "real" engineer's and their feats of construction, bridges, airplanes and buildings all things that Petroski covers in details.

Some additional thoughts on how structural engineering is different from Enterprise Application Software Engineering:

1. --In general software is unlimited, where as Structural Engineering has natural laws. Higher level Patterns are pretty constant, where as within the created construct of software they are reinvited (Object Patterns, EJB Patterns)
2. --structures have the added requirement of no death, where as Enterprise Software only has revenue associated with it, not as powerful a motivator as death.
3. --software is interactive with behavior, where as a bridge is a bridge

http://www.niffgurd.com/mark/books/2002.html#eng

Not many photographs or illustrations. If it is supposed to be a fun easy read - illustrations and photos would be there for the nontechnical reader. If it's going to be a professional analysis it needs to catagorize the failures and cover them in a more orderly manner. It seemed to be a confusing mixture lacking direction, very wordy with lots of digression. I was hoping to nurture my, high school junior, daughter's interested in engineering without getting one of the "text book" engineering failure books. This didn't draw her in at all, even though we had recently been talking about some of the failures that are supposed to be covered in this book.
I am returning this and going for a more professional failure analysis books that caught my interest years ago.