Chesterton's Fence
Don't remove a fence until you know why it was put up.
“If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think.”
To an executive
Old rules and processes often exist for a reason nobody remembers. Removing them unexamined can bring back problems the organisation already paid to solve.
To an engineer
Before deleting odd code, a retry loop or a validation rule, find out why it exists. Use history, tests and the people who remember, then remove it deliberately.
The idea
In The Thing (1929), in the chapter "The Drift from Domesticity", G. K. Chesterton imagined a fence or gate across a road. A reformer says he does not see the use of it and wants it cleared away. The wiser reformer answers that if you do not see the use of it, you certainly may not clear it away. "Go away and think," Chesterton wrote; come back when you can say why it is there, and then it may be removed.
Legacy systems are full of fences: odd retry loops, nightly batch jobs, strange validation rules, a delay nobody can explain. Many encode forgotten business rules or hard-won fixes for past incidents.
Why it works
Things are rarely built for no reason. Someone spent effort on the fence. The reason may be obsolete, but it is usually findable, and finding it is cheaper than rediscovering it in production.
Knowledge leaves faster than code. The people who added a workaround move on; the workaround stays. The fence is often the only remaining record of a problem.
It separates cleaning up from breaking. Once you know why something exists, you can remove it safely, replace it with something better or keep it with a comment explaining why.
Where it applies
- Decommissioning and simplification, before switching anything off.
- Migrations, where the new system may not reproduce behaviour nobody documented.
- Refactoring legacy code, especially odd conditionals, delays and duplicated checks.
- Process and governance clean-ups, where an approval step may exist because of a past failure.
How to apply
- Research the history: commit messages, tickets, incident reports, ADRs and the people who were there.
- Observe what it actually does in production with logging, tracing or traffic analysis.
- Test removal safely where history runs out: switch it off in a lower environment, behind a flag or for a small share of traffic.
- Record what you learned, whether you keep the fence or remove it, so the next person does not have to ask again.
Example scenario
A team cleaning up a settlement job found a 30-second wait before one step and removed it as pointless. The wait existed so a partner bank's batch file could finish arriving. Without it, the job sometimes read a half-written file and processed some payments twice, and it took two days to notice.
After restoring the wait, the team replaced it with an explicit check for the partner's completion marker and wrote a short ADR. They also added a rule to their clean-up checklist: before removing any unexplained delay, retry or check, look in the history and ask its last committer.
Questions to ask
- Why was this built this way, and what problem was it solving at the time?
- What breaks if we remove it, and how can we find out safely?
- Who remembers the history, and where is it written down?
When not to use it
- Clearly harmful things, such as a known security hole; fix it now and investigate its history afterwards.
- Cheap, safely reversible removals, where switching it off under observation is the quickest way to learn why it was there.
How it misleads you
It can become a reason never to change anything, because a reason might exist somewhere. Investigate in proportion to the risk, then act. Also beware of finding a reason and assuming it still holds: the original problem may have been solved elsewhere long ago.
Further reading
Last reviewed · Suggest an improvement