When the constraint moves, reprice the code

When the constraint moves, reprice the code from zero.

The harder the code was to build, the easier it is to mistake past effort for present value. Sunk cost drives the mistake. Technical debt makes it harder to see because carrying the debt was once rational: the benefit disappears while the maintenance burden endures, yet the old decision still sounds like a defense of the code.

While the constraint holds, the workaround is debt worth carrying

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. Pinned builds, special-case handling, patches that exist only because the thing underneath won't do what's needed yet.

Technical debt is the exact name for it, and the definition matters: extra future cost accepted to get a present capability. The patches buy a running workload now by creating maintenance that a mature platform would avoid. Carrying that trade is a rational investment for exactly as long as both sides of it exist.

The constraint can be moved on purpose

A platform too immature to run a workload cleanly forces the trade in its sharpest form. The workload runs only with a pinned build of the framework underneath and a compatibility patch for each edge the platform hasn't sanded, and it still fails loading two gigabytes into 96 GB of addressable VRAM. Two weeks of that is a defensible price while switching platforms costs more than carrying the workaround, because a workload that mostly runs beats one that doesn't run at all.

The constraint doesn't have to move by itself. Move the workload to a platform with a mature toolchain, and you kill the constraint deliberately. The same service runs there unmodified. No patches, no memory bug. Every patch is worth nothing in that moment, because the only thing any of them ever did was stand in for a gap that no longer exists. The code stayed identical while the constraint under it disappeared, and the code's value went with it.

The benefit can expire while the debt remains

Expired code is what's left. Debt has a present capability to point at. Expired code has only the story of what it cost, and that story does all the arguing: the weeks it took, the fight it survived. A workaround that took an afternoon gets deleted the day it stops earning. One that took two weeks survives review after review, and the difference between them is nothing the code does.

Dependents prove use and entanglement at once

Dependents don't settle the valuation either. The count can't tell you whether the code still earns its place or is just expensive to tear out. More dependents raise the switching cost and widen the blast radius whether the code is earning its place or holding the shape of a problem that no longer exists. Infrastructure with a hundred dependents can hide severe debt in its implementation, and a workaround with none can be the most rational investment in the system. The count feeds the decision without settling it.

The test is whether you'd build it again

Almost any code disappears if you delete the requirement behind it, so the counterfactual has to be sharper than asking whether anything would miss it. Two questions do the repricing. What current constraint still requires this code? And if the same problem arrived today, would this get built again?

A protocol you still have to speak answers the first question for as long as the obligation holds. The implementation can fail the second question and be due for replacement, but the constraint behind it is still alive, so the code hasn't expired.

Code that fails both questions has, and everything spent on it is a receipt, not a reason.