Technical debt is the engineering equivalent of financial debt: it lets you move faster today at the cost of paying interest tomorrow. Like financial debt, it is a tool that can be used wisely or recklessly. The key is intentionality.
Types of Technical Debt
Deliberate debt: You consciously choose to take a shortcut because speed matters more right now. Accidental debt: You did not know better at the time and the code reflects outdated understanding. Bit rot: External changes (library updates, new security requirements, scaling needs) have made previously good code inadequate.
When to Take On Technical Debt
It is rational to take on technical debt when: you are validating a hypothesis and the code might be thrown away, the business will fail if you do not ship by a certain date, or the cost of delay exceeds the future cost of refactoring. The key is to document the debt you are taking on and estimate when you will need to pay it down.
When to Pay Down Technical Debt
Pay down debt when: it is slowing feature development measurably (track cycle times), it is causing production incidents, it makes onboarding new engineers significantly harder, or it creates security vulnerabilities. Use data, not feelings, to prioritize which debt to address first.
The 20% Rule
Allocate approximately 20% of each sprint to addressing technical debt. This prevents the debt from compounding to a point where it requires a full rewrite. Frame it to stakeholders as 'investing in velocity' rather than 'paying down debt.'
Documentation Is Debt Prevention
The single most effective way to prevent technical debt is documentation: architectural decision records, code comments explaining why (not what), and up-to-date system diagrams. When future developers understand the context of past decisions, they are less likely to introduce new debt.
