Old Software never Dies

The software half-life and what to do about it.

One of the phrases in popular currency in one of my old jobs was that the only thing harder than introducing a new product into a large organisation is getting rid of an old one. It's relatively easy to reduce the footprint, but almost impossible to eliminate it entirely. Indeed, at one point we came up with the idea that software, like radioactive substances, has a half-life. It takes a certain amount of time to get rid of half of what's there, and the same time to get rid of half of the remainder...and so on. But the glorious day when it's just not there at all seems infinitely far away.

Why is this? and what can be done about it.

The reasons are not hard to find. They vary a bit from firm to firm in their relative importance, but they include:

• If it ain't broke, don't fix it. The chances are the old stuff is still working just fine for some people, so they have no reason voluntarily to change.
• It distracts from the exciting new stuff. The work to replace a product with a new one usually involves the active participation of every team supporting the business areas involved, even if it's only in a test capacity. There's a real opportunity cost here, and those affected are seldom reticent to point it out
• A bit of a delay in this kind of project somehow seems less of a problem than a bit of a delay in going live with something else
• Unless there's a compelling business reason to get off by a particular deadline, senior management sponsorship is likely to be half-hearted at best.

The last point is particularly interesting. The one time when large swathes of software were efficiently retired was in 1999, in preparation for Y2K and the millennium bug. This is not the time to discuss how serious that problem really was or might have been, the point is that everyone, from the regulators and board on down, took it seriously at the time, and as a result, amazingly, large numbers of suspect systems were successfully repaired, upgraded or eliminated.

This certainly suggests one approach - what might be called the nuclear option to extend the earlier analogy -

• Make software retirement projects high-profile, with top management backing and serious resources behind them.

But of course, getting that level of buy in is not easy, especially since the most commonly cited reason for eliminating old, but still working, software is the negative impact that keeping it around has on the support team. Such teams are usually, unfortunately, close to the bottom of the political hierarchy. The resulting difficulty in persuading top management to mobilise around individual retirement projects leads many to go for a superficially attractive 'light' option - what we might call

• 'new software for old', i.e. rub a magic lamp and get the genie to do the work.

Or to be more precise, just get the CIO to send out a memo announcing that they support the project, but without any meaningful backing or resource mobilisation.

For exciting new project which people want to be associated with, that will work. But for retirement projects, it's not enough as the discussion above should make clear.

Fortunately, there are other possibilities. They still require senior management buy-in, but may not be as unpalatable as the nuclear option.

• Set up a programme office to consolidate all your retirement projects into one management effort. Focus on reporting, and naming and shaming those who don't pull their weight. The office needs some oomph behind it, but it doesn't need to be large and expensive.
• Theft and Bribery. First steal some budget from everyone, and then give it back to people as they achieve milestones on the way to elimination. Make sure that you set the bar high enough - remember that it only takes one user left on an obsolete machine to incur the full cost of keeping it around.
• A hit squad. Pick a small group of people with the right personality ( task-driven, highly-motivated, not too simplistic in approach ), and make it their problem. Promise them ( and deliver if needed ) political backing, but expect them to grind down the holders-out until eventually the job gets done.

Which of these approaches to adopt will depend partly on the particular circumstances, and partly on the culture of the organisation. Sometimes an outside view can make it easier to identify the most effective approach.