Wisdom and philosophy
Chesterton's fence
Before you remove a rule, a process or a piece of code, find out why someone put it there.
G. K. Chesterton, The Thing (1929), in the chapter "The Drift from Domesticity".
Chesterton imagined a reformer who finds a fence across a road and wants it gone because he sees no use for it. A wiser reformer answers: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think." Once you know why it was built, you may remove it.
Rules and structures are often scar tissue from a problem nobody remembers. The people who built them knew something the newcomer does not. Asking why first is cheap, and it either confirms the fence is useless or saves you from repeating the original accident.
The idea is often stretched into a defence of every existing rule. That is a misreading. Chesterton only asks you to understand before you act. Sometimes the reason is lost, and you have to judge the risk of removing the fence without it. Some fences were built for bad reasons, and those should come down.
Example
Atomic Energy of Canada Limited's Therac-20 radiation therapy machine had independent hardware circuits and mechanical interlocks to stop overdoses. Its successor, the Therac-25, dropped many of them and relied on software instead. Between June 1985 and January 1987 it gave six patients massive radiation overdoses. Nancy Leveson and Clark Turner later reported that a physicist traced fuse failures on the Therac-20 to the same software bug: there, the hardware had quietly shut the machine down.
Where it applies
Before deleting a strange check, retry loop or config flag, run git blame and read the commit and the linked issue. In a team, ask who owns a process and what incident created it before calling it bureaucracy.
Think about it
Which rule or piece of code are you itching to remove, and do you actually know why it exists?
Applied it to something real? Log it.
Test yourselfWhat does Chesterton's fence tell you to do before removing a rule?
Find out why it was put there. Once you understand its purpose, you can decide whether removing it is safe.
Related models
- InversionWork a problem backwards by asking what would guarantee failure, then make sure you avoid it.
- Second-order thinkingKeep asking "and then what?" until you have looked at the consequences of the consequences.
- First principlesBreak a problem down to what you know is true and reason up from there, instead of copying what others have done.
- The Lindy effectFor things that do not wear out, such as ideas, books and technologies, every year they survive raises how long they can be expected to last.
- Unintended consequencesPurposeful actions produce outcomes nobody planned, because the people and systems acted on respond in ways the plan never modelled.