Chesterton's fence, for business rules
Don't remove a rule until you know why it was put there. A century-old principle, and why it is so hard to follow in software.
In 1929, G. K. Chesterton described a reformer who finds a fence across a road and says, “I don’t see the use of this; let us clear it away.” The wiser reformer answers: if you don’t see the use of it, I certainly won’t let you clear it away. Go and find out why it was put there. Then you may come back and tell me to take it down.
Engineers quote this often, especially about legacy code. It is good advice. It is also very hard to follow.
Why it is hard
To follow Chesterton’s rule you need to find out why the fence is there. In a company, that usually means:
- Searching commit history that says “fix” or “update limit”.
- Searching a ticket system that was migrated twice.
- Asking around until someone says “I think it was Priya, but she left”.
Each step costs time, and the answer is often “nobody knows”. So people either leave every fence standing forever, which is how systems fill with rules nobody can explain, or they take fences down on instinct, which is how incidents happen.
Making the rule cheap to follow
Chesterton’s principle only works if finding out why is cheap. That means the reason has to be recorded when it is known, by the person who knows it, and kept next to the fence.
- Every rule has an owner.
- Every owner has been asked why, in a specific question, while they still remember.
- Every answer is stored with the rule, with a date, and re-checked when the rule changes.
What leaders can do now
Pick one area that changes often: refunds, pricing, credit, payouts. Ask your team to list the ten rules in it that matter most, and for each, who could explain it today. The gaps you find are the fences nobody can justify, and nobody can safely remove.