Rajesh Jayaraman

Of Bridges, Rockets and Code junkies

"Although differences exist between building software systems and building physical structures such as bridges and rockets, enough similarities exist that software engineers can learn lessons from failures in traditional engineering disciplines. This paper draws lessons from two well-known failures - the collapse of the Tacoma Narrows Bridge in 1940 and the destruction of the space shuttle Challenger in 1986 - and applies these lessons to software system development."

- From NASA technical paper From Bridges and Rockets, Lessons for Software Systems by C Micheal Holloway

I read this interesting paper at the NASA Technical Reports site.

It debunks the myth that software engineering is inherently different from other engineering disciplines and we cannot learn anything useful from the rigour of other engineering disciplines. We assume that since this discipline is changing so rapidly, it gives us the liberty to be less than rigorous in our approach to these engineering problems.

There have been many technology disciplines which have had much faster growth rates and have managed to be sufficiently rigorous in their practice.

We enjoy a relaxed working atmosphere in many software workplaces, as opposed to rigid hierarchies in traditional engineering companies. Also our work product does not manifest in any physical form. Neither of this should deter us from learning crucial lessons from the past. The past not only of software but also of other varied disciplines.

I can think of a variety of ideas we can pick up from other engineering disciplines. For example, Hazard and operability (Hazop) analysis carried out by chemical and mechanical engineers before plant modifications can give us ideas for change control of software systems.

I have participated in a couple of Hazop analyses during my days as a chemical engineer. It is generally a team process where the engineer proposing the change has to provide plant diagrams of the affected portion of the plant. He needs to analyze the impact of the modification on upstream and downstream processes. He also needs to clearly specify the safety impact of the change. And all this needs to be done quantitatively. Then the Hazop team systematically goes through the plant diagram and analyzes the impact on each component of the system thoroughly before approving such a change.

The only process that comes close to this in software engineering is a design review and code impact analyses. These tend to be generally loosely structured and rely more on the insight of individual engineers about the overall system than on a formal defined process.

There is a wealth of knowledge out there for us to use. If we refuse to look at these out of ignorance or arrogance, the loss is ours!

blog comments powered by Disqus