Home Insight Let's talk about technical debt
Digital Transformation

In a previous article ,'The ticking time bomb in your in-office server room' we mentioned the term ‘technical debt’, referring to the technical problems that can accumulate from making quick fixes, or ignoring problems altogether. Given how many quick fixes businesses made in the early days of enforced remote working, it’s important to understand how you accumulate technical debt, and its potential impacts.

[Read: Why you shouldn’t have your system backup stored locally]

Old desktop computer dirty cream colour

What is technical debt?

The term ‘technical debt’ finds its origins in the software industry, where it is used to describe the problems (debt) that can arise out of producing imperfect code – typically, when speed or cost of delivery is prioritised over attention to detail. For example, this could manifest in a code that works perfectly with one operating system, but doesn’t translate to the upgraded OS. The concept can also be applied to other areas of IT, such as network or infrastructure platform design, or even wider infrastructure like power and connectivity. Working with a data centre can be a quick and easy way to 'pay off' the technical debt in your physical infrastructure.

At its core, technical debt is a great way of thinking about the design and implementation choices made in the early stages of a technical project (usually for speed or cost reasons) or when changes are being implemented without good quality control. This 'debt' causes future additional work (the 'interest'), over and above if the design and implementation was done differently in the first place.

Yes, it is a lot like ‘a stitch in time saves nine’. But technical debt is less black and white since sometimes taking on technical debt is a conscious choice for a business.

Interest

In this analogy, interest is typically paid in productivity – the time lost while you upgrade, implement a change or add a new feature that should have been in the initial rollout. For example, if fixing a problem takes 5 days and it would only have taken 1 day to build that solution in from the start, you have paid 4 days interest. (Of course, lost productivity can be very expensive, which is one of the reasons why thinking of it as debt can be helpful.)

With financial debt, interest is typically fixed over a period of time. With technical debt, the interest rate is variable and so is the repayment period.

Technical debt can become an obstacle at any time; with increased usage, new interactions with other hardware or software, or even in the event of a cyber attack. Technical debt effecting your cyber security could be the most devastating if you're attacked, so make sure you have a comprehensive suite of security solutions.

One thing is almost always guaranteed with technical debt – if you don’t have a plan for it, it’s going to come calling at the most inconvenient time. The most important thing about interest is to be aware of it and have a timely repayment plan, which brings us on to the different types of technical debt:

Good debt

Good debt is debt you’ve chosen to take on because the short-term benefits are worth the interest.

Mortgages, student loans, and credit cards are all examples of financial debts that have become a very normal part of our lives. Sometimes you need to get into debt (financial or technical) to give your business a jump start.

Knowingly cutting corners in the early stages of projects can get you off the ground quicker, which is important when time is of the essence. Alternatively, there is the known unknown – required changes that will become clear once your project (software or hardware) has been in use for a while. Sometimes you just have to take the leap of faith, knowing there will be work to do later on down the line.

Unknown debt

Unfortunately, technical debt is often taken on inadvertently by people who don’t understand the consequences of their decisions – or who are under too much pressure to give thought to the long-term consequences. They might be kicking the can down the road, hoping for it to be someone else’s problem at some other time, or they might not know it’s there at all – the most dangerous position to be in. Assets acquired in a merger/acquisition, for example, can lead to inherited technical debt – as can staff turnover, particularly if the IT department operates quite distinctly from the rest of the business.

Auditing your digital infrastructure, especially after inheriting it from another team, will prevent you being caught out by unknown debt.

Targeted debt

The best kind of debt is the targeted kind – that which you are not only aware of, but actively trying to eliminate. This could be done incrementally or in solid blocks, but either way you are paying it off – and avoiding the fallout of accumulating interest.

Your aim should be to transform all of your technical debt into targeted debt, to stay proactive and prevent yourself becoming reactive to problems in your system.

What to do about debt

As with so many things, you can’t manage what you don’t measure. An audit of both your software and hardware systems should give you an idea of both your known and unknown debt. With this information to hand, you can plan the fixes in order of priority. For example:

  • Can your IT infrastructure survive another 6 months of remote working?
  • Is your glitchy internet connection trying to tell you something?
  • Is that software upgrade you’re considering going to wreak havoc in your old files?

As you go through the process, challenge not only the contents of your IT infrastructure, but also the supporting facilities to judge their suitability to support your long-term business strategy. Colocation services can help future-proof an IT system and eliminate technical debt by hosting it in a more resilient environment. Or moving to a private cloud might be the way to leave behind your legacy (and debt-ridden) systems.

If you need a helping hand, shoulder to cry, or listening ear, get in touch, we’re always happy to talk through your current and future requirements.

New call-to-action