Technical debt is a tool

Early in my career, I treated technical debt like a disease. I wanted to avoid it, and I felt we'd failed whenever it appeared.

It never went away. Eventually, I had to find a more useful way to think about it.

A quote from Dormain Drewitz changed how I think about this: "All code is technical debt; we're paying different interest rates on it. Debt powers the economy and it powers your business. None of this is inherently good or bad. It's a tool."

That comparison took the shame out of the conversation. The analogy has limits, but the tradeoff is useful: people use a mortgage to buy a house they couldn't otherwise afford. A team can use technical debt to ship while parts of the architecture are still uncertain. In either case, the future cost belongs in the decision.

Service boundaries can be that kind of choice. I wrote about one team that accepted the extra coordination cost so it could learn in smaller systems.

Now, when I look at code, I try to see the decisions it records. Some code is cheap to carry for years. Other code charges interest every time someone adds a feature, investigates a bug, or tries to deploy it.

That changes the questions I ask. Did we take on this debt deliberately? Do we understand what it costs? What would tell us that it is time to pay it down?

I no longer expect a codebase without debt. I look for a team that knows which debt it has chosen and keeps checking the interest rate.