How I think about technical debt

Working at a venture-funded startup has added some nuance to how I think about technical debt: it's not about the debt itself, but the interest rate.

You begin accumulating technical debt the moment you check in some new code. By checking the code in, you are committing your team to the continued maintenance of the functionality you added. On its own, there is nothing inherently good or bad about this debt. What matters is the ongoing cost: the time and effort it takes to change or understand the code later. This is the interest on the technical debt. If a piece of code makes people go "kinda terrified to change the logic here tbh", then you are paying high interest on this code whenever someone interacts with it. The only code with a 0% interest rate is no code at all.

Writing code is only worth it when the benefits it grants are worth the maintenance costs. It might be worth it to write high-interest code if you think it will hardly be changed, but think hard about writing medium-interest code for foundational parts of the system that will be frequently touched.

This type of thinking makes it possible to talk more clearly about paying off technical debt. It is possible to build a collective understanding around how certain corners of a system cost more to change than others. It's likely that high-interest parts of the code are more prone to bugs. Working on high-interest code does not spark joy. I might even try to avoid it by taking on technical debt elsewhere. Given enough churn in a high-interest part of the codebase, there are real impacts on new feature velocity, employee retention and product health. This is language that startups understand. The problem is no longer about some code being inherently "bad" with the only solution being to "fix it". It is now about lowering the interest the company is paying on the code, which can take many forms: rewriting it, refactoring it, replacing it with a third-party library, requesting fewer changes in the affected area etc.