Skip to main content

What is technical debt?

news #agile

Technical debt is one of the most well-known buzz words in the Agile community.

The idea seems fairly simple: when we don’t do things right the first time, we create debt that we should pay back. But the concept of technical debt is so often wilfully abused by the feature-greedy and those trying to please them.

The origins of technical debt

Ward Cunningham, the inventor of the wiki, first coined the phrase technical debt as a metaphor to explain to his non-technical employers why we should refactor code. Like many good ideas, it grew legs and soon became widely used and subject to many different interpretations.

Many leading figures in the Agile community have weighed in on what technical debt means. Uncle Bob (Robert C. Martin), one of the Agile Manifesto’s co-authors, wrote a blog post in 2009  called "A mess is not technical debt” which argues that cutting corners in code should not be considered technical debt.

A mess is technical debt

Although well-intentioned, and providing sound advice on how not to use technical debt, Uncle Bob’s post misses a fundamental point. This misinterpretation is at the foundation of almost all of the pain and suffering caused by poor interpretation of technical debt.

His mistake was to forget that technical debt is purely a metaphor. It’s not a solution or a problem. It’s a way of understanding the future consequences of our present actions. This misconception led Martin Fowler to define the technical debt quadrant.

The quadrant puts technical debt in the context of how we choose to take it on – in a reckless or a prudent manner. This in turn tells us a lot about the costs associated with that debt and our strategy, if any, to pay it back.

Exploring the metaphor

Drawing back to the origins of the metaphor helps us understand why this important: technical debt is a much richer concept than “rush code out and fix it later”. Think about personal debt...

Taking a low-interest mortgage on a house, paying it back early and then making a profit on the house is a prudent and deliberate way to use debt. This is a good metaphor for sacrificing some best practices in order to ship code earlier and paying back the technical debt so that you end up with a better product than when you started.

On the other hand, opening a new credit card to pay off another credit card which is maxed out on impulse purchases is a clear example of unsustainable debt. This is similar to trying to constantly produce the newest and shiniest features at any cost to your code base or architectural landscape.

Change your habits

The biggest mistake most people make with technical debt is focusing solely on paying it back. Don’t get me wrong – paying back technical debt is a good thing. But it’s not enough just to pay back technical debt when you’re accruing it at a much faster rate.

The traditional advice for paying off personal debt is to cut your cards, tighten your belt and create a repayment strategy. The equivalent in IT is to stop trying to push out more features than is realistic, improve the quality of your code and architecture, and dedicate a fixed amount of time to pay back technical debt.

In other words: stop accruing bad debt.

Following this advice is much easier said than done, but it’s the only sustainable way to write software and stay ahead of your competition.