Engineering
Technical debt
The metaphor is precise and worth taking literally. Borrowing deliberately to hit a date is a legitimate financial decision. The danger is debt taken on without anyone recording that it was, because then nobody budgets for the interest and the team simply experiences the codebase getting slower to change without knowing why.
The interest shows up as estimates inflating for no visible reason, as a rising share of time spent on defects, and as senior engineers becoming reluctant to touch particular areas. Those are the metrics to watch; the debt itself is invisible.
Not all of it should be repaid. Debt in code that is about to be replaced is free. Debt in the part of the system every feature touches compounds fastest and should be paid down first.
Unmanaged technical debt is the usual reason a team that shipped quickly in year one ships slowly in year three, with the same people.
Commonly misunderstood
What people get wrong
The claim
“Technical debt means the code is bad.”
What is actually true
It means a trade was made. Sometimes it was the right one. The failure is not making the trade, it is not writing it down.
Where this comes up
Services where it matters
Related terms
Next step
Working through a technical debt decision?
Tell us the situation. We will give you the tradeoffs as we see them, including when the answer is that you do not need what you are being sold.
No pitch deck. A 30-minute conversation about what you are trying to achieve.