Menu

Technical debt – when should you address it?

By David Murphy, Solutions Architect at Acora

A term we have begun to use a lot more of recently at Acora, ‘technical debt’ seems to be increasingly omnipresent in IT platforms everywhere! It sprung into my view this evening in a tweet linking an article at The Register:

The title read: “COBOL-coding volunteers sought as creaking mainframes slow New Jersey’s coronavirus response”

Source:  https://www.theregister.co.uk/2020/04/05/new_jersey_seeks_cobol_volunteers

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.”

Source https://en.wikipedia.org/wiki/Technical_debt

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:

  • 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.
  • 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. Aging software, systems and processes invite security flaws through a lack of patching and the use of aging 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 exposing the cost of doing nothing!
  • 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 resource, 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 quickly, contact us. We’re happy to help.

Got a question?

Need to speak to someone about our services? Get in touch! We're happy to help.

  • This field is for validation purposes and should be left unchanged.