The Agile Executive

Making Agile Work

Rusty Automobiles

with 3 comments

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.

Advertisements

Written by israelgat

June 1, 2009 at 1:24 pm

3 Responses

Subscribe to comments with RSS.

  1. 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

  2. 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

  3. 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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: