Glossary
Technical debt is the accumulated cost of implementation choices that were quicker at the time but make future change harder. Like financial debt, it is not inherently bad; it becomes a problem when nobody is tracking the interest.
Some is accidental, accumulated through turnover, deadline pressure and decisions made without the context to know better.
Estimates inflate for no visible reason, small changes require touching many files, releases become risky, and the team spends more of each week on maintenance than on anything new. Those symptoms are usually visible to a business long before anyone names the cause.
Full rewrites take longer than expected, freeze delivery while they run, and reliably reintroduce bugs the original had already fixed. They are occasionally correct and usually a way of avoiding a harder diagnosis.
Usually not first. Rewrites freeze delivery, take longer than planned and lose behaviour the original had already got right. Incremental replacement of the parts that change most often is lower risk and delivers value sooner.
In delivery terms rather than code terms: how long a typical change takes now versus a year ago, and how much of the team's time goes to maintenance rather than new work. Those are the numbers debt actually moves.
Technical debt is the accumulated cost of implementation choices that were quicker at the time but make future change harder. Like financial debt, it is not inherently bad; it becomes a problem when nobody is tracking the interest.
