Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The criteria for removal are clear on paper, but impossible to meet, so the effect is the same.

It is impossible to meet because the reason why the proverbial fence was put up is, more often than not, a mixture of misunderstandings, logical fallacies and political motives from both the one who put it up, as well as other stakeholders involved, and most importantly, none of those aspects are documented and none of the people are around anymore. You'd need nothing less than a time machine to understand why the fence was put up.



As with all things in life, it's a matter of accumulating evidence up to an acceptance criterion. That criterion can never be 100% certainty, because nothing can be 100% certain.

The difficulty lies in agreeing on what that point should be, and on the magnitude of any particular piece of information as evidence for or against any particular hypothesis.

"The fence was a mistake" is a completely legitimate conclusion here. The principle exists to prevent us from jumping immediately to that conclusion out of convenience, arrogance, or ignorance. It should not be interpreted as preventing us from ever reaching that conclusion after some careful consideration.


"impossible to meet", "more often than not", "none of those aspects are documented": These are huge generalizations, and I very much doubt that they are generally true, or that anyone--including you--has done any kind of investigation into how general these conditions are.


You are the one adding the criteria that you need to know EXACTLY and fully why the fence was built. There is obviously a spot between “I have no idea what the fence was built” and “I know the exact intricate workings of all the minds that were involved in the decision to put up the fence”


> The criteria for removal are clear on paper, but impossible to meet, so the effect is the same.

These arguments are exhausting, especially when we are talking about political issues.

Do you really believe that it is literally impossible to figure out that some legislative "fence" is really a moat protecting entrenched interests of the lobbyists who helped write the legislation?


Fascinating, can you give a couple examples of pre-existing rationale that make it impossible to replace an unneeded fence?


Not OP, but I’ve encountered this in situations where legacy code involved in mission critical business functionality was nearly impossible to remove due to the potential risk of unforeseen impact.

In other words, if the potential impact of an unforeseen breakage is high enough (costs us or the customer $$$), it’s not worth risking the change even if we can find absolutely no good reason for the current behavior to exist.

Example: complex spaghetti that touches billing calculations. These things are better addressed by a full rewrite/redesign followed by a long period of running both things in parallel until we’re confident that we didn’t miss anything. Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.


Sounds like you did the right thing by not changing the code! The rule worked

What would have been the advantage, in this situation, to ignoring the rule? What problem here is the Chestertons Fence rule causing?

EDIT: (responding to below, your issue has nothing whatsoever to do with Chestertons Fence. Making careful code changes to test then effect of removal is a great way to apply the rule. Building a separate system and testing in parallel would be an even cooler way to apply the rule)


The benefit of rearchitecting the code would have been high. As it stood, the status quo was blocking progress on other initiatives and making it difficult to meet the needs of customers. If we had ignored the fence and nothing broke, we could have immediately made major improvements that our customers had been begging us for.

The reality is that we don’t know if it worked. It’s possible that our conclusion that this had no reason to exist as written was accurate, and that doing nothing didn’t actually prevent anything bad from happening. It’s also possible that we saved ourselves from something we didn’t understand.

I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it.

Edit: I can't really respond to your response in its current form without these comments getting really difficult to understand. I disagree that this has nothing to do with Chesterson's fence. It's essentially a failure mode that can occur when applying the ideas behind the principle, i.e. there are times when learning everything we can about a barrier and believing with a high degree of confidence that the barrier isn't needed still isn't enough to remove it due to other factors. This points to the fact that this is a guideline, not a law.


> I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it.

I don't understand this. Implementing billing from scratch and running it in parallel to the old code is a form of doing due diligence. I.e. it is an application of Chesterton's fence. It might be an expensive application but it is one.

To me, this anecdote shows the value of documenting the why of software. I've read some time ago, to add code to systems such that, it is simple to remove it again. This discussion deepened that insight for me. This is preparing for Chesterton's fence.


> it is an application of Chesterton's fence

That's why I closed with:

> Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.

In other words, it's still learning from the cautionary tale of the fence, but the end result isn't a classic removal or non-removal of the fence itself. And it's not as if the idea has hard and fast rules :)

I agree regarding the value of documentation. None of us involved in the project were at the company when the code was written, and so we were left with a dangerous task.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: