What is technical debt and when should you accrue it?
Technical debt exists everywhere in IT and is an inseparable part of software development. To discuss technical debt properly we should first define what it means.
If technical debt is defined purely through the debt analogy the clearest definition is a shortcut that eases development in the short term but creates costs in the long term. The debt is repaid through refactoring and the interest is the cost caused by the existence of the debt.
A very typical reason for taking on technical debt is schedule pressure as a release approaches. New functionality may be implemented by adding exception logic directly into existing code even if it conflicts with the software architecture. In practice this could mean adding a special rule for a single user into one application even though the logic belongs to a service that manages permissions for the entire platform.
The interest on technical debt
The amount of technical debt in a system can be estimated relatively easily but interest is a more complex phenomenon. Technical debt is often thought to mean messy code and interest the increased development cost that follows from it. Interest is not limited to slower development. Depending on the nature of the debt its effects can be varied.
Some examples of debt and interest from previous projects:
- A chosen library does not support all required use cases
- A slow algorithm increases web application latency
- Insufficient testing results in more bugs
- Poorly optimized queries require unnecessarily expensive data infrastructure
- A complex codebase makes onboarding new developers harder
All additional cost and harm caused by debt is interest.
When is technical debt worth it
Should interest be avoided at all costs and a completely debt free system be the goal Not necessarily. One of the biggest differences between financial debt and technical debt is that technical debt or its interest does not always need to be repaid. When software is retired the associated debt disappears as well. If for example the slowness of a poorly optimized algorithm causes no concrete harm the interest remains mostly theoretical.
When taking on technical debt a few things should be weighed:
- How much time does taking the debt save
- What is the interest caused by the debt
- What is the cost of refactoring caused by the debt
Accurately predicting interest and refactoring needs is difficult but at least in theory debt should be taken if its costs never exceed its benefits. In software that is approaching end of life it can be sensible to have a significant amount of low interest debt that has produced savings earlier in the lifecycle.
Final words
Reality is never as neat as textbook examples and debt often accumulates in an uncontrolled way without proper planning. Although in an ideal case debt disappears as a side effect of retiring software quite often debt itself becomes the reason to get rid of the entire system.
