We’ve all been on that project at some point. You know – the one where timelines are ridiculously tight, deadlines are looming, we need to get those features out and make that release date! That’s when you face the all-too-familiar developer-dilemma where you have to choose between doing it right and doing it quick. Of course, none of us like writing quick messy code. We’re professionals after all. We only do this because we intend returning to the code and implementing the better, more sustainable approach at some point. This is called Technical Debt.

What is Technical Debt?

Technical Debt is a metaphor developed by Ward Cunningham to help explain this idea. Similar to financial debt, when we take out a loan, we incur interest payments on it. The debt yields value, but depending on the amount of debt, it most likely needs to be paid off as soon as possible, otherwise we may be crippled by the interest payments in the long term.

Types of Technical Debt

Martin Fowler’s Technical Debt Quadrant (see below) presents the 4 types of Technical Debt that may be incurred.

Inadvertent Debt – This is not done consciously, the team is unaware that they are incurring debt. These issues are identified further down the line.

Deliberate Debt – Occurs when the team knows they are taking on debt, they have considered the options as well the consequences and made an informed decision.

Prudent Debt – Debt that makes sense. Usually incurred because of timelines. Often this is manageable debt that has been considered and it has been decided as the best option.

Reckless Debt – Often occurs because of bad design/lack of time. This is not necessarily inadvertent.

Prudent-Deliberate debt is considered the only actual/valid form of Technical Debt. The others can be attributed to poor specs, lack of skills/incompetence, bad design decisions etc.

Is Technical Debt a no-no?

Whilst we would all prefer to live a debt free life, unfortunately that is only possible in an ideal world. Every project incurs technical debt at some point. It’s virtually unavoidable. As your code base grows and timelines shrink you start picking up technical debt. Which is OK. Agile is, after all, about continuous improvement. As long as the debt is prudent and the impact/consequences have been carefully considered, I don’t believe technical debt should be feared. However, it does need to be managed and controlled, otherwise you end up with layering i.e. compounded debt, when the original debt wasn’t paid off, and more debt was taken on, the problem now becomes a mammoth task.

So how do you manage Technical Debt?

• Track technical debt - Log tasks in an issue tracking system. This backlog must be visible to the team so they are aware of the amount of technical debt as the project progresses.
• Schedule payoffs – If it isn’t scheduled it won’t get done. Consider the impact of the debt and decide how soon it needs to be paid off. If the interest is small, it may be acceptable to delay until future iterations.
• Measure the cost of technical debt as the project progresses. In time and money. As much as possible. This is useful in identifying whether the debt was worth it by comparing the short term benefit vs the long term cost of paying it off.
• Create a sense of responsibility amongst the team. Often debt gets logged and shelved…indefinitely. It’s deprioritized. This causes issues further down the line. It’s important that developers are held accountable for design decisions and are encouraged to pay off debt e.g. make it compulsory for each team member to pay off some debt in a specified time period over the project.

Technical Debt is a necessary evil but it’s important to have the right attitude when it comes to taking it on. It must be used with caution.

If you can’t find the time to do it right, when will you find the time to do it over?

Make the time.

If that’s not going to happen…you will be shooting yourself in the foot and your project will become a maintenance nightmare.