Chesterton's Fence

Chesterton's fence is G. K. Chesterton's parable about reform: coming upon a fence across a road, the sensible reply to "I see no use for this, let us clear it away" is "go away and think. When you can come back and tell me that you do see the use of it, I may allow you to destroy it."

Applied to code, it argues against deleting a guard, a workaround, or an odd-looking line simply because its purpose is not evident. Much production code encodes constraints that are invisible from the code itself — a browser quirk, an ordering requirement, an upstream bug. Removing one produces a fault that looks unrelated and reappears months later.

The productive form of the principle is not conservatism but investigation: find the reason, then decide. If the fence turns out to be a real constraint, that is exactly the fact worth recording — see Code Comment, whose useful form answers "what breaks if you rewrite this?".

The principle has a mirror, and both are needed. A fence whose reason has expired should come down; keeping it forever is Technical Debt with a good story. And a fence nobody can explain because nobody wrote it down is why Documentation Rot is a correctness problem, not a tidiness one.