Technical Debt
| Shortcut taken | Debt incurred | Cost if ignored |
| Hardcoded values | Config changes require code changes | Grows with every new environment |
| No tests written | Changes made with no safety net | Every change is a risk |
| Duplicate logic | Bug fixed in one place, not the other | Bugs multiply silently |
| Quick fix over proper fix | Workaround on workaround | System becomes unmaintainable |
| No documentation | Only the author understands it | Knowledge leaves with people |
"Technical debt is borrowed time. The interest always comes due."
212
Technical debt is like financial debt. You take a shortcut today: you borrow against the future. And just like financial debt, it accumulates interest.
The shortcut is usually made with good intentions. The deadline is tomorrow. The quick fix works. We will clean it up later. And in the moment, that is often the right trade-off.
The problem is later. Later, there is another deadline. And another shortcut. The debt grows. Each shortcut makes the next one harder, because you are building on an unstable foundation.
Features that should take days take weeks. Bugs that should be simple to fix take hours to trace. New developers cannot understand the codebase. Nobody is confident changing anything.
The solution is not to never take shortcuts. It is to take them consciously and pay them down deliberately. Track the debt. Set aside time to refactor.
Technical debt is not a sign of bad programmers. It is a sign of programmers under pressure. The failure is not in making the trade-off; it is in forgetting it was made.
Borrow consciously. Pay back regularly.
213