Hacker News Reader

Comment by mmaunder | Hacker News Reader

Another approach is to temporarily remove the fence and the gate and monitor the effects. This is far less work than doing an organization-wide audit to first determine why the fence and gate exist.

Chesterton's Fence leads to the ossification of large organizations. Determining why the fence exists can be so much work that it's easier to just leave it be and move on or go and work somewhere nimble.

View on HN

This all depends on the risks involved.

Can I handle it failing, sure, go ahead. There are so many variables that could be involved, not uncommonly including temporal ones. I don't think simply monitoring for a period and calling it healthy is of any guarantee.

I do very much think you are right though. Being too risk averse will grind everything to a halt.

Your whole process has to be designed around avoid these issues. Allow failures, fix continuously and _quickly_, don't repeat mistakes.

Ossification of systems is mostly due to zero order thinking - a paucity of examination into the purpose of established systems. If someone with the agency to change a system gets to 2nd order thinking in their decision making, that is a blessing to everyone.

Even better: instrument the fence without removing it. You get the same knowledge without the chance of breaking stuff. If it's code, put it under a anti-feature flag.

Chesterton's fence might not be ideal for a fast moving startup. Perhaps it is a better strategy to question the wisdom of anything that existed only for a few month/years. But if we are talking about society-wide or nation-wide changes, Chesterton's fence seams to be quite relevant. It is rather easy to destroy a society, but it is so damn hard to create a prospering society.

That approach can work but requires a person with enough experience with the systems+domain in question to know when it's a reasonable risk. Just last week we had an example where they didn't have enough experience and there was an enormous effort to clean up all of the transactions that posted incorrectly.

It may be that the fence is there for a catastrophic black swan, so this method may not be suitable.

The most interesting remedy is continually developing domain experts in both roads and fences within the organization who can reliably intuit the likely purposes of the fence when they come upon it.

That's called a "scream test", and it's for after you think you've probably found everything important.

Reply on news.ycombinator.com