The British Writer and Catholic apologist G. K. Chesterton is, perhaps, most well known to programmers through a paragraph in which he introduces what is now known as “Chesterton’s fence”. It’s a very simple idea: You walk through a field and see a fence which, seemingly, has no purpose. Instead of tearing it down because it seemingly has no use, try to understand or ask why somebody put it there. ¹ That’s it!

Paraphrasing: if you think somebody built something bad or in a bad way, try to understand why they did it that way before undoing their work. Being burned while ignoring Chesterton’s fence is a rite of passage for every programmer: you see a piece of code and think “who the hell wrote this”. Then, when rewriting it, you break production, and realize that there was a good reason somebody did the things they did. They weren’t stupid after all. Or, you rewrite it and it’s actually better, and you now know more about the person who wrote it, and maybe can teach them how to build better together.

Chesterton’s fence urges us to slow down, and retrace the thinking steps of the person who built before you, thus putting you in their shoes. Keeping Chesterton’s fence in mind does not only make you a better engineer, but it also makes you empathize more with the people around you, the ones that came before you. It shows you the limits of your own knowledge, but simultaneously shows you what you can teach others around you.

Chesterton’s gap

So having said that, I think there’s an interesting new dynamic at play in software land, which I will call Chesterton’s gap. It’s like Chesterton’s fence, except that people walk through the field and ask themselves why somebody hasn’t built a fence there yet, and then, without asking, build a fence.

To me, this is what it feels like to build open source libraries. The cost of creating lines of code has dropped to ~0, which causes people ² to submit 10k line PRs without even opening an issue first. The thing is, these PRs make sense. They are not bad! They’re just not necessary. They add features to projects that nobody asked for, add tools that are marginally useful, add configuration scaffolding for IDEs that barely anyone uses. ³ To return to the parable: the fences are well built, they are sturdy, they may even serve a purpose. But I don’t need a fence in that specific location, even if it is free. I just don’t need it, and I don’t want it.

I can also write lines of code for free. I have the same superpowers you do, so if I didn’t add some feature to a project I own, there’s probably a good reason I didn’t add that specific feature. If you’re wondering why I didn’t add it myself, just ask. Don’t build the fence.

Footnotes