"Technical Debt" is a metaphor coined by Ward Cunningham to explain to finance stakeholders why we need to refactor. Like financial debt, you take a loan (shortcuts) to buy something now (features), but you have to pay interest (slower development) later.
But in finance, debt isn't inherently evil. Companies take on debt to grow. They use leverage.
The same applies to engineering. The goal isn't "Zero Technical Debt." The goal is Managed Leverage.
Good Debt vs. Bad Debt
Bad Debt is accidental. It comes from sloppy coding, lack of knowledge, or laziness. It’s the variable named x, the copy-pasted function, the swallowed error. This debt has a high interest rate and buys you almost nothing.
Good Debt (or Leverage) is intentional. It's saying, "We won't build a generic, scalable notification engine right now. We'll hardcode these three email templates so we can launch next week and test if anyone even uses this feature."
You are trading future maintainability for present learning. That is a smart trade if you plan to pay it down.
The Bankruptcy Event
The problem arises when you treat the loan as revenue. If you keep taking shortcuts without ever paying down the principal, you hit technical bankruptcy.
Signs you are near bankruptcy:
- Simple changes take days. You touch one file and break three others.
- Onboarding is a nightmare. New hires take months to become productive because the system logic is spaghetti.
- Fear. Developers are afraid to deploy.
Tracking Your Leverage
You can't manage what you don't measure. While you can't quantify "debt" directly, you can see its shadow in your metrics.
- Rising Change Failure Rate: The system is becoming fragile.
- Increasing Cycle Time: It takes longer to wade through the mud.
- Code Churn: You're constantly fixing the same modules.
Velocinator helps you spot these trends. When you see velocity dipping despite team effort remaining high, it's usually interest payments eating your capacity. That's your signal to stop borrowing and start paying down.