Technical debt – when should you address it?

A term we have begun to use a lot more recently at Acora, ‘technical debt’ seems to be increasingly omnipresent in IT platforms everywhere! It sprung into our view this evening in a tweet linking an article at The Register: “COBOL-coding volunteers sought as creaking mainframes slow New Jersey’s coronavirus response.”

It may seem an extreme example – it’s certainly a very timely example – but as I mentioned above, this is an issue present in almost every platform I come into contact with.

Why is it an issue?

In the software development world, the term ‘technical debt’ has been around for a long time – Wikipedia defines it as: “a concept that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”

In my infrastructure world, ‘technical debt’ typically represents an item that was ‘de-scoped’ from a project to get it to the finish line quickly, deemed ‘too expensive/complicated/long’ to fix properly, or otherwise ignored for too long.

Typically, by the time we are brought in to look at it, that technical debt is stopping something important, whether it be the upgrade of your SQL estate, finally decommissioning that last stubborn Windows Server 2003 server, or getting your Cyber Essentials accreditation.

Where does the problem come from?

There are a few sources of technical debt, and each one requires a different approach, below are some examples of the most common ones we see:

1. Compatibility Issues

“I can’t get rid of X system because this Y system only works with X.” Probably the most common and usually the result of a Line of Business application with very specific requirements. This typically entails a conversation with vendors around compatibility, upgrades, or even a migration away from the existing system.

Whatever the technical solution, in our experience sometimes the best plan is to bring in a team with a very specific agenda – rather than trying to wrap the task into a wider project.

2. Cost issues

“Getting rid of X system will cost too much, we simply don’t have the budget.” Getting a business to allocate the budget can be challenging, “It works now, right? So why do I need to upgrade it?” – but it’s important to understand that security is a boardroom conversation. Ageing software, systems and processes invite security flaws through a lack of patching and the use of ageing protocols.  A security breach due to this can quickly escalate from lost productivity to lost revenue directly through fines, and indirectly through damage to the business reputation.

Sometimes, the best way to address it is to expose the cost of doing nothing!

3. Resourcing issues

“We want to get rid of X system, we even know how to get rid of it, we just don’t have the time.” This one requires little explanation and has the most obvious answer – get help. Either by boosting your capability to free up internal resources or by bringing in that specific team to deal with the issue directly.

Deal with it, before it escalates

Maybe it was highlighted by a recent audit, holding up a project, or maybe it’s an issue that’s playing on your mind, keeping you awake at night – in the modern world, technical debt is something that should be dealt with expediently, lest it winds up slowing productivity or innovation, or worse still – results in a security breach.

And remember, prevention is better than cure – if you don’t have any technical debt today, keep it that way by making sure those active or upcoming projects are “ready for innovation!”

For support with technical debt and help getting where you need to be quick, contact us. We’re happy to help.