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

So, it’s been a while since I wrote a book review. And I have, in fact, been reading the odd book here and there. I read everyone’s favourite late-noughties manifesto The Lean Startup, which was a few good insights smothered in thousands of words of undergraduate-essay padding. I followed that with Steve Blank’s The Startup Owner’s Manual. It made a wonderful fwooshing sound as it zoomed over my head. Fun fact: it’s actually three books. Or rather, the same book thrice.

What I ought to have done is to try to stick to my intention to review every book I read, even if only briefly. But I didn’t. So until I go back to one or other, I’m declaring bookruptcy and excusing myself from those reviews.

That leaves Henry Petroski’s To Engineer is Human as the most recent book I knocked over.

What’s it about?


Petroski covers a lot of ground, but the core of his argument is that we learn more from failure than from success. For a structural or civil engineer, success doesn’t exist as a distinct quality. It’s merely the absence of failure.

Petroski expands this to say that every structure is a hypothesis. An experiment: will this configuration of matter, under these conditions, perform this function, for this time span?

This is important because sometimes the hypothesis is proved in the negative. No: due to some unforeseen combination of factors, the design is a failure. Often these failures are instructive. Subsequent designs evolve away from those failures. Perhaps a new line of thinking is abandoned, perhaps bigger safety margins are used, or some combination of the above.

After a while, the safety margins begin to shrink again; possibly creating the seeds of a new failure. And so on it goes, in a sinusoidal process of oscillating caution and optimism. It reminds me somewhat of the “secular cycles” that Turchin outlined in War and Peace and War, particularly the Father/Son dynamic that lead to “imperiopathosis”.

Part of Petroski’s answer to this cycle is to place the study of failure close to the centre of the intellectual life of engineers. And I think that’s a sound idea. Some professions, such as law, enjoy deep, deliberately self-conscious institutional memories.

Profession Envy

My own profession is, perhaps optimistically, called “Software Engineering”. A common claim is that we shouldn’t be allowed to call ourselves engineers — our products fail more often, and more spectacularly, than the work of the ordinary civil or structural engineer.

Well, look. We’ve been comparing ourselves to a Platonic Ideal, not to actual engineering. At least if Petroski’s account is to be taken as fair. Petroski demonstrates that while it appears in principle that an engineer can design the “perfect” bridge, in actual fact the engineer faces a great deal of uncertainty. The problem domain remains unknown. In fact the solution domain is full of variance too. All of this can be obscured by the falsely confidence-inducing precision of numerical solutions to integral equations.

It might well be that a bridge, unlike most software, can be built exactly as specified on time and on schedule. But that’s a matter of building the bridge the right way; it remains to be seen whether the bridge will be the right bridge. Many iron bridges failed not because they were built badly — later rail carriages simply became too heavy.

Our cousin engineers give off the illusion of perfect mastery over unruly reality through safety margins. Designs are overbuilt to the extent that can be economically, physically and logistically justified. It’s not that civil or structural engineers are necessarily better engineers. Rather, the nature of dealing with physical matter enables them to create large safety margins to protect against unforeseen variance, mere chance and human error.

Software engineers don’t get to do that. We can’t make two copies of a piece of code and suddenly enjoy an improvement in code quality. Computers move pretty fast, so when we make mistakes, the mistake can happen a lot of times before it is corrected. And sometimes, as with the Ariane-5 launch, it only has to happen once.

So take heart, my fellow Software Engineers. The grass isn’t necessarily greener on the other side of the fence. There’s just more of it, in case some patches go brown.

Conclusion

Petroski’s writing is urbane and lucid and I found a lot of it thought provoking. Recommended, especially as a counterpoint and forerunner to Drift into Failure.

This entry was posted in Books, Software Engineering, Systems. Bookmark the permalink.