3 December 2010

Is software engineering immature?

Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:
"Software engineering is gravely hampered today by immature practices."
If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of  Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:
"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."
So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?

5 comments:

nva said...

Based on experiences I had in software industry, I think we are more hampered by the wrong choices(and often imposed) of engineering practises to a given project. I think we tend to generalise a successful practise and do not evaluate for the current context and adapt suitably.

(I'm very much impressed ideas and thoughts that you bring out through your blog. Kudos)

Ulrik said...

Thanks for your praise.

I think you are right, software is a development activity, but it is managed as a production activity.
And efficient production is done by reusing successful practices and optimise them while keeping the context as stable as possible.
Agile methods are a step in the right direction but I think they still are based on the underlying notion of software production.

Chris 'Buzz' O'Neil said...

I agree with your assessment of the state of software practices being crude at best. I can recall in the halls of the electrical engineering building that software should be self taught. This is a difficult proposition because most standards such as the IEEE STD 1471 which provide an approach to developing software architecture, leaves it to the reader to derive the process. In some industries such as the web there exists a vast literature and free frameworks complete with software examples of implemented design patterns. It should be noted that these reference implementations took years to develop.

Unfortunately this does not appear to be the case for the automotive and agriculture industries. Without a reference implementation, these industries must rely on internal competencies, but if they fail to bring together all the cross disciplines of program management, architect, designer, and implementer to derive a practice, it will most likely fail to achieve the desired results.

Ulrik said...

I agree that there are no reference implementations of software in the automotive industry. Or rather each OEM tries to maintain their own, heavily influenced by their suppliers. And one can guess how well that works if one changes supplier for each new car model. AUTOSAR might be a step in the right direction, but they actively avoid establishing common processes.

As for software engineering should be self taught: I'm very involved in teaching SE at two universities and I think this is the only way to rise the standard in our field. But I have to confess that most of the knowledge I have about software I did not get at any university. Not by choice but when I was an undergrad all that was offered was the typical range of computer science courses about various programming languages. I am very grateful for meeting some very skilled professionals who freely shared their knowledge after graduating.

John Michle said...

Its really informative, some facts and other points given here are quite considerable and to the point as well, would be better to look for more of these kind for efficient results. for your business.

Construction Service Management Software