Some music loving readers could notice that this title is borrowed from a 1975’s Supertramp album. On the cover of this vinyl LP, you can see a guy taking a sunbath in a gray industrial landscape. According to the common interpretation, the term Software Engineering was coined just some years before this, in 1968 at the NATO Software Engineering Conference in Garmisch, Germany. The aim of this conference was already to tame the “software crisis”. Since this era, vinyls and Supertramp have mostly disappeared, but software development seems to have been continuously in crisis and we still debate today if we are software engineers or software craftsmen.
Many reports exist on software projects have difficulties to respect initial budget and schedule, which is confirmed by real life experience. Multiple approaches have been devised and promoted to change this situation. While we can always discuss the problems that plague our industry, I found interesting to compare it with a “true” engineering area: construction. Even in Switzerland where precision is valued as a country of watchmakers would, you can read every week in the newspapers the mention that some public construction project is not respecting its budget, schedule or often both. And this is mostly the same for individual houses building projects. Do you see a debate about the fact that tunnel or road building is not engineering? Have you read about the ” building crisis”? I don’t. Construction engineering has been presented in the past as a model for software engineering. If we could define precisely the requirements like the construction industry blueprints, we would be able to achieve the same reliable results. This was the foundation of the methodologies crafted in the 20th century (SSADM, Information Engineering, Merise, RUP, etc.) that rely on a complete initial analysis and architecture of software projects. It is true that you don’t see a lot of abandoned half-built bridges or roads as you can witness canceled software projects. However, you can see examples where the final price is really higher than the initial estimation. The main tunnel through the Swiss Alps still under construction is expected to cost the double of its initial budget…. and there are 8 years left to make this worse. We can then wonder if construction engineering should really be an example for software development.
Tunnels and software project could have a lot in common. When you start digging, you have an overall idea of where you want to go, but you don’t know exactly what you will meet in the middle. This is why the Agile Manifesto prefers “Customer collaboration over contract negotiation” and “Responding to change over following a plan”. Getting back to the concept of software “crisis”, I think that there is no crisis. Every project meets obstacles. Some teams manage to overcome them, some not. Our software obstacles are the uncertainty of requirements and the heat that friction between people can create. No process or tools can help overcoming this, only collaboration and the ability responding to change with incremental development. It is even more important in software projects. If we mostly lack the skills to build tunnels and will accept whatever engineers tell us, users have a clearer idea of what software could be and a greater decision power about project evolution. Communication and negotiation skills are thus more important in our context.
Even if we cannot plan the changes that every project will face, we should remember that laser-guided technology allows tunnel boring machines that started from each end to meet after a journey of many kilometers underground. Choosing trusted technology and using good practices are a prerequisite to reach success in every project context. Otherwise, you project will already be in crisis before its beginning. Contrary to most engineering domains, the lack of discipline and professionalism of some developers could be the real human crisis of software development. Get yourself some help to prevent the software crisis with a free subscription to the Methods & Tools software development magazine.
There was an article in The Idler maybe 3 years or so ago, that cited some research that had looked at cost and time over-runs for major engineering projects right back into C19th, and which reached the conclusion that despite the use of all sorts of management techniques through the C20th, there has been no improvement in our ability to estimate over the last 100 years.
One problem is that where we find a tool or methodology that improves productivity, we immediately reduce our estimates to fit.
Might be worth considering cost overruns as an example of technical debt. Sometimes during the life cycle development, corners are cut which results in “technical debt” that after either be paid back up front or else it comes back at a later time (bill collector)
See Technical Debt
http://en.wikipedia.org/wiki/Technical_debt