Technical debt

Technical debt is the extra work a team will have to do later because of a quicker, messier choice made now. The programmer Ward Cunningham coined the metaphor in 1992 to explain it to non-technical managers: shipping imperfect code is like borrowing money. You get something sooner, but you pay interest: every future change in that area takes longer and breaks more easily, until you pay back the principal by cleaning it up.

Debt is not automatically bad. A startup testing whether anyone wants its product may reasonably cut corners, the same way a business takes a loan to grow. The trouble is debt nobody tracks. It piles up from many sources: rushed deadlines, copy-pasted code, missing tests, outdated libraries, an early design that no longer fits what the product became, or simply people who left without documenting anything.

You notice it when simple requests start taking weeks, when each fix causes two new bugs, or when only one person dares to touch a certain module. Teams manage it by naming it in their backlog, reserving part of each cycle to pay it down, and refactoring as they go. Ignored long enough, it can make a system so costly to change that a full rewrite looks tempting, which is its own risky bet.