Software Best Practices

Hi everyone,

I've been looking for opinions or empirically derived 'truths' about how to tell when a software application is nearing retirement age (or well past it!) The only thing I found was a SAM page on TechNet with basic truisms, such as 'when your maintenance costs too much'. (An over-simplification of what they say there, but you see what I mean.)

My company has a number of huge, aging systems, which are integral to most of our business functions. The cost to replace all of them would probably be prohibitive. But there's genuine interest in replacing some of them. The question our business colleagues ask us in IT is, essentially, 'What does it look like when I have a system that's too old and should be replaced?'

I think that is a most excellent question. Do any of you have references you could point me to? Or knowledge you would be willing to share? Even heuristics are good as a starting place.

Many thanks.

Debby

Hi Debby,

I asked around Construx for some ideas for you. Matt Peloquin replied with

Not what they're hoping for but I'd replace:
'when your maintenance costs too much'
With
'when your maintenance costs more than building a new system to produce equivalent value'
This is such an economics based question that it has to be answered by an analysis of cost of development vs. value in old vs. new system. Any rule of thumb heuristic not based in such an analysis seems glib to me.

Steve Tockey replied with

He also suggested that you look to his book Return on Software for was to calculate those decisions.

Interesting question and there is a simple answer - when it costs you more to carry on using it than to replace it. How you work that out is much, much harder though.

I'd be more included to look for the warning flags or symptoms first though:

• Your not adding any features to it but are paying more and more to maintain the system status quo.
• It has become near impossible to refactor the code (signs of an application that has had lots of features added with little thought to future maintenance or architectural concerns).
• You have trouble hiring people that have the skills to maintain the system - (although it would need to be pretty old for this to be a problem!).
• Your users are calling out to move to a new application because they think it will improve their productivity. 

Thanks for these answers. As I was writing my question I looked at my bookshelf and saw Steve's book sitting there, and thought, 'I bet there's a financial algorithm for this.' 

Matt's suggested refinement is helpful. I think the development managers can sometimes get too close to be able to take a broad, comparable view of the cost of development vs the cost of maintenance. 

And David's input will ensure I also consider how easy it is to get qualified staff to maintain and support the systems, if the technology is old and the language archane. If we aren't adding new features, it's arguable that the system isn't providing enough business value. Certainly the innovation aspect and competetive edge would be missing (which is an irrelevant consideration unless you disagree with Nicholas Carr, in Does IT Matter?,  when he says that IT doesn't provide a competetive edge anymore -- another topic, isn't it?). 

Thanks to all. Time to go read more of Return on Software.  

Debby