On June 22, 2026, Martin Tournoij (arp242) published a short piece with a title that changes the classic principle by a single letter — Fence becomes Finger. Behind this wordplay lies a real software engineering disaster scene. He was hired to take over a 13-year-old codebase. Everyone who came before him was gone. The git log contained 295 commit lines total; after removing dependabot auto-commits and “fix typo” entries, only 167 remained — averaging one per month. No design documents. Almost no comments in the code. Leftover traces of unfinished refactoring, carcasses of deleted features, and features that were written but never referenced by any page.
Tournoij calls this Chesterton’s Middle Finger. “Yes, we did all these weird things, and we’re not going to tell anyone why. Ha ha, fuck you.”
Chesterton’s Fence originates from G.K. Chesterton’s 1929 book The Thing. The parable is simple: a reformer sees a fence standing across a road, thinks it’s useless, and wants to tear it down. Chesterton says: don’t be so hasty — first understand why it was built. Maybe the reason isn’t apparent to you yet, but it existed once. This principle has been repeatedly cited in software engineering because it precisely hits a common accident scenario: someone deletes “seemingly useless” code, and months later production goes down because that code handled a boundary condition that only triggered once every three years. Nobody knew why it was there because the person who wrote it left two years ago.
arp242 changing Fence to Finger isn’t just a pun. The codebase Tournoij inherited wasn’t bad because the code was poor — bad code is everywhere. The problem was that nobody left any record of “why.” Thirteen years of accumulated decisions — all the trade-offs, all the historical constraints, all the hard-won lessons — completely evaporated. The person taking over wasn’t “climbing over a wall” — a wall at least has visible physical presence, implying “someone once made a decision here.” He faced a complete information vacuum. That’s far worse than a wall. A wall is a silent reminder. A middle finger is silent mockery.
This distinction gets at the core value of code comments. Code itself already says what was done — as long as the language isn’t intentionally obfuscated, the logic is readable. But code can never say why option A was chosen over option B. That bizarre workaround was because a specific library version had a bug. That seemingly redundant null check was because of a P0 incident one Friday afternoon in 2019. That weird sorting logic was because the downstream system had a hard ordering dependency that was itself a historical mistake. If this information isn’t in comments or commit messages, it’s gone forever. Tournoij’s point is straightforward — writing this down isn’t optional extra work, it is part of development work itself. It’s okay to write poorly. It’s okay if your English isn’t great. It’s okay to forget some details. But at least have something. Nothing at all is a middle finger to everyone who comes after.
In the Lobsters discussion, ChrisDenton (18 votes) pushed the topic to the organizational level. He pointed out a more insidious dilemma: sometimes at the time, nobody knows what information will become important later. If the discussions around a decision aren’t recorded — whether in email, chat logs, or issues — later “digital archaeology” is nearly impossible. And when an organization treats developers as interchangeable parts, this vulnerability is amplified to the extreme. Nobody stays long enough. Nobody accumulates an intuitive understanding of the whole system. The same mistakes are made repeatedly. Reinventing wheels becomes the norm. ChrisDenton’s wording was restrained, but the conclusion is sharp: organizations that treat developers as interchangeable parts are the most fragile organizations.
david_chisnall (8 votes) added a further point from a code review perspective. He said the greatest value of code review is forcing you to add comments for non-obvious decisions — finding bugs is a side effect. The real value is “a second person forces you to annotate non-obvious decisions.” He writes comments for things he finds non-obvious. Reviewers ask about things they find non-obvious. After two rounds, the comments cover what two different people each thought needed explanation. When someone later reads that code, the probability of understanding is no longer zero. The cleverness of this mechanism is that it doesn’t rely on the author’s self-discipline — it embeds knowledge preservation into a mandatory workflow.
But should every fence be kept? There is a counterargument. Steph Tulkens wrote “Chesterton’s Gap” — build the fence first, ask questions later. Excessive conservatism is also harmful: every team has that legacy code nobody dares touch, whose surrounding logic has changed three times over, whose original problem may no longer exist — but it stays because “nobody knows why it was written.” Technical debt isn’t just accumulated by writing bad code; not daring to change code also accumulates technical debt. When to tear down the fence and when to leave it — there’s no algorithm that can automatically decide. Judgment comes only from deep enough understanding of the system — which circles back to ChrisDenton’s point: organizations that treat developers as replaceable parts can’t even cultivate this kind of judgment.
Here is a simplified decision framework, presented as a checklist of questions:
| Dimension | Tend to Keep | Tend to Remove |
|---|---|---|
| Context availability | Original team all gone, no docs, no comments | Original decision-makers still around, can ask directly |
| Impact scope | Involves core business path, errors are costly | Isolated module, full test coverage |
| Code intent clarity | Comments explain “why,” logic is coherent | Comments only say “what” and disagree with behavior |
| Trigger frequency | Handles low-frequency but high-impact edge cases | Code proven to never execute |
| Replacement cost | Rewriting requires rediscovering all edge cases | Clear specification exists to guide rewrite |
This table doesn’t solve anything. It’s just a reminder: judging whether to tear down the fence requires more information than tearing it down.
Tournoij’s article got 82 votes on Lobsters, not because it said anything new. Chesterton’s Fence has been discussed in software engineering circles for over a decade. The resonance came from the emotion he named — writing bad code isn’t necessarily malicious, but leaving without a single explanation is contempt for everyone who follows. Every developer who’s been woken up at 3 AM by “that incomprehensible legacy code” recognizes that middle finger. Fixing it doesn’t require more process. It requires treating commit messages as part of the deliverable. Those 167 lines over 13 years — that number itself is the most effective argument.