I watched it happen again this morning. A developer opened a codebase they inherited, scanned through a few files, and said the words I have heard too many times: “We should just start over.”
They had not asked why the code looked the way it did. They had not traced the decisions that led to the current structure. They just saw something unfamiliar and assumed it was wrong. This is a pattern I see everywhere, not just in software. The instinct to tear down what we did not build runs deep. But there is a principle that pushes back against that instinct, and it is worth understanding.
The Fence You Did Not Build
G.K. Chesterton offered a simple thought experiment. You are walking down a road and you find a fence blocking the path. You do not know why it is there. Your first impulse might be to remove it. After all, it is in the way.
Chesterton said: Do not tear it down yet. First, figure out why someone built it.
The fence might be pointless. It might be outdated. But your ignorance of its purpose is not proof that it has no purpose. Someone put it there for a reason. Until you know what that reason was, you are not qualified to remove it.
This is Chesterton’s Fence. It is not a rule that says everything old is good. It is a rule that says you should understand something before you destroy it.
The Code You Did Not Write
In software, this shows up constantly. A new developer joins a project, sees a workaround that looks clunky, and thinks it should be removed. But that workaround might exist because of a customer requirement, a production bug, a third party integration, a legal constraint, a performance issue, or an edge case that caused a real failure.
The code may be ugly. It may also contain years of accumulated decisions. Some of those decisions are obsolete. Some are still essential. The danger is treating all complexity as incompetence, when some complexity is actually scar tissue from real-world use.
I have seen teams rewrite systems without understanding what knowledge was embedded in the original. They removed the fence, and then they spent months rebuilding it piece by piece as they rediscovered why it was there in the first place.
The Right to Change
Chesterton’s Fence does not mean you keep everything. It means you earn the right to change something by understanding it first. You do not have to agree with every decision that came before you. You just have to know what those decisions were and why they were made.
This is a warning against premature simplification. It tells us not to confuse “I do not understand why this exists” with “this should not exist.”
“Your ignorance of its purpose is not proof that it has no purpose.”
The next time you see something that looks wrong, stop. Ask why it is there. Talk to the people who built it. Read the commit history. Trace the decisions. You might still decide to remove it. But you will do it with knowledge instead of assumption. That is the difference between tearing down a fence and understanding when it is safe to take it down.
