The Cost of Software Maintenance: The Qualitative Cost of Old Software

The start of any new project normally weighs up questions such as “What’s the expected ROI (return on investment) of this project?” or “If we provide this feature, what’s the increase in cost going to be?”. These are excellent questions. But how do you answer these when it comes to maintenance? What do you do when you have a piece of software that works, but has not been worked on in years?

That old faithful, the thing that keeps the lights on while the rest of your company is trying to think of new ways to innovate and increase your gross margins. She was there making you money when that last idea only boosted MAU (monthly active users) by 1%, but cost 5 times more to implement. You didn’t have time to update to the latest LTS (long term support) but you got that new feature out on time. Onto the next idea, and on it goes until you are so far behind it’s now going to take longer to update. But what’s the return on investment of updating software?

Keeping software up to date is easy when all you have to do is bump the version number, but when it requires a code change, there never seems to be a good time to do it. How do you tell your product team that you need time to update software so you can’t work on that new feature they want? No, patching a security vulnerability isn’t going to increase revenue, but it may stop a future attack IF we are ever attacked. Once a piece of software is deployed in the wild, we don’t think about how long it’s going to be there for, nor do many teams have the amount of people it requires to support that software. As long as it’s running and making us money, it’s sunshine and rainbows and onto the next piece of work that will make us more money.

Maintenance is the hidden cost that increases every year you have software running. It doesn’t just accumulate by itself, it’s every new feature you add increases the cost of maintenance, every LTS version you miss adds to the debt. Until you can’t pay the bill anymore. Now to update, it’s going to take an entire team of engineers months to catch up. How much money is that going to make us this quarter? Nothing? It’s only going to do what it already does? Who is going to approve that?

Most businesses don’t have the same resources as big tech. They don’t have an enormous engineering arm that can support and develop new features. They all too easily fall into the trap of coming up with a new idea, after a new idea. Develop it. Release it, move on to the next idea. As businesses grow and develop new products, that maintenance debt just gets bigger and bigger.

Instead of asking what’s next when completing a new feature or product. We should be asking. How do we support and maintain this? Most LTS languages have a release schedule, this means that even before a new LTS is released, you can schedule in the required maintenance. New tools are also available, like Dependabot which will bump a new version for you, package managers even have audit commands to shame you into updating your software. There is never going to be a good time for maintenance. So do it now.

Key Takeaways

• It’s hard to put an ROI on maintenance, or attributing a cost to not doing maintenance.
• As we leave software running without updates, we begin to accrue technical debt.
• The more technical debt you have, the longer it takes to make changes or improvements to that software.
• Microservices offer an easy out, you can replace outdated modules of software easier than replacing a monolith.
• There are tools out there that help you keep software up to date.