Story time: at my previous job we had an old server called "the black box" which hosted some old cronjobs and various services from about a decade earlier. There was no documentation and everyone who had worked on it had left years earlier. The ops team dutifully kept it online but otherwise didn't touch it, and no other team owned it. In short, it was the ideal candidate for your "reverse Chestertons fence" strategy. At some point we had to delve into what was actually on it, and it turned out that both company payroll and a service responsible for about 50% of company revenue was on that box. Simply removing it to see what happened would have easily cost a few million in revenue, even if it could be reinstated from backup a day later (and I'm doubtful if we could have restored it at all without serious data loss). Now obviously having such a server is a bad practice in the first case, but if you find yourself in such a position "just kill it and see what happens" is definitely not the most economical option in all cases.

In the case of POSIX it might hold, since probably the worst case is that some volunteers throw away a few years of their life hacking away on yet another OS that will never gain traction. Humanity spends a lot more time on a lot less worthy endeavors.

Why are you putting the onus on someone else to provide clues that you understand?

You still don't escape the requirement to understand the problem before fixing the problem. Even if the explanation for the current solution is lacking, you still need to understand enough to articulate why it's lacking.

It is completely crazy to expect people to "pro-actively explain why it's there" -- how do you see this? A plaque at every fence with explanation? A person standing by fence every day, just in case someone wants to tear it down? Do you expect each shared object to be labeled and documented?

Whomever wants to tear the fence down has to do basic research -- visit city hall for the plans, talk to old-timers, check the old newspapers, etc... If they do it, this qualifies for "understanding". And yes, maybe the fence was put by Crazy Old Bill who was paranoid about neighbour's goats... then yes, tear it down. But make sure it is really him first, and not some better reason.

> assuming you don’t know consequences of removing the fence, you also have to assume that you don’t know consequences of letting the fence in place,

Note that at some moment there were no fence, and yet someone has expended non-trivial effort to put the fence up. This means someone had a reason do to so, so whomever that past person was, they knew more than you did right now. Therefore, unless you believe that you are smarter than most other people, you should defer to their past decision.

(And if you believe that you are smart that most other people, and yet want to tear down the fences you don't understand... I have bad news for you :) )

> Actually, assuming you don’t know consequences of removing the fence, you also have to assume that you don’t know consequences of letting the fence in place, which might just as well turn to a dramatic situation.

That assumption reads as false to me. There should generally be historical data around the costs and consequences of maintaining the fence. E.g. if you're shutting down a server, it's generally easy to figure out how much the hardware costs, how many man-hours you spend on maintaining it, etc. None of that requires knowing why the fence exists.

Those costs and consequences tend to be small, because large costs have to be continually validated as a good use of resources so they have a living memory of sorts.

> What is for sure, if nothing around can explain its purpose, is that it was placed here by people to negligent to induce the right clues about it.

Again, I don't think this is sure. I've seen lots of cases where docs probably did exist at some point, but the writers left and successors lost the knowledge of where the docs are or failed to migrate them to a new system or etc. They're lost to attrition, not to negligence.

> Remove the fence unless someone know why it was put up in the first place, and the rational still hold.

It doesn't, because it's trading known risks for unknown and unbounded risks. That's usually a bad trade, especially when the known costs tend to be small. Nobody wins a promotion for causing a million dollar outage while trying to get rid of a $50/month maintenance cost.

I can't upvote you enough.

Around here, on HN, Chesterton's fences pops up so many times as some type of ageless nugget of wisdom.

But another way to look at it is that it's just the lazy guy's excuse to allow bit rot. Because, let's be honest, we only care about Chesterton's fence in the context of software development.

Who among us did not work with software with dark corners, with files with no commits in the last 10 years, with playbooks that people just go through mechanically, because there's no one from the "old guard" who remembers why things are the way they are?

Who would not love to live in an alternate reality, where each Chesterton's fence was removed at the first opportunity, rather than left there to burden future generations of unlucky toilers? Where code is clean, documentation is up to date, tests complete, colleagues who know what's going on? Well, that alternate reality does not exist, of course.

But at least let's stop thinking we are wise whenever we postpone deprecating something we don't understand, just because some semi-famous essayist came up with a nice figure of speech one hundred years ago.

I think it depends on your experience and what you have gone through, in my case how many of the decisions I've made that looked excellent to me back then, turned out to be okish at most.

Can we actually improve the POSIX shell?

Can we reform it, perhaps into a "D-shell," that is an LR-parsed language?

AWK had a yacc grammar for many years. Why can't this be the language of the shell, at least for the sake of maintainability and comprehension?

https://archive.fosdem.org/2018/schedule/event/code_parsing_...

Part of the process of erecting your own identity, both individually and as a generation, involves flatly refusing and denying the practices of your immediate predecessors (eg: your parents' and their generation of men, source code written by programmers before your time, etc.).

It's stupid and almost always leads to unintended (and usually negative) consequences, but it's probably something strongly ingrained in our instincts because it rears its ugly head every time there's a generational turnover.

Some variation on this has been consistently brought up for going on a decade now. At this point it's a HN meme.

Its opposite is "cargo culting".