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.

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.