That’s the ambitious title of my presentation that I held at Statens Pensjonskasse on their agile day. Technical debt is a wide topic, so having an understanding of what it means is important before the discussion on how much can be started. I think the TechnicalDebtQuadrant is useful for introducing non-technical people to the different aspects of technical debt.
To justify taking up technical debt is easy, it could be what the project needs in order to be a success. Not solving all problems at once and focus on delivering customer value is a good agile tradition, and here is where technical debt in the form of shortcuts come in handy. The risk is that the shortcuts are too many, and decreases the quality so much over time, that the project could be held to a standstill.
So again, how much can be justified? Of course that answer can’t be given in numbers. I gave my audience two examples to consider. The first example contained a design shortcut where technical debt could be said to represent 50% of the initial budget. The other example represented a microscopic debt in comparison. So what was the conclusion about these two scenarios? It is not how much, but how it’s done, that is important.
In general I would suggest the following rules when considering technical debt:
- Don’t take up a lot of small debt, the interest is high
- Be careful, not every shortcut is a smart choice
- Be methodical, debt should be paid
- Be open about it, give the customer the right expectations about future maintenance and development