← All Essays/ESSAY #04/Mar 18, 2024/5 min read

On technical debt — a different frame.

Technical debt is not a failure. It is a design decision about the allocation of future work. The question is whether you made it consciously.

EngineeringCraftArchitecture

Technical debt has a reputation problem.

The phrase comes loaded with shame. It implies negligence. It suggests that someone, somewhere, took a shortcut they shouldn't have, and now everyone is paying for it.

Sometimes that's true. But more often, technical debt is something else entirely: a record of decisions made under conditions that no longer exist.

Debt as a historical document

Every codebase is an archaeology site. The layers tell a story.

The function that does three things because, when it was written, there were only two things — and the third was added as a one-liner that everyone intended to refactor, but the refactor never happened because there were more important things to build.

The table schema that made sense when the product had one kind of user and doesn't quite make sense now that there are four kinds.

These are not signs of failure. They are signs of a product that survived long enough to outgrow its first assumptions. Most products don't.

The question of consciousness

The difference between good technical debt and bad technical debt is not the debt itself. It is whether the decision was made consciously.

Conscious debt looks like this: we know this is not the right structure long-term. We are building it this way because speed matters now and we will have the information to do it right in six months. We are noting this. We are scheduling the work.

Unconscious debt looks like this: we didn't notice. Or we noticed and hoped it would be fine. Or we noticed and didn't want to have the conversation.

The remediation strategy for conscious debt is a project. The remediation strategy for unconscious debt is first an audit, which is slower and more expensive.

What we try to do

We try to make debt visible. When we make a decision that creates future work, we say so. We name the debt. We note it in the codebase — not as a TODO comment that will be ignored, but as a documented architectural decision with a rationale and a revisit date.

This doesn't eliminate debt. It makes it manageable. Debt you can see is debt you can plan for.