Book review - To Engineer Is Human, Henry Petrovski
Taking a break from computer books and other distractions, I recently read To Engineer Is Human: The Role of Failure in Successful Design, by Henry Petroski. Since I occasionally get into arguments about whether software development is a kind of engineering (it isn’t), I thought it would be interesting to read some more about civil engineering.
To Engineer Is Human was an interesting read, and Henry Petroski tells a good story about how failures in civil engineering allowed the discipline to develop. For example, he recounts early difficulties with iron bridges in Victorian times, and how each failure led to a period of overengineering - stronger bridges with a greater margin of error. It is these accounts that reveal the most interesting similarities and differences between software development and structural engineering.
The first difference emerges when the discussion on the use of 'factors of safety' to prevent failure introduces the term overdesigned. For example, a bridge may have been built with more iron than usual to provide more strength than the engineer expected to be necessary, in the hope that the bridge will survive the unexpected. This approach unfortunately applies less to software, where 'overengineered' is bad, and there is no concept of strength that you can increase to reduce the risk of failure: overengineered software is not less likely to be buggy, and with the exception of well-designed error-handling, increased complexity generally makes things worse.
The first similarity appears in Petroski's account of early iron bridges that, unlike reliable stone bridges, may have been failing at the rate of one in four. So although the bridge is less likely to be 'down' than the computer system, software's unreliability may be partly due to its quantity and complexity, and because software embraces new 'materials' and construction techniques on a different time-scale to civil engineering.
Although some developers think of software development as engineering, or like the look of 'software engineer' on their business cards, the comparison is more misleading than helpful. All the same, this is an interesting and well-written book, whose dense and concise text is frequently thought-provoking. In any case, I now have a better idea of why bridges and aeroplanes are generally reliable these days, and why this is largely irrelevant when it comes to software that does not work for its users.
Peter Hilton is a senior software developer at Lunatech Research.