14 ms·

Chesterton’s Fence (2020)

158 points by hasheddan 5y ago

auntienomen 5y ago
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.
- brodouevencode 5y ago
  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.
- foobarian 5y ago
  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.
- parentheses 5y ago
  must be the second order effects of said trauma
- shadowgovt 5y ago
  I expect it's a frequent side-effect of working on large systems with many interdependencies.
- jqgatsby 5y ago
  Before we stop frontpaging articles about Chesterton's fence, we must first understand why the articles are being frontpaged to begin with.
  - leobg 5y ago
    I like what you did there.
- forgotmypw17 5y ago
  Perhaps it is the trauma of non-consensual changes in software and especially user interfaces that we are forced to deal with regularly?
- dogleash 5y ago
  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.
- BitwiseFool 5y ago
  Things get reposted all the time, is there something particularly odious about Chesterton's Fence?
- deleted 5y ago
  [deleted]
- stinkytaco 5y ago
  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.
- dang 5y ago
  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 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 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 https://news.ycombinator.com/item?id=11743965 - May 2016 (2 comments) There was also https://news.ycombinator.com/item?id=23196731 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.
- neartheplain 5y ago
  Young developers often propose large-scale rewrites with little sense of the costs or risks involved. Changing old code often has unintended side-effects.
- exolymph 5y ago
  ?? This phenomenon applies to every topic on the front page. We like to rehash the same concepts and subjects over and over.
cmsefton 5y ago
Previous discussion: https://news.ycombinator.com/item?id=22533484 https://news.ycombinator.com/item?id=22533484
femto 5y ago
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.
- carlmr 5y ago
  >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.
- dccoolgai 5y ago
  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.
  - marcosdumay 5y ago
    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.
deleted 5y ago
[deleted]
reedf1 5y ago
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.
- huetius 5y ago
  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.
  - huetius 5y ago
    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.
- rglullis 5y ago
  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.
  - reedf1 5y ago
    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?
inwit 5y ago
ADRs FTW
- brodouevencode 5y ago
  This actually made me laugh
- dredmorbius 5y ago
  Advanced dining reservations?
this_steve_j 5y ago
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).
mtzet 5y ago
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.
- robertlagrant 5y ago
  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).
  - deleted 5y ago
    [deleted]
- JamesSwift 5y ago
  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.
- satyrnein 5y ago
  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.
Wolfenstein98k 5y ago
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
evancoop 5y ago
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 :-)
- blowski 5y ago
  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.
  - shandor 5y ago
    > 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.
    - blowski 5y ago
      That makes sense. I guess I like the nuance of the Cynefin framework for this.
pnutjam 5y ago
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
psychoslave 5y ago
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?
vivegi 5y ago
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.
- winstonewert 5y ago
  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.
  - vivegi 5y ago
    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).
    - winstonewert 5y ago
      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.
  - slowhand09 5y ago
    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".
mhb 5y ago
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.
- shadowgovt 5y ago
  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.
less_less 5y ago
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.
csours 5y ago
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 https://en.wikipedia.org/wiki/Genchi_Genbutsu Wisdom is deciding how much of each to do.
sohdas 5y ago
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.
- dredmorbius 5y ago
  The point is to expend effort, where possible, in gaining understanding. Recognising the possiblity of misrepresentation is yet another higher-order level of awareness.
vintermann 5y ago
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: ..."
credit_guy 5y ago
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 https://abseil.io/resources/swe-book
tsewlliw 5y ago
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.
- ska 5y ago
  > 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.
bmhin 5y ago
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.
dang 5y ago
Past related threads: Chesterton’s Fence: A Lesson in Second Order Thinking - https://news.ycombinator.com/item?id=22533484 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 https://news.ycombinator.com/item?id=13063246 - Nov 2016 (26 comments)
8bitsrule 5y ago
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.
political12345 5y ago
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
- dredmorbius 5y ago
  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.
  - joshuamorton 5y ago
    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.
anyonecancode 5y ago
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.
- mkoubaa 5y ago
  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
SergeAx 5y ago
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!

158 points by hasheddan 5y ago

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.

brodouevencode 5y ago
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.
foobarian 5y ago
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.
parentheses 5y ago
must be the second order effects of said trauma
shadowgovt 5y ago
I expect it's a frequent side-effect of working on large systems with many interdependencies.
jqgatsby 5y ago
Before we stop frontpaging articles about Chesterton's fence, we must first understand why the articles are being frontpaged to begin with.
- leobg 5y ago
  I like what you did there.
forgotmypw17 5y ago
Perhaps it is the trauma of non-consensual changes in software and especially user interfaces that we are forced to deal with regularly?
dogleash 5y ago
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.
BitwiseFool 5y ago
Things get reposted all the time, is there something particularly odious about Chesterton's Fence?
deleted 5y ago
[deleted]
stinkytaco 5y ago
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.
dang 5y ago
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 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 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 https://news.ycombinator.com/item?id=11743965 - May 2016 (2 comments) There was also https://news.ycombinator.com/item?id=23196731 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.
neartheplain 5y ago
Young developers often propose large-scale rewrites with little sense of the costs or risks involved. Changing old code often has unintended side-effects.
exolymph 5y ago
?? This phenomenon applies to every topic on the front page. We like to rehash the same concepts and subjects over and over.

cmsefton 5y ago

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

femto 5y ago

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.

carlmr 5y ago
>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.
dccoolgai 5y ago
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.
- marcosdumay 5y ago
  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.

deleted 5y ago

[deleted]

reedf1 5y ago

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.

huetius 5y ago
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.
- huetius 5y ago
  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.
rglullis 5y ago
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.
- reedf1 5y ago
  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?

inwit 5y ago

ADRs FTW

brodouevencode 5y ago
This actually made me laugh
dredmorbius 5y ago
Advanced dining reservations?

this_steve_j 5y ago

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).

mtzet 5y ago

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.

robertlagrant 5y ago
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).
- deleted 5y ago
  [deleted]
JamesSwift 5y ago
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.
satyrnein 5y ago
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.

Wolfenstein98k 5y ago

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

evancoop 5y ago

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 :-)

blowski 5y ago
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.
- shandor 5y ago
  > 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.
  - blowski 5y ago
    That makes sense. I guess I like the nuance of the Cynefin framework for this.

pnutjam 5y ago

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

psychoslave 5y ago

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?

vivegi 5y ago

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.

winstonewert 5y ago
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.
- vivegi 5y ago
  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).
  - winstonewert 5y ago
    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.
- slowhand09 5y ago
  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".

mhb 5y ago

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.

shadowgovt 5y ago
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.

less_less 5y ago

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.

csours 5y ago

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 https://en.wikipedia.org/wiki/Genchi_Genbutsu Wisdom is deciding how much of each to do.

sohdas 5y ago

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.

dredmorbius 5y ago
The point is to expend effort, where possible, in gaining understanding. Recognising the possiblity of misrepresentation is yet another higher-order level of awareness.

vintermann 5y ago

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: ..."

credit_guy 5y ago

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 https://abseil.io/resources/swe-book

tsewlliw 5y ago

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.

ska 5y ago
> 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.

bmhin 5y ago

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.

dang 5y ago

Past related threads: Chesterton’s Fence: A Lesson in Second Order Thinking - https://news.ycombinator.com/item?id=22533484 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 https://news.ycombinator.com/item?id=13063246 - Nov 2016 (26 comments)

8bitsrule 5y ago

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.

political12345 5y ago

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

dredmorbius 5y ago
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.
- joshuamorton 5y ago
  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.

anyonecancode 5y ago

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.

mkoubaa 5y ago
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

SergeAx 5y ago

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!