Chesterton’s Fence (2020) | Hacker News Reader

Chesterton’s Fence (2020)

fs.blog

158 pointshasheddan142 comments

I'd argue that incremental change strikes the balance between tearing something down and being paralysed by potential consequences. Also, you can only learn so much by passive observation. Eventually you have to apply a small stimulus (incremental change) and observe the response. If the response is bad reverse the increment.

Caveat is that if you reach a local maxima a more drastic change may be required, but the journey to the local maxima has probably taught you enough about the system that you can safely make the bigger jump.

>Eventually you have to apply a small stimulus (incremental change) and observe the response.

In any sufficiently complex system this is probably true. Often there's a reason for some thing being there, and that reason is often enough a workaround for an issue in an external library. Then the library gets updated, but the workaround remains.

I've observed this often enough. I try to add a comment whenever I do this linking to the issue on the external repo if possible, so that later on you can check if it's still needed.

But this is not fool proof and not everyone will leave breadcrumbs. The breadcrumbs might also be eaten in the meantime by some merges and refactorings.

In the end you're often left with a useless workaround, the person that made it is not in the company anymore, and there's nothing to observe for why it's necessary.

If you don't want your system to eventually collapse under its own weight, sometimes you have to go for a risky refactoring. Doing it incrementally mitigates the risk.

Chesterton's Fence doesn't tell us _not to change things_ or even prescribe some level of _incrementalism_ it just asks us to make a good-faith effort to _know_ why the thing we want to change is the way it is before we change it.

To follow the metaphor, maybe the reason the fence is there is because the county water supply is behind the fence and they put it there to stop cows and livestock from fouling the water.

Often enough there is just no reason at all for the fence, or the reason is completely lost. So knowing why it's there is impossible, and if you condition taking down the fence on that, you are effectively prohibiting taking the fence down.

That's why every time somebody argues against it. It's because at some point you have to abandon that rule, and all the interesting discussion is about when to abandon it, not on how to follow it.

Right, which is why like the comment you're replying to said, you make a good faith effort (i.e. not just as a formality), and then dismantle that fence if reasons why are lost in the mists of time and bureaucracy.

Think about what "good-faith effort" means.

This is another thing the Fence metaphor helps us understand when we think about it a little bit more.

