Well, according to all the things I have heard on different lectures and read in various computer magazines, software engineering is not an engineering.
First, programming (and building a programming product in general) is offer compared to building a bridge. This metaphor is correct in some aspects. You have small pieces (functions, objects) which you combine and put together to construct a bigger and more complex system - a bridge (programming product).
But in other ways the bridge metaphor is totally incorrect. There are multiple ways how to argument this. Constructing a bridge is very well studied discipline. All the forces that have to be taken into consideration during designing a bridge are well defined. There are exact mathematical formulas that define these forces. When an engineer knows how those forces work he can design the fully functional bridge and pass his plans to builders who build the bridge exactly as it was designed.
But in other ways the bridge metaphor is totally incorrect. There are multiple ways how to argument this. Constructing a bridge is very well studied discipline. All the forces that have to be taken into consideration during designing a bridge are well defined. There are exact mathematical formulas that define these forces. When an engineer knows how those forces work he can design the fully functional bridge and pass his plans to builders who build the bridge exactly as it was designed.
 |
| Of course we are just humans and we make mistakes so even building a real bridge does not have to end well |
On the other hand software development is not well studied at all. There is some knowledge about factors that influence the development process but this is more or less just an outline what really goes on. Some estimate that the percentage of software projects that exceeded their budgets is higher than 60%. According to May(1998) the average software development project is 187% over budget and 222% behind schedule and implements only 61% of the specified features. The average success rate of the software project is somewhere around 30% [1] - it means 25% of software development efforts failed outright; another 45% produce a sub-standard product. In what other industry would we tolerate such inefficiency. Could you imagine that just 25% of the bridges fell down or 25% of airplanes crashed?
Next thing is that software development is defined as incremental and iterative process. This is also not true in bridge building parallel. The designer of the bridge sits down, design the bridge and that`s it (well, this is a little bit exaggerating). But in case of software development there is not such thing. During the life cycle there is a lot of prototypes and modifications of the initial plan.
There is also conflict in bridge builder vs. programmer parallel. Bridge builders are like trained monkeys. They just do what is written in desing plans of the bridge, nothing less nothing more. And the character of their work is highly repetitive. But the programmer recieves very abstract definition of his work and to get it done programmer needs a creativity. Programmers sometimes have so much of creativity that they want to improve the initial program design and it usually does have very bad consequences.
The following video lecture deals with reasons of such low successfull rate of software projects in more detail. I really encourage you to watch it. Glen Vanderburg puts it in really interesting way.
There is also an opinion that computer science is not a science. More on this topic can be found in Communications of ACM`s article [2].
[1] Watts S. Humphrey: Why Big Software Projects Fail.
[2] Communications of the ACM, Vol. 56 No. 1, Pages 8-9: Computer Science Is Not a Science
No comments:
Post a Comment