Technical debt is mostly misunderstood. It is often framed as "messy code" or "lack of tests." In reality, technical debt is a financial instrument. Like financial debt, it allows you to leverage speed today at the cost of future obligations. The problem is not the debt itself; it is the inability to service the interest payments, which eventually leads to technical bankruptcy.
The "interest" on technical debt manifests in velocity drag. Features that used to take 2 days now take 2 weeks because the system is fragile, confusing, or tightly coupled. When 50% of your engineering capacity is spent "keeping the lights on" (KTLO) or fixing regressions, you are effectively paying high-interest credit card rates on your codebase.
This is often invisible to management. They see a team of 10 engineers and wonder why output has slowed. They don't see that 5 of them are just shoveling coal to keep the engine running.
Martin Fowler's logical quadrant of technical debt is a useful framework for categorization:
"We need to ship for Black Friday. We will hardcode this integration and refactor it in January." This is good debt. It is a conscious business decision with a repayment plan. You are borrowing speed to capture market opportunity.
"We didn't know how to structure this React app, so we just put everything in one file and used 'any' everywhere." This is bad debt. It stems from incompetence, lack of mentorship, or laziness. There is no plan to pay it back because the team doesn't even realize they borrowed it.
Code that sits untouched creates debt. Libraries deprecate, security vulnerabilities are discovered (`npm audit` nightmares), and the mental model of the team drifts away from the code's intent. "Legacy code" is just code without tests that you are afraid to change.
You cannot simply "stop everything and rewrite." That is the most dangerous phrase in software engineering. Netscape killed their company by doing a full rewrite. Instead, institute a "Debt Ceiling" and a repayment strategy:
Engineers often fail to communicate debt because they speak in technical terms ("The code is messy"). Business leaders don't care about clean code; they care about speed and risk.
Do not say: "We need to rewrite the auth service because the code is spaghetti."
Do say: "The current auth service is slowing down new feature development by 40%. It also introduces a risk of security outages. Investing 2 weeks now will prevent an outage and speed up Q4 roadmap delivery."
Translate technical debt into financial risk and opportunity cost.
Sometimes, the interest payments are so high that you cannot ship any new features. You are in technical bankruptcy. In this state, a "Strategic Rewrite" might be the only option. But this is the nuclear option. It requires a "Strangler Fig" approach: building the new system alongside the old one and gradually migrating traffic, rather than a "Big Bang" switch-over.
Software is never "finished." It is a living garden that requires constant weeding. If you stop weeding, the weeds will take over. Treating technical debt is not a project; it is a lifestyle. It is the hygiene of a high-performing engineering team.
Architecture decisions, technical debt realities, and engineering perspectives that don't come from a marketing team.
Delivered when there's something worth saying. Not on a schedule.
No spam. Unsubscribe anytime. Your email stays private.
