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, and a clean interface. The barrier to removing it grows. 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 time of removal by identifying the points of resistance.

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), the code is debt. The resistance is about the work, not the function.

If the resistance points at what would still need to exist under a simpler replacement (services downstream, callers upstream, contracts the code satisfies), the code is an investment. The resistance is about the function, not the work.

Reluctance shows up either way. The diagnostic is the question it answers.

Dependents prove demand for the function, not the workaround

the

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

The function is a real demand that any replacement must meet. The debt is the workaround's implementation shape and the coupling that grew around it. More dependents don't change the classification; only the cost of acting on it does.

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, and code where nobody remembers why it exists: what would resist removal? 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 is the dependency graph. Without this workaround, would the function still have demand?

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 can reimplement that interface, and no dependent code has to migrate. 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 in 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 the 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. It separates real demand from debt: the function to preserve in any replacement, and the workaround shape to stop polishing. The replacement may never arrive. The audit still draws the line.