Rusty Automobiles
No, this post is not about today’s GM bankruptcy filing. Rather, it is about coming to terms with a phenomenon similar to rust – software decay.
An IT application development team I met with recently indicated they reached the point of allocating 80% of their resources to software maintenance. Various colleagues of mine report similarly worrisome figures experienced in their practices. As a matter of fact, some of my colleagues consider such figures endemic.
It might indeed be hard to visualize a rusted line of code. Decay, however, applies. To quote Capers Jones:
All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.
Hazardous that software decay is operationally and economically, it is lethal once it becomes embedded as a revenue generator in the business design for enterprise software. In particular, high maintenance costs as part of planned obsolescence invariably lead to the sorry state of affairs characterized as “Consumer Underworld” in The Myth of Excellence.
If you find this post a bit dramatic, please read Christensen’s recent post on the titanic efforts to turn things around launched by GM when it was already too late. Christensen concludes his post with a very pointed warning:
If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.
The Agile Executive 
It is very true that software just like everything else does become obsolete. Obsolescence is relative from one organization to another, at one place a policy can make a software system obsolete while at another it might still be producing.
Thanks for sharing those links.
Ayman Nassar
June 2, 2009 at 6:19 am
We are in full agreement, Ayman. I believe the malleability of software often makes us forget about the decay. The problem is particularly bad when life-cycle costs of software are not sufficiently understood. The post Can You Afford the Software You are Developing (http://tr.im/nchq) speaks to the economics of the issue.
Israel
Israel Gat
June 2, 2009 at 12:50 pm
I would add that even software with a slow decay curve suffers from accumulated mass over time. That mass creates a technology inertia as palpable as a rolling snowball. Once the snowball becomes a certain size, it becomes almost impossible to lift or reshape it without immense effort. One need look no further than Microsoft Windows to see the effect. Each new release seems to require a longer time and greater complexity.
Paul Brownell
June 2, 2009 at 1:06 pm