How I Think About Technical Debt

I used to describe any code I disliked as technical debt. That made the backlog longer without making the decisions clearer. A more useful question is what the current design costs us when we try to do something that matters.

Put a real change beside the concern

A concrete example changes the conversation. If a routine policy update requires three coordinated releases, the cost is visible. We can compare an improvement with other work and decide when it is worth doing. The same design may be perfectly acceptable in a part of the system that rarely changes.

Not every imperfection deserves the next week of attention.

I still value clean code, but I try to connect cleanup to a capability or a recurring source of friction. That makes room for deliberate compromises. It also helps me recognize when a small repair is enough and when the underlying design really needs to change.