Chesterton's fence

“Know why that fence is there before you tear it down.”

Most systems have a reason for why they are the way they are. Sometimes you can ignore it, but usually not.

Software is written in a context. Rarely can you just change the code without understanding it.

My favorite personal experience about this is when I “fixed” a bottleneck in a job queue system only for enqueue several orders of magnitude more work. Someone else had been using the queueing system as a throttling mechanism to limit downstream system load. They thought it was clever, and so they left it.

Is that bad design? Sure.

But should I have checked why that fence was there? Ayup.

In practice:

This one is relatively simple to understand. Don’t just delete stuff without understanding what it’s doing.

Sometimes code does indeed do nothing. There are in fact tools to help you discover this. I’m thinking of unreachable code.

Sometimes, though, you need human reviewers to help you understand the code. So another practical tip is to just make smaller changes in general and to use stacked PRs for any large refactors to make them more understandable to reviewers.

For more details, read:

G. K. Chesterton, The Thing: Why I Am a Catholic, Dodd, Mead and Company, 1929. https://www.chesterton.org/taking-a-fence-down/