Chesterton's Fence - Don't Tear Down the Fence

There is a principle in philosophy called Chesterton’s Fence: don’t remove a fence until you understand why it was built. The person who sees a fence and tears it down without asking why isn’t being efficient. They’re being dangerous.

Software has fences everywhere. Every senior developer has seen them. Most want to remove them. And most do — during a rewrite.

In 2012, Knight Capital deployed a rewrite of their trading system. They deleted what the old code knew. In 45 minutes they lost $440 million.

The fence had been there for a reason.

This talk is about what lives inside legacy code that no architecture diagram, no requirement document, and no sprint planning session captures: the system’s memory of its own failures. Every unfixed bug that’s been there for three years. Every test nobody can explain. Every module that breaks whenever someone touches it. These aren’t signs of technical debt. They’re a risk register nobody wrote down.

A developer reads legacy code to understand what it does. Reading it to understand what it was once afraid of is a different skill — and it’s the skill that makes the difference between a rewrite that ships and one that recreates every production incident the old system had already learned from.

Legacy code is not bad code. It is survived code. The scars are information. The question is whether you read them before you cut.

We go through three concrete techniques for extracting what a legacy system knows before you change it: 1. Oldest unfixed bugs. 2. Modules that break together. 3. Tests nobody can explain. Each extracts knowledge the rewrite will otherwise delete.