Isometric illustration of a man walking while being chained to a computer screen with software on it.

Minimizing technical debt

6 min reading time

"Technical debt" is a metaphor introduced decades ago for project stakeholders to illustrate what we developers would call "refactoring". As such, the term might encompass everything that causes a slow down or friction in development. The overuse of this metaphor makes the term lose some of its strength.In this post I'll be describing and discerning a concise definition of "technical debt" to reach a better understanding of this metaphor, as well as providing a possible path for solutions for this issue.

What exactly is technical debt?

In a nutshell, technical debt is the increase of costs and a decrease in maneuverability of your organisation as a result of prior decisions that were made to save time or money when implementing new features or maintaining existing ones.
It usually occurs when the project codebase becomes overly complex, and when new systems aren't integrated correctly. This is due to a variety of reasons: from hastily made decisions, lack of (technical) knowledge or using outdated versions of software, amongst many others.

Some examples would be:

  1. Using and old version of Linux on your server that prevents you from using new features or applying security upgrades.
  2. A vicious circle of using a CRM system that is so old and customized that it's unfeasible to upgrade it, as that would mean a complete replacement of the system.
  3. Using similar systems with overlapping functions throughout different parts of your project.

Even though the term technical debt can mean many things, it does not serve for describing bugs in the codebase. Bugs are an opaque phenomenon: they are bound to features in your software. Bugs can be tested and identified pretty easily.
Technical debt is completely different in that its presence is almost intangible: it is bound to the decisions made in the architecture of your software, it is not bound to specific features. That's why the presence of technical debt is usually invisible and can unsuspectingly accumulate to cause big problems in the future.

Diagram illustrating the visibility and relationship of bugs vs. technical debt.
Diagram illustrating the visibility and relationship of bugs vs. technical debt.

Finding a path to solutions

Reading and informing yourself about technical debt is important, but how do you take some measures to actually resolve this issue?

Actually, financial debt has a lot of overlap with technical debt. Therefore, the techniques to manage financial debt lend a great way to assess and pay off technical debt as well. We're going to apply some of these techniques to figure out a clear path to move forward.

1. Identify and measure your technical debt

Identifying your debt is not easy. A good moment to pinpoint a debt is when your system is growing and needs new features. Developers in your organisation will voice their concerns and describe what obstacles lie on the road for implementing a new feature. Some of these obstacles are not about the complexity of writing the actual code, nor are they about expertise levels of the developers. Instead, they are a challenge because of a prior choice in the architecture of the system. At this moment, technical debt is much easier to identify than by doing an analysis after implementation.

As for measurement of technical debt: technical debt comes in multiple forms, depending on how much impact it has on your system and how much effort you will need to put in to pay off the debt.
You can simplify this process by placing your top ten ideas in a two-by-two matrix: cost to pay off the debt on one axis and the degree of benefits on the other. The matrix will hopefully provide a clear visual reference of which issues to prioritize.

Diagram for visualizing the cost to benefit ratio, indicating the priority of technical debt issues.
Diagram for visualizing the cost to benefit ratio, indicating the priority of technical debt issues.

2. Deciding what to do with each issue

How do you actually deal with the technical debt you identified? Each issue is unique and there are many options to take.

Perhaps the best choice is not to do anything. Debt that is assessed to have "small impact" or debt that as a "low interest rate" might be optimal to just leave it. The same goes for technical debt that has a high "prepayment penalty" of paying it off early. This is applicable to adopting or upgrading new systems. Strategically it might even be beneficial to stay one version behind and upgrading whenever the kinks have been worked out at someone else's expense.

Paying off the debt means that you will have to refactor your codebase and accept the cost hit. You can choose to do this immediately or gradually over the course of multiple sprints, improving the system in the process.

Outsourcing this process is another way to pay off your debt. It might ultimately cost more to outsource the execution of this process but by spreading out the initial cost and by bringing in a specialized party, it could be a great solution.

The rise of cloud-based computing and services could be yet another route. Leveraging cloud services can be an effective tool for reducing technical debt, both in expenses and shifting some of the development onto the cloud provider.

3. Creating a payment plan

After plotting your debts on the diagram above, you should see a relationship of high benefit/low cost per issue. This guides you to pay off the debts with "high interest rates" first.

Whenever you're considering reducing your technical debt, you should research alternative options of paying off the debt like mentioned in the previous paragraph. You should always put your options, and your "baseline" next to each other and plot them on a cash flow diagram. The diagram will represent the cost over time to pay off the debt.

Diagram for visualizing the cost to benefit ratio, indicating the cost of technical debt issues.
Diagram for visualizing the cost to benefit ratio, indicating the cost of technical debt issues.

The take-away

Technical debt can be a daunting topic. Elucidating previously hidden parts of your systems that are plucking money and manpower from your organisation is scary. Hopefully with the information here you can start by inventorying your technical debts and create an overview of which issue to tackle first.

Don't pay off your debts at once, and always research alternatives when the costs are high. Reducing your technical debt can be liberating!

Did I spark your interest?

Let's work together! Drop me a line at: