Guy Reams (00:00.622)
This is day 207, the fence in the code. I watched it happen again this morning. A developer opened a code base they inherited, scanned through a few files, and said the words I've 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 and 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 that you did not build. G.K. Chesterson 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's just in the way.
Chesteron said, do not tear it down yet. First, figure out why someone built that fence in the first place. 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 that fence there for a reason. Until you know what that reason was, you are not qualified to remove it. This is Chesteron'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. 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 some edge case that caused a real failure.
The code may be ugly, it may also contain years of accumulated decisions. Some of those decisions might be obsolete, some may still be essential. The danger is treating all complexity as incompetence, when some complexities actually scar tissue from real world use. I've seen teams rewrite systems without understanding what knowledge was embedded in the original. They remove the fence.
Guy Reams (02:25.676)
and they spent months rebuilding it piece by piece as they rediscovered why it was there in the first place. Chesterston'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, 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 is it 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 assumptions. That is the difference between tearing down a fence and understanding what it is safe to take it down.