Every organisation I have worked at has struggled with technical debt. But the truth is that technical debt can be an inevitable part of the software development process.

But what exactly is technical debt? And how can we deal with it? I've been interested in this topic recently, so I've been doing some digging and wanted to share what I've learned.

I'm certainly not going to be getting into the nitty gritty of dealing with tech debt in this article, but I'm going to cover:

  • What technical debt is
  • The forms technical debt can take
  • Some useful resources to tackle techncial debt

This article certainly won't be exhaustive, but will hopefully serve as a concise introduction to the topic.

What is tech debt?

Technical debt – also known as "tech debt" or "code debt" – accumulates when engineers take shortcuts in order to reach their goal more quickly.

It's sometimes necessary to take on tech debt. Teams accumulate tech debt precisely because it allows for things to be shipped faster.

But just like a real debt, tech debt has costs. But in this case, the cost isn't paying extra interest, like you would with a financial loan. Instead, the cost is things like...

  • delayed software releases
  • buggy software that doesn't do the job it's meant to do
  • annoyed customers that might go to competitors
  • unhappy engineers that might quit
  • ever-growing amounts of time sunk into maintenance

If these things are allowed to compound, they all have the potential to impact the bottom line.

To avoid compounding problems (just as you might compound interest with a financial loan), it's crucial to pay back the debt in an orderly manner. This is the tough part. Often there isn't a coherent plan to pay back the debt, a good system for keeping track of it, or the cause of the debt gets forgotten or muddied. When this happens, taking on the debt could have been considered, in hindsight, a false economy.

Eventually, all debt has to be repaid one way or another..!

What it isn't

Tech debt isn't the same as bad or broken code.

When an engineer or a team takes on tech debt, it's generally a conscious decision to exchange achieving a goal faster for paying the debt back later.

This is a bit simplified, but if you'd like to learn more you can do so here.

There's an advantage to taking on tech debt which has the potential to pay off. But writing bad code is just writing bad code..!

What forms can tech debt take?

1. The code itself

When people think of tech debt, they usually think of code. And this is the most apparent kind of tech debt.

A range of factors can cause tech debt in code. Here are a few...

  • Poor review processes
  • Rushed or non-existent onboarding of engineers
  • Poor or non-existent coding standards
  • Poor project or time management

2. Knowledge gaps

Tech changes all the time. This makes keeping up an enormous challenge.

Sometimes the gulf in understanding between management and the tools engineers use – not to mention between engineers and their tools – is simply too great. This leads to poor software and infrastructure choices being made.

There's a cost to using the wrong tools in the wrong places. Things are less efficient, devs are more frustrated, customers are less happy, money is wasted. Tech debt certainly isn't always about code.

3. Documentation (or lack of it)

Let's be real – cutting corners on documentation is common. Many engineers are begrudging about writing it. And fair enough – they love writing code, not docs!

When time is tight, documentation is a most tempting victim.

But there's nothing more frustrating than poorly documented code. And most engineers have been in the somewhat unfortunate situation of simply having to figure things out by themselves, with no docs to guide them.

4. Poor testing

Sometimes, features have to be rushed through. When this happens, testing can begin to feel optional – particularly in small teams that lack roles like DevOps and QA.

Tackling tech debt

When managed correctly, it's entirely possible to minimise the impact of accumulating tech debt, making it worth the trade-off for shipping faster.

I'm not going to get into a lot of detail here, but I'm going to suggest some resources that might be helpful.

In a nutshell, we need to build systems to make it easy for engineering teams to report tech debt, and then to prioritise and fix them.

Here is a great article all about strategies to prevent tech debt

If you want to track and manage tech debt, here are some great tools you can use.