Software (Engineering or Development?)

One thing that always interests me about software is the eternal discussion, that has been going for some years now, about the relationship between software development and other engineering disciplines.

On one side stand the traditional approach folks, claiming that software projects are the same as any other engineering projects, and because of that, should be managed as other engineering projects (the favorite one is civil engineering, with house building…)

On the other, the agile practitioners don’t accept software development to be called “engineering”, and say that this is probably one of the reasons software development is in this situation nowadays (not a good one, as you may conclude).

So, what is the right answer? In my opinion, both! To the explanation…

Martin Fowler wrote something about it in this article (everybody knows which side he is in :-) ), where he explains why the traditional civil engineering approach can not work in software development. Quoting one of his sentences

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

And I totally agree with him. If you look at UML models and other software design methodologies, there is no way to design a software in such detail so that the construction phase could be a less skilled activity, with predictable results. All you get in projects with long design phase is a lot of rework in the construction phase.

Ok, so software is not civil engineering, but is it not engineering at all? That’s what got clearer after reading the appendix F of the Rogers Commission Report, written by Richard Feynman, which investigated the Challenger Space Shuttle disaster, in 1986.

Now, if you are still paying attention, you should be asking: “What space shuttles have to do with software?”

Simple, it’s engineering. And not just that, it is high technology engineering.

Take a look at what Dr. Feynman said in his report about the space shuttle main engine (quoted from this other blog, where I’ve found all the material):

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes.

Anything rings a bell? How about that?

The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), …

With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood.

Well, I don’t know what are you thinking, but when I read that, it seemed to me that somebody was talking about iterative software development. And that’s the whole point about it, software development can be compared to an engineering discipline, but to an advanced engineering discipline.

If you try to compare developing software to building houses, you try to compare 2000 years of experience to something we started to do in the last century. But even in software, if you go to well known domains, with well known technologies (not easy to find projects like that… :-) ), you can probably automate the process with different tools, making it a “less skilled task” and also a lot easier.

But in the great majority of projects, developing software is still about messing with recent discovered technologies and changing domains, and that what makes it so hard.

So, just to make a final point, software development is rocket science!


  1. See also Concurrent Set-Based Engineering

  2. Reading this reminds me of my previous room mate. That guy was one of the smartest people I know, but he was a little odd for my tastes though. Anyways I delighted in reading this, thanks. Will give me something to discuss when I see him.

%d bloggers like this: