Pressure code is the debt you don't want to remove

Refactoring pressure code makes it harder to remove.

Pressure code is code built around a constraint: a tool that almost fits, an ecosystem still settling, a deadline with no slack. It mirrors the constraint's shape. Custom builds, special-case handling, patches that exist only because of this constraint.

Each refactoring pass adds tests, documentation, an interface wrapped around the workaround. The barrier to removing it grows, even though the interface still leaks the workaround's shape to everything downstream. The constraint underneath hasn't moved.

Pressure code creates value while the constraint exists: teams ship against it, systems run, contracts hold. When the constraint moves (a tool matures, an ecosystem ships the missing feature, a deadline passes), the workaround structure is what's left. Its forward value drops to zero. The carrying cost remains.

Infrastructure code is the opposite. It exists so other code can work. The cost amortizes across dependents. Take it away and the foundation goes with it.

The two look identical as code, and feel identical to the engineer who wrote them. The diagnostic resolves them at the moment of removal, by where the resistance points.

The diagnostic is what would resist the removal

If the resistance points at the effort of building it (the weeks of patches, the special-case handling, the work it took to ship), set it aside. That's sunk cost, and it says nothing about whether to keep the code.

What's left is what a simpler replacement would face. If it would still have to carry the function forward (the callers, the contracts the code satisfies), that part is investment. If it would shed a workaround shape that dependents coupled to, that part is debt. The same code can hold both.

Reluctance shows up in every case. The diagnostic is what the reluctance points at: sunk work, live function, or workaround shape.

Dependents prove demand for the function, not the workaround

Pressure code can accumulate dependents because the workaround was the only path forward. The dependents look like proof of investment in the workaround. They prove something narrower: demand for the function the workaround happens to host.

The function is real demand that any replacement has to carry forward. The debt is the workaround's implementation shape and the coupling that dependents grew around it. More dependents raise the cost of acting on the classification. The classification itself holds.

The diagnostic doesn't need the original author

The classification doesn't need the original author. Code outlives the people who wrote it. The same question resolves it for inherited code, code with rotated owners, code where nobody remembers why it exists: what would resist removing it. Past effort doesn't come back, no matter whose it was. What matters is the demand on the function the code hosts.

Reluctance is one signal: useful, but not the audit. The audit runs on the dependency graph. Every function has demand, so demand can't be the test. The test is whether a replacement carrying the same function to the same callers would force those dependents to migrate. If it would, the shape is debt.

Foundational functions can have debt implementations

Some constraints don't move on a useful timescale: a protocol specification, a hardware interface, a backward-compatibility commitment. Something has to translate between the system and the constraint. That translating function is real demand.

The implementation that does the translating can be infrastructure or debt. The difference is what a replacement has to do. A clean implementation exposes the function through a stable interface, so a replacement reimplements that interface and dependents coupled to what it specifies don't have to migrate. Dependents that grew to rely on its incidental timing or error quirks still might. A workaround-shaped implementation couples dependents to its peculiar shape, so a replacement has to carry the function forward and migrate the dependents off the shape.

The function is real demand in both cases. The workaround shape is the debt.

When a cleaner implementation appears, the workaround-shaped one becomes the kind of debt the diagnostic catches. When nothing simpler appears, the workaround stays debt. Its shape costs more than the function requires, and nothing exists yet to shed the excess.

The resistance is the audit

The resistance to removing pressure code separates into three things. Past effort sunk into the workaround is irrelevant to the decision. The function the code hosts is real demand: any replacement has to carry it forward. The workaround shape the dependents got coupled to is debt: shedding it is the migration cost.

That sets the replacement's job: deliver the same function to the same callers, without the workaround shape. Past effort doesn't enter into it.

Refactoring the workaround in the meantime makes the eventual replacement harder.

The classification doesn't require a replacement to exist. The replacement may never arrive. The audit still draws the line.