Think of it like financial debt. You can 'borrow' time by writing quick-and-dirty code to launch a feature today. But eventually, you have to pay the 'interest'—which is the extra time spent fixing bugs and refactoring later.
Some tech debt is intentional (strategy), but too much can paralyze a development team.
Tech debt works exactly like a credit card. It lets you buy something (a new feature) today that you can't afford (don't have time to build perfectly).
But if you only make minimum payments, the interest (complexity) compounds. Eventually, adding a simple 'Hello World' button takes 3 weeks because the codebase is a tangle of hacks.
All tech debt is bad.
Reality:False. If you are rushing to hit a market window, 'Prudent' tech debt is good strategy. Just make sure you plan to pay it back.
We can fix it all in one 'Refactoring Sprint'.
Reality:Rarely works. Paying down debt should be a continuous habit, like doing the dishes. 10% of every sprint should be dedicated to cleanup.
Hard-Coding: Putting a special holiday banner directly in the HTML instead of building a CMS feature for it. Fast now, painful later when you need to remove it.
Dependency Updates: Ignoring software updates for 3 years. When you finally try to update, everything breaks.
Usually management pressure ('We need this live Friday!') combined with developer shortcuts. It's a shared responsibility.
You can't put a number on it easily. But 'Code Complexity' tools and 'Bug Rate' are good proxies.
Don't let technical jargon slow you down. Get a clear strategy for your growth.