age of software

I have been thinking about longevity of software, how it ages and eventually dies. Many of the software that was around while I was baby footing in this industry is no longer around or has come up with newer versions that resemble to the original only in name. Is it possible to write a truly magnificent piece of software that can live forever without being a recluse? If we realistically don’t expect our software to live forever, what are we doing about it?

Is it possible to design for the future in advance? Unless hit by a bus tomorrow, I can venture a fair guess about what will happen to me at most 1 year from now, not more than that. Then how can we design a piece of software to work for even 5 years. Do we even think about how many years a piece of software will be used while designing?

There is music, films, paintings and buildings that last for a really long time, but the average life of software maybe 5 years (wild guess). There are too many parameters changing in software usage. Programming languages, operating systems and hardware is still changing along with maturity of software users, competition in the market, new innovative ways to do business and systems to support it, more and more automation. Internet is becoming part of routine life. A system designed 5 years back to automate a manual process is a called a legacy system now. Sophistication of requirements increase with time – process automation was the original requirement. Now same users want analytics, modeling and personalization of systems.

Business empowerment is another theme that is driving system changes. Users won’t want IT involvement in modifying values in a list of values or adding a field to a page or creating a custom report. Combined with Sarbanes-Oxley and Change Management processes, if you force business users to submit a change request and ask them to go through a set of approvals etc to add a field to a data entry page, then it will be frustrating. On the other hand I don’t think it is possible to make a system completely configurable so that it can sustain itself. At least that is not practical if it is for use by one organization, not a full-fledged product.

What I established so far is that too many parameters change over time – business, sophistication of users and technology. It is not cost effective to create a truly flexible system for use by internal organization. It is difficult to predict future. But is there anything that can be done to extend the life of software? Couple of things comes to mind – routine checkups, constant exercise to remain healthy and accommodate changing needs. I remember something that I studied in school economics – with education, need of people change.

If a request for a similar type of change comes in 10 times a year, it is high time to make the think about a way to reduce the IT dependency in doing that. Alleviate the heartache by giving more control to users. At the same time, don’t expect to cut off IT completely – the system may become like an abandoned house and weeds may start to grow up the roof. With this, my intention is not to make a case for livelihood of IT department.

In conclusion, systems are not immortal, it will age and there should be enough nourishment to keep it going strong and keep up with the changing world.