I think the point of the fence is to move the impulse from yourself (If I can't see the reason there must not be one) to the greater context (Someone had a reason for this at some point, let me see if I can try to understand).

Related to Chesterton's fence is Levi's Onion:

https://www.joeydevilla.com/2001/12/03/4419/

Which is sort of a Chesterton's fence situation where someone took those required steps.

Thank you! I collect these kind of metaphors and I didn't have Levi's Onion. I just added it to my list. I had a similar one called "chicken chopping" that I heard from an Australian once, but I like this one better.

If you posted your collection on Pastebin I'd be forever in your debt!

I had to fill some of these in, but here you go: https://pastebin.com/ukGdAWbW

I have my own collection of these and would also like to see a pastebin of yours!

https://pastebin.com/ukGdAWbW Share yours, please!

A bit disorganized and apparently pastebin thinks there is something so offensive in here they won't let me share it but here you go, a collection aphorisms and various other adjacent things

https://controlc.com/db66d6e4

That's amazing! Thank you so much! I've always had a little back-burner dream of making a little blog that does like one of these allegories per week.

It is also very easy to fall into the trap of assuming you know why it was put there, only because you found out one reason.

Being aware of this, it is easy to assume that, no matter how many reasons you can think of as to why something was done, there might very well be other reasons you don't know, at that point, it seems to me, the options are either accepting the risk or never changing anything.

>Often enough there is just no reason at all for the fence

The article makes the point that people do not build fences for no reason. It costs time, effort and resources, not to mention it's a lot of work and people are lazy. There's always a reason for the fence.

>or the reason is completely lost.

This may be true. A fence in the middle of a wood may have been put there 90 years ago because of old property demarcations, or an effort to keep the dread bearded grindlesnatch from attacking the village. The property is now owned by one person, and climate change killed the bearded grindlesnatch, so the fence isn't needed anymore. But the point is to find out why it was there before you tear it down, and if you can't find the reason, you should be extra careful about yanking it down. Perhaps now the fence harbors a mini ecosystem of berry bushes that has increased the potential environment for wild game.

Progressives tend to be very dismissive of the Chesterton's Fence analogy, because they think change is an unalloyed good. There are a lot of social mores or codes that seem unnecessary, outdated or even bad, but they don't want to look at the reasoning behind them. Second order effects are easy to dismiss as speculation, so they usually are dismissed; but any change, radical or otherwise, will have second order effects, so careful thought must go into them.

Why did you need to make this political? It's just a matter of minutes before someone points out that conservatives love the Chesterton's Fence analogy because most fences are built to keep _those people_ out. And then we're off to the races.

Wasn’t the point of Chesterton coming up with this metaphor political? His whole point was that conservatism was, in his view, wise.

I thought that his point was "there's no substitute for understanding why" ?

If every change demands first a detailed study, a logical consequence is fewer things will ever be changed.

>because most fences are built to keep _those people_ out.

A fine example of how the warning of Chesterton's Fence is ignored by inferring the worst possible motive without evidence or reason, and using that unsupported aspersion as a reason to rip something up.

And there you go pulling the quote out of its context, changing its meaning completely. You ignored Chesterton's intentionally to make a point, or MISSED the point by not reading it thoroughly, or something I may have missed. But I'm attempting to understand before changing anything.

Just because you attempted, doesn't mean you succeeded.

I'm suspicious of seductively clever writers like Chesterton. You'll find this quote on his wikipedia page:

> "The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected."

Having read some of his Christian apologetic essays, I suspected the fence argument was fundamentally motivated by religion, and again from the wiki page, it originated in from his book "The Thing: Why I Am a Catholic".

EDIT: GP said "Progressives tend to be very dismissive of the Chesterton's Fence analogy, because they think change is an unalloyed good." to which parent complained "Why did you need to make this political?". I found Chesterton's own words both relevant and sufficient warrant to broaden the discussion along the lines of the GP.

I read "Man Who was Thursday" and some of his other works... He always struck me as more of a "contrarian" than anything else. If he lived in a time when Christianity/Church was gaining popularity I think he would have declared himself a devout atheist. Reminds me of the "true neutral" alignment from the old Dungeons and Dragons rulebooks.

You're right. A conservative is a contrarian. They fight change.

Chesterton's fence is a rational argument in favor of being conservative.

I don't completely agree. A contrarian, by definition, is responsive to the political context they are in. In Chesterton's time, there was a wave of anarchism finding purchase in academic and philosophical circles: hence he appeared as a conservative.

A "conservative" from Chesterton's time doesn't necessarily map cleanly onto the modern notion of the same name... Supposing the allegorical "fence" to be something like clean air or water regulation, one could argue that it's modern "conservatives" more often than not arguing to disturb things without considering second-order effects.

I realize it's probably too late to respond, but I don't completely disagree.

I really don't like referring to Republican's as conservative or Democrats as liberal precisely because neither party really sticks to those concepts. "Conservatives" as a political unit are not conservative and "Liberals" aren't liberal.

The world is a dumb place.

First, I see that quote as mocking both sides, it seems more like Chesterton was trying to be an enlightened centrist. To boil it down, his quote is basically "Progressives make new mistakes, conservatives keep repeating old mistakes".

And I always felt Chesterton's fence to be advice to be deliberate in your actions. Spending the time and effort to find out why the fence exists, doesn't mean it won't get torn down. It just means that we won't be taking it down spontaneously.

> The article makes the point that people do not build fences for no reason. It costs time, effort and resources, not to mention it's a lot of work and people are lazy. There's always a reason for the fence.

Since this is HN, I think a lot of us have experience with software. If you do, then I find it incredible that you have never discovered some complicated code that serves no real purpose, or at least no good one, and was presumably written to amuse the author more than anything else.

>If you do, then I find it incredible that you have never discovered some complicated code that serves no real purpose

Hell, I've written some of that. Very complicated, usually awful code, but it did at one point have a purpose.

If somebody wrote something complicated, just for amusement, then that is its purpose. That's a fence that can be rebuilt or thrown away, but you'd better be sure that nothing else references it or otherwise depends on it doing its quirky baroque thing.

But the whole point of Chesterton's Fence is that you don't immediately assume it has no purpose, you put a bit of effort into double checking. If you checked and you're confident it's useless and you can explain why to a reviewer, then sure, remove it.

Edit to add: thinking about it, I don't think I've ever found code in a legacy codebase that had literally no purpose. The closest might be code that was once used but now isn't referenced anywhere.

I see code without purpose all the time. I have some colleagues who seem to believe that they should assign `null` to class fields when disposing an object. And no, the object will not be recycled, and never was.

> or at least no good one

Understanding whether the purpose was good implies understanding the purpose. Even with very bad code you can at least see what the author was going for. Most code I've seen and felt was bad could be described as "Author needed to do X but wasn't aware of Y." I can't remember a time where I had to deal with code where I couldn't figure out what X was.

It becomes pretty apparent to me, often, that the author wanted to put something on their resume, or wished to spice up a boring task.

You keep saying this is your lived experience, and a lot of other people are saying that it is too rare to be worth making a presumption without putting in the work to go look.

What I’ll say to you now is that if you are actually looking for the reasons, and all you can find are people making your life hard for the glorification of their ego, you have a much bigger problem than whether it’s worth presuming that there is no reason for code you want to remove:

You are located in a local pessimum. Consider working on a different code base. Ask yourself what is going on that you keep running into all this code written by people you disrespect so much.

It happens to me infrequently now and I work with a team I really respect. But it took me the better part of a decade to land there.

Our experiences and outlook may differ, but I am very gratified to hear that you have found your way to a better place.

Joel Spolsky, just about 22 years ago:

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Yes, it may be the case that we no longer support Internet Explorer, and none of our customers even know that Windows 95 ever existed, much less run it. And our users look at a floopy disk and exclaim "Cool, a 3D-printed save icon!"

So yes, lots of code serves "no good purpose" today, even if it was a good purpose when it was written. HARD AGREE.

Presumably written to amuse the author? Hard disagree from my n=1 experience, even if that experience with commercial software development dates back to the early 1980s. I think those cases are outliers that exist, but shouldn't drive our decision-making. The key word is "presumably." Presuming that code we find doesn't seem to serve a purpose was written for the self-gratification of the author is, in my experience, a very bad way to manage risk.

I'm prepared to assume that code which doesn't seem to serve a purpose may no longer serve a purpose, but while it may never have served a purpose, I'll try my best to find out what that purpose was before throwing it away.

I could maybe buy that if the code was very old. When it’s a couple months old I find it hard to swallow.

If the code is only a couple of months old, why presume anything when the original authors are probably still around? When the pull requests are right there to look at? When the JIRA tickets either completely explain, or link to documents that explain the acceptance criteria for the code? When a quick search can pull up slack conversations about the code?

Going back to the metaphor, if the fence you want to pull down is only a couple of months old, the knowledge of why it was put up in the first place is readily available. Just ask around.

Sometimes they’re not around anymore regardless. Sometimes I’ll ask and become more secure in my conviction that it is an exercise in self gratification. From these experiences I can extrapolate to the general case and say “there’s always a sensible reason” is hogwash.

I like Joel Spolsky's take on software rewrites. He never mentions Chesterton but he's thinking along the same lines - old code is a collection of fixes to problems that real people had. You throw it out at your peril.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

> The article makes the point that people do not build fences for no reason.

I think it’s more than sometimes reasons go away and sometimes people do unreasonable things. I don’t think anyone thinks that people literally build fences completely randomly.

In another thread about JWT there’s a discussion about how the Soviets tried to copy the design of the space shuttle because “the Americans must have had some reason we can’t see yet for that design”. Turns out the design was largely motivated by a secret military operation only relevant to the Americans (which never materialized either apparently).

> The article makes the point that people do not build fences for no reason

Sure. That doesn’t mean that the reasons are good or accessible to you to make that decision. Now when the reason is obviously apparent and widely known, that’s a totally different thing with the caveat being that conditions change and you may not have realized that in a complex system.

The shuttle carried out multiple classified military missions, although fewer than planned. It had capabilities unique to its design. The difference is that the Soviets didn't have the economic base to support such an inefficient design.

And yet the Russians, in this case, would have been better served ignoring the Chesterton fence.

It's a neat analogy but it has limited utility as a general rule for either side.

yes, I have a lot of respect for soyuz.

Chesterton's Fence does not say you should build a fence 100 feet from your house because your neighbor has a fence 100 feet from their house.

I think you're mixing up Chesterton's fence with cargo culting.

Chesterton's fence is about attempting understanding. If the Russians were blindly copying the space shuttle design, how is that attempting understanding?

Chesterton’s fence is about keeping the status quo unless you have a deeper understanding. From my perspective, copying an existing design of your competitor is the status quo. Innovating would be tearing down the fence.

> There's always a reason for the fence.

Yes: To get the rocks out of the dirt so we can farm there.

https://www.loe.org/shows/segments.html?programID=18-P13-000...

https://www.atlasobscura.com/articles/new-england-stone-wall...

Now, of course, New England with its rocky soil is no longer an agricultural powerhouse, so maintaining a stone wall in the middle of re-forested land is rather pointless from the perspective of anything other than an antiquarian interest. The whole world has changed and the walls weren't primarily intended as boundaries anyway.

Pointless unless it now marks lots, or pastures for animals. You've never see a fence or wall to delimit the upper pasture from the lower pasture? Or to mark the area where you leave trees to grow rather than weed them as samplings, thus forming a woodlot for future generations. Stone fences in days gone by were probably very desirable say as cover when fighting the British during the revolution. Original reasons may be obsolete, but it doesn't make future reasons invalid.

> The article makes the point that people do not build fences for no reason.

Naturally everything that ends up happening has a cause and happens for _some_ reason; that's nearly a tautology. But I think the is that there are many things that don't happen for any _good_ reason, many often for bad reasons. And it's also common to find that the reasons for these things aren't discernible. Someone made a mistake decades ago, and now no one wants to correct it because there must have been a reason for it, but we can't figure out what it was.

Years ago I was the member of a local governing board, and there were many people there who thought that because we were part of a bureaucracy, we should act more bureaucratic. The more work we did, the more we required of other people, the longer the meetings, the more trainings for systems we'd never use, the better.

I remember one particular situation where another agency was asking our input about an application in our jurisdiction, and the chair told me to tell the applicant about all the extra paperwork they would need to file with our board. I contacted the agency the application was actually filed with, and they told me they already handled that, and they were only notifying us in the off-chance there were any special considerations in our district the agency needed to be notified of. As far as I could tell, the dozens of boards who oversaw other jurisdictions didn't have our additional requirement either. When I told our chair that the agency wasn't asking us for the additional paperwork, he replied "but that's how we've always handled this." At some point years before somebody on the board wanted to add additional paperwork (and it's questionable whether they actually had the authority to do this), and the rest of the board just mindlessly followed along for years.

The point is, you can't evaluate whether a reason is good or bad (or more likely, out of date) until you know what it was.

> Progressives tend to be very dismissive of the Chesterton's Fence analogy, because they think change is an unalloyed good.

That's a bit of a strawman. One could just as easily argue that reactionaries in the USA don't want to admit why many fences were built.

> Progressives tend to be very dismissive of the Chesterton's Fence analogy

Is this true? Who is leading the charge to distrust longstanding institutions such as universities… or the CDC? Who is trying to hold nature in balance? Even the right to terminate a pregnancy can be seen as a Chesterson’s fence that is looking to be torn down.

The former leader of the “conservative” party was infamous for steamrolling norms.

I’m not a progressive personally, but I think this is an unfair description of them. Too broad a brush.

> So knowing why it's there is impossible, and if you condition taking down the fence on that

The condition is to make an effort, not to necessarily succeed. If you try and can't make sense of it, you have the green light to proceed with caution.

Yes, it can happen that we can't figure out why the fence is there. I think we must pragmatically amend the dictate of Chesterton to be something like: make a reasonable effort to know why the fence is there.

Then we would still notice the difference between two kinds of reformer: those who don't know (and don't care) why an institution is the way it is and those who are reasonably curious about what the institution was for, how it worked, and so on, even as they recognize a need for reform.

If there's one "prescriptive" thing I find useful about the allegory that applies to software, it's thinking about how to write good documentation.

A lot of engineers would write something like "this fence is made of silver oak planks cut to a length of 3 feet and fastened together aluminum wire" and while that may be useful if you have to fix the fence, for the people in the allegory it would be much more helpful to have a sign that says "this fence is here to keep cows from fouling the water in the lake behind it because 5 houses nearby use it for drinking water". If either the 5 houses or the cows are no longer there, it makes the whole system much less resistant to change.

At one time I had the thought that, in coding, one should note assumptions in a searchable and documentable way. Then, others later could audit for assumptions which no longer applied, without needing to go deep into the code.

Another lesson from the story is that you might not be able to figure out the reason for the fence currently, but in springtime when the creek overflows, it might become obvious.

See the problems of historical warnings, markers, and legends, for example.

Japanese seaside communities frequently have markers showing the height or inland range of previous tsunamis. Proscriptions against specific materials, sites, foods, or practices may be based on previous lessons for which available archival mechanisms were insufficient to detail though lore and monuments might serve as warning.

Jared Diamond observes that in New Guinea, natives refuse to sleep beneath certain types of tree, despite what seems a small risk of limb-fall. The occasional recreational camper might get away with spending a few nights out of a lifetime under such a tree or camping on low ground. Small risks repeated sufficiently many times become large, and those living such a lifestyle take precautions.

Similarly: many safety regulations, standards, and precautions are written in blood. Oderised gas is the scented memorial to the 300 souls of the New London School.

Long-term, latent, non-manifest risks are a chief form of technical debt.

I'd counter argue that the need to make executive quick consequential decisions actually does a lot of damage. I understand that is what we value and how we consider our executives to be high functioning strong leaders but I don't believe that gets to the best long term outcomes for the organization.

Obviously paralysis is a different matter - but taking time and consideration to get to the appropriate decision actually is highly productive in the long run - though if you are an executive it might not signal that you are going to be around for a long time due to organization thinking you aren't up to task.

N.B - taking the time to access a decision is always a trade-off.

Agreed; under uncertainly, you should shrink the size of your bet.

For example, I think open borders might be good for the world (maybe outside of pandemics, say), with less than 100% confidence. However, debating completely open borders is sort of pointless. The actual lever we have is how much legal immigration we allow (and possibly how much enforcement we do against illegal immigration). So in practice, the road to open borders would be steady increases in the number of visas we grant (unless things start to go badly), not just tearing down the "fence" all at once.

There is also a different point here:

Even with 100% knowledge¹ that Open Borders is the right policy, implementing it overnight can be a disaster, since institutions, culture, public opinion etc need time to adjust to the new reality.

¹ For the sake of argument. Let's not debate immigration policy.

There are also often (though not always) alternatives to incremental change.

These include pilot projects, modelling, stratified or distributed deployments (different regulations in different districts, rolling out changes to subsets of a userbase, etc.).

There are times when an entire system needs to be modified as a whole. Those are not all instances however.

> Eventually you have to apply a small stimulus (incremental change) and observe the response

I wonder whether if that observation is transferable so that the second-order thinking need not be original if there exists a directory of common decisions & outcomes?

I've been trying to validate[1] whether if we could create a standardization for common decisions and outcomes; Then people could share their recipes of decisions & outcomes to a central directory which can be used to make Second-Order decisions without actually having to make one our self.

[1] https://needgap.com/problems/263-plan-second-order-third-ord...

Here is a very popular in Russian tech joke, in my humble translation.

Why do engineers hate to work with other people's code? Let me try to make an analogy.

You are hired to finish building a scientific lab on a distant island. When you arrive, you see half-finished building, a giant (same size than the building) fan and a hot air balloon. In the basement you found a room full of floor mops - about a thousand of these.

You clean up the mess, finish all the work, the lab starts it's first experiment and then suddenly after only five minutes scientists are starting running around screaming about toxic gas leak. You call your predecessor.

- Buddy, what's up, there's a toxic gas leak, how's that possible?

- I don't know, everything should just work, did you change anything?

- Yes, I put all those floor mops away.

- Why did you do that?! It was meant to support the floor above, where the toxic gas reservoir is! It was too heavy, thus the mops!

- Are you crazy to support the toxic gas reservoir with mops? Why didn't you at least put a sign on the door? What do I do now?

- Turn on the fan, it will blow the gas away.

- Dude, I disassembled the fan first thing, why didn't you put a box of gas masks instead?

- Where do I find gas masks? And the fan was a spare from the other project!

- This is terrible! We all gonna die here!

- Why are you still there? Jump to the balloon and fuck off the damn island!

In a perfect world where you are able to find out the reasons why the fence exists, it is fine to evaluate if the reasons still hold true to keep the fence. In many real instances, we may not be able to find out the original reasons with any reasonable level of certainty.

Under those circumstances, it is best to figure out options in front of us, make a decision and move forward. Doing nothing is also an option, but one cannot be stuck in endless analysis-paralysis and fail to decide.

Does anybody actually think we shouldn't change anything if we can't figure out what the original reason after a good faith effort? That just seems like a straw man that simply isn't what Chesteron's fence is about.

It does happen quite often, especially when groups (n>1) are involved in decision making and the parties don't all agree on the causes or have divergent views or have competing vested interests. eg: UN decision making or Climate change action planning etc.,

When this occurs, they dig in firmly in their positions and either argue for keeping the fence as-is (maintain status quo) or taking it down (action bias).

Except that's a totally different scenario, where the different parties have different interests and thus don't agree on whether to keep the fence, not one where we don't know why the fence exists.

I may be reading your point incorrectly, but you mention no reason FOR a change, except change. I think that is fine on your own property, but wasteful when it comes to property that is public or common. If the change has an associated cost, on public or common property, change is usually passed to those public or common owners, often when they don't want it.

Bureaucrats famously build things just to associate themselves with "getting things done".

I don't understand what your point is. Sure, people of abuse shared property, tragedy of the commons and all. What does that have to do with the fence?

This is one of the reasons that keeping code in a repository (especially a git repo) with good discipline on tying changes to issue descriptions is so key. It won't guarantee you'll find all relevant consequences of a change, but it really gives you a leg-up on the alternative of parsing out the results of a change by examining the code entrails.

Chesterton's Fence is a valid point, but I dislike how the article celebrates it. Doing the archeology required to figure out why things are the way they are is oftentimes much more expensive than building it was in the first place. This leads to terrible situations where it's cheaper to simply build an expressway over the fence rather than tear it down.

This is the stuff technical debt is made of.

Sometimes it's the right decision to risk second-order regressions in order to make forward progress. This of course depends on the circumstances and the costs of regressions.

With technical debt you know why something was done a certain way. It was a deliberate shortcut, done for a reason, to be fixed later (paying off the debt).

Its a process obviously. Sure it is painful to spelunk the first time. But it gets easier over time. And it definitely gets easier if you are able to remove things over time and eliminate all that unneeded code/architecture noise.

This is the stuff technical debt is made of.

True, but also ignoring Chesterton's Fence is what catastrophic rewrites are made of.

If you know why the fence is there and have confidence the reasons no longer apply, you can be bold. If you're not sure because the archeology is expensive, you should take baby steps if possible. (Which I think you get at with the cost of regressions.)

For my team, that's often flipping a feature flag where we don't expect any difference, and watching the output for a while to verify. First sign of surprise, we can quickly flip back. We get surprised more than we would like.

A witty saying proves nothing. -- Voltaire

Just as a general rule in conversation, invoking so-and-so's law or this fence isn't a productive tactic. Instead, ask the question that wisdom suggests you ask, and for this bothersome fence in particular, keep in mind that you are weighing an unidentified consequence against a proposed benefit, and at least endeavor to expend some of your own effort on suggesting what the value of the fence might be or how one might go about finding it. You may find some of that effort has been undertaken and that failure has not been shared.

> invoking so-and-so's law or this fence isn't a productive tactic.

Not true. If we both are familiar with the concept, saying "Consider Chesterson's fence" conveys a lot of information. If we aren't, chasing down the reference will almost always result in a much more articulate version of the concept than whatever you or I would come up with on the fly.

I wonder what kind of collective trauma could be causing the HN community to frontpage articles about Chesterton's fence a few times a year.

Its downstream of the collective trauma experienced by those who as a result insist on changing everything all the time, often with no good reason.

It's not trauma, it's fear of what would happen if there weren't articles on HN about Chesterton's fence a few times a year.

must be the second order effects of said trauma

I expect it's a frequent side-effect of working on large systems with many interdependencies.

Before we stop frontpaging articles about Chesterton's fence, we must first understand why the articles are being frontpaged to begin with.

I like what you did there.

Perhaps it is the trauma of non-consensual changes in software and especially user interfaces that we are forced to deal with regularly?

I think it's cheekier than that. It's a deliberate attempt to watch people miss points, argue, and split hairs over the mildest of mild rules of thumb.

Things get reposted all the time, is there something particularly odious about Chesterton's Fence?

What I tend to notice about this is how easily people seem to fall on both sides of this fence (pun slightly intended). People can be annoyed that a change broke their workflow (why didn't anyone bother to find out if this was in use), while simultaneously pushing to change other things without applying Chesterton's Fence (we should just do ... to solve this problem).

Like so many logical constructs, it really just seems to exist so we can apply it when we are frustrated, not in our day to day decision making.

I don't think that's happening. Here are the Chesterton's Fence stories that have made HN's front page:

Chesterton’s Fence: A Lesson in Second Order Thinking - https://news.ycombinator.com/item?id=22533484 - March 2020 (85 comments)

The Fallacy of Chesterton’s Fence (2014) - https://news.ycombinator.com/item?id=13063246 - Nov 2016 (26 comments)

The Fallacy of Chesterton’s Fence (2014) - https://news.ycombinator.com/item?id=11743965 - May 2016 (2 comments)

There was also https://news.ycombinator.com/item?id=23196731, which was on the front page for 5 minutes before we buried it.

It's true that it's an internet cliché though—so much so that Chesterton seems in danger of turning into his fence.

Young developers often propose large-scale rewrites with little sense of the costs or risks involved. Changing old code often has unintended side-effects.

?? This phenomenon applies to every topic on the front page. We like to rehash the same concepts and subjects over and over.

I can summarise this article in 1 sentence:

Before destroying/removing/deleting something, make sure you spend sufficient time to understand why it was created in the first place and if you can't, then leave it intact.

No need to spread 1 piece of butter on a whole bakery worth of bread

If I'm reading your revision correctly, you're suggesting leaving the feature in place if you cannot spend the time to understand its justification, rather than if you cannot find a justification. Your wording could be read either way.

The first interpretation is generally more defensible, but still not an absolute. There may be circumstances in which time does not exist and other exigencies prevail. As an example, if you come across a fence in the course of, say, responding to / evacuating from a natural disaster, you might consider briefly if there's some specific danger that the fence guards against (say, a cliff or other hazard), but determine that the greater benefit is in removal for the purpose of effecting rescue or escape.

First-responders don't agonise over why car doors were created when deploying Jaws of Life, earthquake responders don't survey plans of buildings to determine why walls exist before demolishing or removing them to access victims.

In less pressing circumstances, such as making incremental updates or changes to some system, performing some inquiry into purpose, intent, or function is strongly advisable, and Chesterton's Law is a check against naive and uninformed alteration without such considerations.

And this distinction is very important. Organizational scar tissue can and does develop, where things are a certain way and no one for sure knows why, but there are {vibes, superstition, ego, whatever} that develop into maintaining them.

It's really important to challenge these things, but they're tricky specifically because no one owns the decision (the person who chose left, or forgot, or who knows) so a naïve application of "don't change what you can't figure out the reason for" fails when there may be no clearly documented reason, beyond a shared hunch that it mattered at some point.

Sure you should still investigate, but if after a decent investigation you can't figure out why, yes, change the thing. Sometimes you'll be wrong, but this is what we have error budgets for.

Quite and very much this.

Where the change is needed and previous rationale can't be determined, if possible:

- Note that you've made the change.

- That the previous rationale wasn't clear.

- If possible, provide for backing out the change if it proves ill-advised.

Often an initial approach can be to disable or bypass a specific mechanism. E.g., put a gate in a fence, a bridge over a gap, disable a feature, etc. Watch to see what does or doesn't fail.

In software, specific time-triggered events may exercise infrequently-traversed paths --- end of week, month, year, etc. Naturally, these are hard to detect in advance. More convoluted are conditions triggered rarely (lunar cycle ~= 19 years, leap years, Unix epoch overflows, etc.).

This is where documentation and QA engineering will save butts.

I'm not sure what Frost's _Mending Wall_ was supposed to add to this. In that poem, in the author's view the wall is entirely pointless, since it doesn't actually block anything. But his neighbor insists on repairing it because "good fences make good neighbors".

Its juxtaposition with Chesterton's essay is kind of weird, because Frost doesn't even know what the wall is for, and apparently neither does the neighbor.

Chesterton never working in an Enterprise, here are the most common reasons for a fence. 1. developer, who's long gone, only supported road with fence, not road 2. budget needed to be spent and fence was the right price 3. friend of a friend builds fences and needed some work

Still the most important lesson for the average person to bake into their thinking.

Maybe not so much the HN crowd...but then again maybe especially them

What was the guy who put up the fence thinking? Maybe he was thinking of someone else who put up a fence, who also thought: "What was the guy who put up the fence thinking? Maybe he was thinking of someone else who put up a fence, who also thought: ..."

Previous discussion: https://news.ycombinator.com/item?id=22533484

Wow. Chesterton's original essay was a pithy commentary on the value of humility. It doesn't really require a lot of further explanation, but here we are.

Sometimes re-enforcement of humility is key. People who do computers for a living operate in a space where they both define realities and operate in those definitions; it's pretty easy to build up a poorly-earned god complex there.

I'm getting ready to leave my current gig, and have had Chesterton's fence in mind, but kind of in a reverse way -- I'm trying to do some cleanup of confusing code so that it doesn't become a Chesteron's fence after I'm gone. There's some complicated code that absolutely doesn't have to be that complex, and I know that if I don't take the time to refactor that before I head out, some poor developer's going to be stuck debugging an issue that would be much clearer (or may not even happen at all) if that code were gone.

I did the same once right before switching teams. It feels good when you make a dent but you'll never feel done. Don't let great be the enemy of good

When I was younger, I thought I could examine a situation until I understood it. Now I feel like one must experience a situation to understand it.

Chesterton's Fence is a good principle; so is "Go and See" - https://en.wikipedia.org/wiki/Genchi_Genbutsu

Wisdom is deciding how much of each to do.

On the other hand, if you don’t know, and no one else around know, removing the chester might be a good option to quickly know why it was there rather opting for long inner speculations.

Yes, maybe the fence is there for a good reason, in which case the people that installed it made a poor documentation job. So who know what else they poorly implemented?

You could easily call this thought experiment Chesterton's Cage. At least that is more honest about the philosophical implications. It's like Plato's allegory of the cave, except the argument is that you should never leave the cave because you don't (and can't) know what's outside.

I have mixed feelings about Chesterton, but I’m not sure this is fair. I think the point is that change is not a good in itself; it’s only good insofar as the new state it brings into being is good. It places contemplation of the good above praxis.

Seeing some of the responses in this thread, I think I might want to withdraw, or at least modify this comment. I am going to leave it as is because others have upvoted it, as is.

People are trying to interpret the analogy outside of the theological context in which Chesterton wrote, and therefore either reduce it to the kind of relativistic conservatism that GP rightly decries, or else deny what Chesterton actually wrote.

Chesterton’s point is that change can be good or destructive. Since evil is not a positively existing thing, but merely a lack of goodness, a lower goodness mistaken for a higher goodness, or vice versa, if I am to act upon something in order to bring it to its full goodness, I have to understand the goodness already in it, otherwise I act in a way that is destructive. In short, I can only be trusted to change a thing if I am able to love it.

You can know what's outside and you can leave your surroundings. The point is that you should understand first why things are in the way they are before implementing any change.

But the point of my comparison to Plato's allegory of the cave is that there are situations where you can't know. If we applied Chesterton's fence to situations at the limit of our understanding, say physics, would we be compelled to shutdown CERN?

What are you on about?

CERN is an instrument to help us learn more about physics. Bringing it down would not help us make any change, and it would only hinder us from learning more about the truth of nature. You need a better example than that.

My point is the bounds of reality and knowledge are their own sort of fence. This isn't a stretch, because this is literally the philosophical point of the argument.

What if a high energy particle collision causes a miniature blackhole that destroys all life on earth? What if sailing across the uncharted sea makes God angry? What if knocking down the walls of my cage lets the monsters in? What if the act of investigating the fence destroys the fence?

> This isn't a stretch, because this is literally the philosophical point of the argument.

This is reductio ad absurdium. There is a whole lot of contexts and dimensions where the concept of Chesterton's Fence can be applied before trying to dismiss it.

If you want a better example, you could ask "why so many religions teach to not eat pork?"[0]. Then we could look at historical contexts (i.e, understanding why it was put up in the first place), realize that most of those don't really apply to the modern world and "tear it down" if you want to enjoy delicious pulled pork sandwich.

> What if sailing across the uncharted sea makes God angry?

That is not a satisfactory answer to "why can't we explore the seas?", and any rational person would/should continue to investigate.

---

[0]: https://www.youtube.com/watch?v=Sew4rctKghY

Its good to note that sometimes "it makes God angry" is not a TERRIBLE answer. Maybe X or Y act does on average create worse results for a person/group/society that aren't immediately apparent or obvious, but people managed to figure out via correlation or even evolutionary pressure (the groups that refused to eat pork lived longer and had more kids). Recognizing that X or Y on average causes a worse outcome for reasons you dont understand isnt a terrible thing.

Using the "sail the uncharted sea makes god angry" example.

Maybe that particular parts of the ocean has sea monsters (dangerous animals), and lots of whirlpools, and lots of poisonous fish that kill you if you eat them, and pirates.

People short hand that to "going there makes God angry" because they know people don't come back and when they do come back its in worse condition. But its never quite the same root cause. (hence why they blame god, and not the pirates for example) So there is no easy one answer unless theres concrete efforts to add together the stories of the guy who got attacked by pirates, the guy who had a run in with a giant squid, the guy who got poisoned, and the guy who almost drowned in a whirlpool.

You'd be pretty foolish to ignore the "god will get angry" warning, if you go there. You might have heard one or even two of the dangers, but not all of them that push the risk profile so high. Thats where Chestertons fence becomes useful and says you should be the person that gets all the stories together and realizes the real dangers and not dismiss the "god will get angry" warning off hand.

Even if we agree that it is not a terrible answer, we seem to agree that it is an insufficient one. Notice that I didn't say that the reaction to hear such an answer would be to ignore and take down the fence, but to keep investigating for the underlying truth.

Yes, but plenty of people would treat religious/ideological justifications as the reason and stop their investigation there.

"Make god angry" is parsed as "because these people had a religious belief i believe is false", and they assume they understand the Fence in question and mow it down.

If the issue is that someone in a position of power wants to make the change and all they are given is "religious/ideological justifications", then I'd say that an incomplete answer is indeed bad.

It's easier to dismiss 20 different people saying the exact same, meaningless "God will be angry" answer than to dismiss 20 different tales of "someone two/three/six generations ago got attacked/drowned/never was seen again after going to the ocean".

Such "laws" or rules of thumb should always be interpreted in light of reason. There's nothing reasonable about paralyzing yourself by entertaining random risks or possibilities for which there is no justification. That's as silly as the idea that science is about doubt as a matter of method. It isn't. You don't go around arbitrarily doubting things for no reason because you have somehow convinced yourself that such willful doubting produces knowledge. It doesn't. It produces an incurable skepticism that destroys science. Doubt is the effect of having learned something credible that conflicts with a prior belief. That doubt might prompt us to verify these conflicting bits of information in order to establish some kind of certainty.

Chesterton's Fence is a criticism of reformers, revolutionaries, and burn-it-all-down types who want to make changes without making an effort to understand why the thing they want to tear down is there in the first place, what purpose it is serving, and the consequences of doing so.

Responsible jurisprudence does this all the time. When judges are presented with a case that puts a law into question, they look at the origins of the law and make an effort to determine the costs of eliminating that law because the good of a lot of people may rely on that law being in place. This doesn't mean they don't change the law if some people would suffer as a result. It just means they are aware of why the law exists and what purpose it serves as well as the relative costs and benefits of doing so (principle of double effect). Naturally, as you have said, we do not have perfect knowledge, so obviously we can merely do the best we can. A person is not obligated to do the impossible.

> What if sailing across the uncharted sea makes God angry?

most of these examples are not structured as a Chesterton's fence type problem.

If there is a prohibition against sailing across the seas in the town's bylaws and you do not know why it is there, then you would have Chesterton's fence. You would then do investigation until you found an old letter from the mayor about his indigestion and a bad dream that told him that sailing across the seas made God angry.

Then as making God angry is understood as not a reasonable prohibition and the mayor's indigestion not sufficient cause for anything (especially as that mayor died years ago) it would be concluded that you could then sail.

The next day God will of course smite you and everyone in the town, but thems the breaks.

on edit: fix typo, fix grammar

I don't think that's the way Chesterton's fence is supposed to be used.

The kind of situations where it could be applied is when an individual wants to change a system, i.e., when an developer wants to rewrite a codebase that "is way too complex for what it is", when a employee see a process that doesn't seem to make any sense, when a reformist wants to change the rules of society, ...

It's basically an invitation to consider why the system was put this way, before envisioning how to change it. Instead of designing a new system based on the flaws of the current system, find out why it was designed this way, so you can design a system that solves both the flaws of the current system, and the flaws of the previous system, for which the current system was put in place.

> If we applied Chesterton's fence to situations at the limit of our understanding, say physics, would we be compelled to shutdown CERN?

You’re applying Chestertons fence backwards. Instead, it would inform you to _not_ shutdown CERN until you tried to understand its purpose.

This article made me think of the many virtues of the (analog) landline telephone system, built up over a century of universal usage. All due nostalgia aside, its well-known problems and solutions have been replaced by an arguably (physically) less resilient and markedly more wasteful alternative.

I have yet to see a detailed balance sheet on that choice (which includes externalities) from the 'someone who made that decision'. No doubt 'profits' are up, depending on who defines 'profit', and who it advantaged. Sometimes things start out seeming like a great idea (universal automobile ownership). Sometimes haste (like universal nuclear energy, all political motivations aside) makes waste.

The less-discussed issue is the high rate of turnover with respect to corporate roles. There are significant incentives that push new leaders to "remove the fences" rather than spend the time (money) and energy (capital) to determine why the fence was there in the first place.

Often, new leaders replace old frustrations, and concluding that the previous regime had some wisdom of its own is received like a lead balloon.

Chesterton was right, but probably did not consider corporate politics :-)

Sometimes this is definitely the case - by removing the fence you have an immediate impact, so you get promoted, and somebody else deals with all the consequences.

But that doesn't mean we should always establish why the fence is there. Sometimes, the opportunity cost of working out the reason outweighs additional certainty. I guess good leadership is repeatedly making the right call over when to do one or the other, and putting in place appropriate mitigations in case you're wrong.

> repeatedly making the right call over when to do one or the other, and putting in place appropriate mitigations in case you're wrong

I think succeeding in this part already requires quite a bit of the understanding that Chesterton's Fence is actually calling for.

If you're (in good faith) able to make an informed opinion between choosing taking the risk and gathering yet more additional information, you're already in a much stronger position than what's usually considered as the failure mode of not taking the Fence into account at all.

That makes sense. I guess I like the nuance of the Cynefin framework for this.

Past related threads:

Chesterton’s Fence: A Lesson in Second Order Thinking - https://news.ycombinator.com/item?id=22533484 - March 2020 (85 comments)

The Fallacy of Chesterton’s Fence (2014) - https://news.ycombinator.com/item?id=13063246 - Nov 2016 (26 comments)

Yeah, it's important but not some grand law one should obey. I think every technical person has a time in their early life where they come across something that was genuinely wrong or illogical or just bad (in some cut and dry way). That imprints on them and from then on it is burned into our minds when we see something that seems off to immediately think "that is stupid". That is always my first (perhaps subconscious at times) thought I know and suspect it's fairly endemic.

All I take this nice parable to mean is that maybe you make your second, less instinctive thought be "why is that here?". That's it. Consider it then carry on. No law mandating a thorough investigation. No restriction on change without complete understanding. No need for deterministic certainty. Just a simple consideration that you should entertain. Or perhaps more accurately, a consideration you shouldn't disregard.

There are situations where the defenders of the fence are willfully obscuring / misrepresenting its purpose or may not even know it themselves, when I think this argument reaches its limits.

The point is to expend effort, where possible, in gaining understanding.

Recognising the possiblity of misrepresentation is yet another higher-order level of awareness.

I love the corollary developing here called Chesterton’s cage. It’s an extension of the fence, but on four sides around you (or something of value).

ADRs FTW

This actually made me laugh

Advanced dining reservations?

Chesterton’s fence is lazy.

Here’s a better approach:

- admit that deprecation work is hard. Damn hard.

- but know that is important. Damn important.

- read the chapter on deprecation (15) in the book Software Engineering at Google [1]

- come to appreciate that if deprecation is a hard problem for Google, then it is hard for you

- sit down, take a breath, make a plan, then roll up your sleeves and do it. Smash that fence.

- if needed, watch Shia LeBoeuf’s motivational on youtube

- just do it

[1] https://abseil.io/resources/swe-book

Reply on news.ycombinator.com