{"slug": "chesterton-s-half-implemented-fence-that-he-built-just-in-case", "title": "Chesterton's half-implemented fence that he built just in case", "summary": "A software engineer argues that developers should apply Chesterton's fence when refactoring unfamiliar code, understanding why code was written before removing it. The engineer recommends documenting intent through READMEs, Notion docs, pull request descriptions, tests, and public Slack channels so future maintainers have the context behind each decision.", "body_md": "There's a fun part of starting every new software engineering job as you navigate an unfamiliar codebase:\n\nYou want to make some changes, maybe refactor some old code, and you see some things that strike you as odd.\n\nYou ask yourself, \"Was it done this way for a specific reason, and I'm just missing something that I don't understand yet? Or was this just always broken or not well thought out to begin with?\"\n\nYou scour the codebase for any READMEs, look at past pull requests and commit messages, and hunt for any wikis you can find. It wasn't documented.\n\nYou ask the engineers who you think might have some context, but they're not sure why it was written that way either.\n\nYou ask Claude for more info, but it feels like it's grasping at straws as well, and you're not quite sure how trustworthy any answers you get are at this point.\n\nSo you make your changes, test as best you can, merge the pull request, and hope that nothing blows up.\n\nBest-case scenario: Everything's fine.\n\nWorst-case scenario: That was a load-bearing console log you just removed, and you've taken down production.\n\nThere is a parable by G. K. Chesterton, an English philosopher and theologian. It goes like this:\n\nIn the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, \"I don't see the use of this; let us clear it away.\" To which the more intelligent type of reformer will do well to answer: \"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.\n\nApplied to most scenarios, the lesson is that you need to understand why the thing was there in the first place before you get rid of it.\n\nRecurring meeting you don't like? Figure out why the meeting was created to begin with. If it's no longer serving its stated purpose, great, remove it.\n\nProcess you don't agree with? Understand why the process was originally instituted. Maybe it was to solve an organizational problem or to clarify something people were frequently confused about.\n\nCode you don't understand? Maybe there were technological constraints or business requirements influencing the decisions made.\n\nThe point is: before you go about changing things, make sure you understand the historical context and any nuance that may not be immediately obvious to you at first glance.\n\nAs a software engineer refactoring code, be aware of Chesterton's fence. Do your due diligence to understand why the code was written the way it was.\n\nAnd as code authors, make sure you leave the breadcrumbs behind for your future coworkers, maybe even for your future selves. Make sure to explain the purpose of the fence when you build it. In the present moment, you have more context than anyone else will ever have.\n\nCreate that README file. Write the Notion doc. Include context in your pull request descriptions (explain *why*, not just *what* — bonus points for including screenshots or videos!). Write tests to verify behavior and prevent regressions. Use public Slack channels rather than DMs.\n\nYour future self will thank you. Because there's nothing more frustrating than trying to figure out if Chesterton's fence was ever even working to begin with.", "url": "https://wpnews.pro/news/chesterton-s-half-implemented-fence-that-he-built-just-in-case", "canonical_source": "https://dev.to/thawkin3/chestertons-half-implemented-fence-that-he-built-just-in-case-5ape", "published_at": "2026-09-14 15:00:00+00:00", "updated_at": "2026-09-14 15:17:23.778172+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Chesterton", "Claude", "Slack", "Notion"], "alternates": {"html": "https://wpnews.pro/news/chesterton-s-half-implemented-fence-that-he-built-just-in-case", "markdown": "https://wpnews.pro/news/chesterton-s-half-implemented-fence-that-he-built-just-in-case.md", "text": "https://wpnews.pro/news/chesterton-s-half-implemented-fence-that-he-built-just-in-case.txt", "jsonld": "https://wpnews.pro/news/chesterton-s-half-implemented-fence-that-he-built-just-in-case.jsonld"}}