I understood it differently. As in: there is always a reason for the fence but you never know whether it is justified or not without understanding it. Don’t tear down the fence until you understand why it was put there for the wrong reasons.

True, but what I think s_kilk was getting at is that sometimes (especially in software) a bad developer will put a "fence" somewhere without a reason. And if that person already left the company, maybe you can never find out why.

That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but often it's not.

Even bad developers have reasons, you may not be able to divine those reasons but they may be legitimate. The would-be refactorer would do well to consider carefully what the reason might have been, even if a git-blame reveals a less-than-excellent contributor.

As an programmer I always try to capture these reasons in my commit messages, after a decade of doing this I’ve gotten a lot of thank you notes years after leaving a project, and I’ve even reminded myself details about my own thought process that I had otherwise would have long forgotten.

One thing I’ve learned by having long tenures is that context change over years is much more likely the reason for nonsensical code than developer stupidity.

> some testcases of required behavior, and then refactor only code that is supported by tests

The difficulty is making sure that you have all the requirements and aren't missing any, and once a system gets big enough, that gets really difficult.

Chesterton’s fence is an idea to help you counteract the exact notion you are expressing here. You must prove that the reason for its existence is no longer sensible (or, perhaps, never was sensible) before removing it. There is no probability distribution associated with the proverb, except that there is a nonzero chance of sensible explanation.

No, the point of Chesterton's fence isn't presuming there is a reason:

> The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

The point is that there might be a reason, and before careful consideration we won't understand what that might be.

You can't expect it to just come to you, you have to ask. Unfortunately many organisations are bad at institutional memory, so reasons get lost. But fundamentally this requires a "why?" conversation, it can't be done by purely technical means.

If you're very confident that your test suite covers all use cases, then you can just change it and see what breaks.