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, where he explains why the traditional civil engineering approach can not work in software development:
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 do 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:
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.
Anything ring a bell? How about the alternative approach:
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…
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. There is a good chance, by this time, that the engine will generally succeed, or that any failures are easily isolated and analysed because the failure modes and limitations of materials are so well understood.
Well, 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, 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 recently discovered technologies and changing domains, and that is what makes it so hard.
So, just to make a final point, software development is rocket science!