After this lesson, you will be able to: Define technical debt honestly, recognize how it accumulates, explain it to non-engineers in business terms, and decide when to pay it down versus live with it.
Technical debt is the gap between the code you have and the code you would write if you had time. Some of it is fine, even smart; some of it quietly grinds a team to a halt. The engineering skill is not avoiding all debt (impossible) but managing it deliberately and being able to argue for paying it down in language a product manager will fund.
The metaphor, coined by Ward Cunningham, is financial: taking a shortcut now to ship faster is like borrowing money. It can be the right call, but you pay interest, in the form of extra effort on every future change, until you pay down the principal by refactoring. Not all debt is bad. Deliberate, short-term debt to hit a launch is a sound trade. The dangerous kind is the debt nobody chose and nobody tracks: it just accretes until 'simple' changes take weeks.
Deadline shortcuts that never get revisited. Copy-paste instead of refactoring, so one bug now lives in nine places. Dependencies that go years without updates until a security patch forces a painful jump. 'Temporary' workarounds that outlive the people who wrote them. Missing tests, so nobody dares change the scary module. Knowledge debt, where only one person understands a system and they are on vacation. Most debt is not one bad decision; it is a hundred reasonable small ones with no cleanup budget.
Pay down debt in code you are about to change anyway (the boy-scout rule: leave it cleaner than you found it), in hot paths that the whole team touches, and when interest (slowed delivery, repeated incidents) is clearly higher than the cost of fixing it. Do not pay down debt in code that rarely changes and works, in something you are about to delete, or by stopping all feature work for a giant rewrite (rewrites are how teams lose a year). Track debt as tickets in the backlog so it is visible and prioritized alongside features, not as silent code rot.
Calling every piece of code you dislike 'tech debt.' Debt is a shortcut with real interest, not just a style you would not have chosen. Hiding debt from product instead of translating it into velocity and risk they will fund. The big-bang rewrite. Incremental paydown (the strangler-fig pattern) almost always beats stopping the world to rebuild. Never writing debt down, so it stays invisible until it is a crisis. Make tickets. Gold-plating: paying down debt in code that never changes, which is effort with no return.
Pick the most effective framing.
Sign in and purchase access to unlock this lesson.