Most Technical Debt Is Consumer Debt

This is still a draft

Technical debt is probably the most used and misused analogy in tech. The term was coined by Ward Cunningham back in 1992, but that has taken on a life of its own since. The original analogy was that the interest is the time it takes to change things due to past design choices. The most common misuse is probably to use it as an excuse to do sloppy work or to rely too much on hacky, temporary solutions.

A common criticism (link to HN) of the analogy is that to take on debt is a conscious choice. A business takes on debt to invest in things they expect to have a higher return than their cost of capital. It could be new machinery to produce more or in marketing campaigns. The point is that the returns from the investment are higher than the costs of maintaining the debt and that the decision is very explicit.

Most technical debt I have seen is more like buy-now-pay-later (BNPL) loans. It's convenient and the plan is to pay it back before any interest accrues. But you're living sprint to sprint and before you know it the interest is accruing and it's higher than you expected. Before you know it, simple changes take longer and longer, making it harder to get around to deal with the technical debt so instead you take on more debt to cover the current interest payments.

So what is good technical debt and what is bad? Martin Fowler has a good classification by dividing it into a quadrant with deliberate and inadvertent on one axis and prudent and reckless on the other. BNPL debt would fit into the reckless and deliberate quadrant. It is all the unresolved comments on your PR's. It can be confusing names and magic numbers scattered around the code base, like doing price = price / 0.8 to remove the VAT. Before you know it, the VAT changes. It is all the mysterious variable names and function calls where the parameter ordering is critical since you call f(price, bid, fraction) instead of f(price=some_amount, bid=some_other_amount, vat=some_percentage), but g(bid, price, percentage) has a different order.

The good kind is the decisions that you know you'll have to revisit when you reach millions of requests per second. It is starting with a relational database and some schemas you know will change, but you don't yet know how. You developed things to the best of your understanding, knowing that it will change as you develop. You're developing a theory. The example with the slow simulations is a good example of good technical debt.

So how do you decide whether to take on technical debt? A lot of debt accumulate since there isn't an obvious answer where something belongs. Make your assumptions and interfaces clear. Tsumulathey might not hold and a decision might have been a bad one in hindsight. As you develop, your understanding increases and you might fit more and more to fit new changes into the previous design. The debt was worth it since it allowed you to develop your theory further.

The more interesting question is how to deal with existing debt. A good rule is to pay down debt that pays back immediately. This usually means time savings. If your CI/CD pipeline takes too long and this slows down the team by making the path to production difficult, it's usually an easy decision. If your alerts are too aggressive they cost focus and distract people. Visualising this can make a big difference in getting support to work on these kinds of things, but in a well-functioning tech organisation.

The debt that is more diffuse is more tricky to pay down. I've found that the only way is to do it as part of other work. Ideally, doing it makes the current task easier and faster to do as well. Then it's a no-brainer. Sometimes it doesn't, but it helps you and the team in the long term. In that case, just do it¹. If you have to ask you it should be for forgiveness. Many tech debt discussions shouldn't reach outside stakeholders. They are your domain. Kent Beck's advice of tidying as a way to get into a problem again is very good. Always be tidying.