How to measure and remove technical debt

Learn how you can identify technical debt in your organisation and how much of your time should be spent working on it from Ten10 Head of Cloud & DevOps Practice, Matt Smith

When it comes to software engineering or operations the most critical factor that determines an organisation’s success is how it manages its technical debt. In this article, Matt Smith, Ten10’s Head of Cloud & Devops Services will cover what technical debt is, how to track and measure it, how to manage it, and most importantly how much time and effort should go into resolving it.

What is technical debt?

Technical debt is when a previous decision is no longer fit for purpose so you need to refactor to resolve a new issue or to mitigate a new issue. This occurs when you knowingly or unknowingly decide to deliver something in a specific way. What once was a pragmatic and sensible solution can become technical debt as the needs of the software or solution evolve through use.

But technical debt isn’t strictly negative. Yes, it reveals known flaws with your current solution but it also enables you to make pragmatic decisions knowing you are creating a future problem that you are not simply going to forget about.

The most important thing to realise about technical debt is that everything has technical debt. While it’s not great, it’s not terrible either and it can be good if managed appropriately.

How to track and measure technical debt

It is vital to ensure that technical debt is tracked. Not tracking it is like burying your head in the sand – it doesn’t mean that the bad thing you’re avoiding won’t happen because you can’t see it. So if it’s going to happen anyway, at least track it. That way you have both visibility and information so you can make informed decisions about what risk a product is taking and how you should prioritise work for your team.

You should ideally track technical debt in an issue tracker like Jira or GitHub. As long as it’s documented (electronically) it should have its own flag so it can be easily identified and tracked. Technical debt should also be easy to log. As long as it is descriptive and articulates the risk/problem, that is good enough. You want to reduce the barrier to entry on creating technical debt so it is as easy as possible to create it. This will ensure that technical debt is created regularly and appropriately giving you visibility of the risk.

At some later point, you will need to go through your technical debt items to size and prioritise them. You can rewrite them at this stage but it is important to absolve this from the people creating the items as much as possible. You do not want the creation of technical debt items to be seen as a chore as this will just lead to no one raising the items to begin with.

Once you have sufficient visibility of your technical debt, you can measure it by sizing the debt like any other piece of work and comparing it to your existing backlog of changes. This is called your Technical Debt Ratio, although you can also express it as a simple percentage.

How to manage your technical debt

With your tracking and measuring established, you can start dialling in an acceptable amount of technical debt for your team to work on. I would guess that number would be between 5% and 15% of your team’s time, depending on its size and the impact of the product not functioning. The important thing you should notice is that as your technical debt decreases you should have fewer service disruptions and the implementation of new work should be quicker (as you don’t have to resolve technical debt while adding new functionality into the mix).

You will always have some technical debt on a live and healthy product or service, so if you see that your Technical Debt Ration is quite low, or just feels low based on your experiences, I suggest you hold a technical debt workshop. This should be roughly an hour and dedicated to discussing the problems you know affect you but are not identified or tracked. This also allows the team the opportunity to raise their own concerns. If after this your technical debt is still very low, the reason may be something else – your team may be too big or the product may not be successful.

Setting an upper bound to the amount of technical debt you allow is equally important. At peak performance, you should be spending approximately 20% of your time resolving technical debt or adding improvements to the system because the technical debt is unimportant or non-existent. If you are spending 20% of your time working on technical debt resolution and the amount of technical debt is rising this is okay in the short term (1-3 months) but not the long term. It’s hard to define an upper boundary, but if I had a project where 20% of the work to be done was technical debt I would concentrate on resolving that debt unless the business was about to go bankrupt by not implementing a change.

While technical debt may initially be above 10%, particularly as workloads burst or new solutions are implemented, around 10% is a reasonable target to maintain.

Resolving technical debt

The best way to stay on top of technical debt is to make it part of your regular process. Where I have had the most success is when I have been allowed to allocate 20% of my team’s effort to what we as a team determine is important, be it technical debt or improvement activities. This was always stuck to and we sized our work in a way where we had more consistency in delivery rather than higher throughput. This allowed us to have additional time to safeguard that 20% from ad-hoc work requests that came up.

Leaders from large organisations always ask me “How were you successful?” and I put my success down to this 20% rule. By accepting things are not perfect and finding any way possible to work on reducing the technical debt, you eventually get to a point where the debt you have just isn’t that important to resolve and instead, you can focus that 20% towards improvements that benefit your team and the business as a whole, like self-service.