To (nextgen) engineer is human

by Dries De Roeck on April 17, 2016

During a brief trip to Milan, I managed to read through a book that has been on my bookshelf for a long time : “To Engineer is human: The Role of Failure in Successful Design“. This little book was first published in 1985, and went through some edits along the way (I read the 1992 edition). The book basically gives several examples of how learning by doing has been an integral part of the way that we design and create the world around us.

Besides elaborating on some well known ‘engineering failures’ (Hyat Regency  & Tacoma Narrows) the book gives a higher level overview of why things sometimes don’t work out as we designed or thought about them. And it is mostly this last bit that I found most interesting about this book.

What I found most insightful was the reference to Sr. Oliver Wendell Holmes’ poem ‘The Deacon’s Masterpiece‘. This poem talks about the construction of a horse carriage (a one-horse shay) which is made with the best materials around. Yet, at the end of the poem it is made clear that even the best piece of engineering eventually fails and falls apart. The book then goes on about foreseeing failure during the design process, which is something I’ve been questioning myself in relationship to internet of things products – for example: the sunsetting of the Revolv smart hub and the fading of Bergcloud and their Little Printer.

It got me wondering that when we’re designing connected products, we shouldn’t only think about mechanical failing of devices (buttons, moving parts, lights,…) but also the digital parts of the device (server connection, network uptime, technology deprecation,…). These novel aspects seem to be a lot more uncertain to predict, but they might feel a lot more easy to change, ie. shutting down a server happens by pushing some virtual buttons – the effect of that action is much less visible.

There’s probably a lot of work done on this already, I can imagine that the same questions have surfaced in the home automation market. But I wonder if someone is actually doing anything about it, as the support for ‘legacy internet of things devices’ seems something we should seriously consider.

Why do I blog this?

What intrigued me is that the book dates back more than 3 decades, but very much pins down what is still happening with novel products. Henry Petroski (the author) never mentions computerised systems as an example, but I think that his reasoning is applicable to a lot of the design and development of internet of things systems being created at this moment. All that put aside, the content of the book itself can be somewhat repetitive and the writing style is questionable. So probably not a recommended piece of reading, but it does trigger some thinking.

Leave your comment


Required. Not published.

If you have one.