I was harassing a friend at the highway department about deteriorating roads encountered during my commute and he shared some interesting wisdom. Asphalt roads must be resurfaced every few years. He described it as a relatively inexpensive process that helps keep roads smooth and divot free. The problem, he said, was that it was easy to defer maintenance to “save” money – the road is still smooth, and no one is complaining - but by the time cracks appear in the pavement the maintenance bill will be substantially higher. Something about water getting into the cracks and further damaging the pavement when it freezes and thaws as well as undermining the roadbed. As I recall, he said the cost escalation of fixing the road after cracks appeared was something like ten or twenty to one.
It struck me that we run into the same problem with software systems. Bits don’t rot, and our systems don’t develop “cracks”, but it is easy (in the short term) to defer maintenance without realizing that a debt is accumulating, sometimes with substantial interest.
That said, it’s hard to get executives and bean counters excited about spending money on maintenance upgrades that seem to offer little or no performance or functionality improvement when organizations have pressing and visible business problems to solve. The return on investment for software maintenance is hard to quantify – but we need to get better at it. Think of some of the challenges faced by organizations that have aging software applications, databases, and operating systems that haven’t kept up with their maintenance.
Compatibility – If you are running an old version of a database or operating system, you may find that newer applications aren’t compatible and don’t behave well with it. This can limit your options when bringing in new applications or result in an unscheduled “crash” project to bring your old system current to enable support for essential new applications.
Security – When exploits are discovered in commercial systems, word travels fast among the unsavory jerks who want to infect your systems and compromise your data. Software vendors are always a step or two behind, trying to patch security holes as they are identified. If your systems haven’t been patched/upgraded in a few years, there are probably instructions and tools available on the dark web to facilitate compromising your system’s security.
Increased burden of refitting – As commercial software evolves, the little changes made in each release accumulate over time. If maintenance upgrades are deferred long enough, then when they finally are applied it can present a substantial learning curve to both support staff and application users. The upgrade burden can be especially labor intensive if the legacy implementation has been highly customized or augmented locally over time because it can increase the effort to reimplement those customizations.
Loss of Support – Vendors often establish “sunset” dates for older releases beyond which they will not guarantee support. A looming sunset date for a key system can be a real headache for an organization that wasn’t planning on a significant maintenance upgrade project but can’t afford to be without support for a mission critical system.
The problem is obvious, but the solution is not. We need to get better at keeping non-IT leadership apprised of the ongoing costs and labor requirements of keeping our systems up to date. Deferring maintenance is easy in the short term when resources are scarce and there are more user requested projects than people available to perform them. We must have a sustained education effort for executives that reminds them that the ongoing support for our business applications isn’t just the maintenance fee charged by the software vendor – it also represents ongoing human resource commitments internally to keep our systems relatively up to date.
Maintenance isn’t sexy – but it is important. When maintenance is deferred, it can get very expensive and difficult to schedule. As a profession, we need to do better.
