The recourse when nobody can be found who knows or remembers why the fence is there, is to figure it out based on first principles. It's fine to do "tear it down and see what happens" as a consciously chosen trade-off for expediency. But in my experience people often act like there's just no way of knowing if you can't find someone to ask, and that's very rarely the case.

In software, sure, reasoning from first principles is likely to work. With older traditions, it could just as easily lead you to just-so stories and other false explanations, such as the endless number of false etymologies which make all seasoned linguists deeply suspicious of any cute etymology, especially one which could be used to make a point.

Sure, I was talking about software. I think lots of other things are attackable from first principles. But sure, some aren't.

So true.

"What do you mean add in logging and watch it over several months?!?!?! I'll have to climb the fence for several more months, that's not acceptable!".

ok...

> at what point do we tear it down to see what happens?

Without knowing the purpose of something, we cannot know the cost of removing it.

A few weeks someone commented to me on how they thought that some chain link fencing along a railing should be removed because it was unsightly, until they saw a toddler playing near the railing and realized that the toddler could easily squeeze through if the chain link fencing wasn't there. If they never saw the toddler, they would have thought the fencing pointless. If the people they asked failed to think of the size or behaviour of toddlers, their conclusion would remain unchanged. Yet, had that chain link fencing been removed, the results have been tragic. Because of the nature of my work, I can think of many other circumstances where safety measures have been put into place where only a few people would understand their purpose. In most cases the reason is less obvious than that bit of fencing. Unfortunately, few of them have the element where someone realizes the purpose out of chance before the damage was done.

Much the same can be said of software. It may seem like it is fine to pull out a piece of code, test it outside of a production environment, and give it the okay when everything works. Yet it may not be fine. That code may have been inserted to deal with a problem that client X was having to deal with one of their requirements or to deal with a peculiarity of their production environment. Because it is particular to a particular client, the development team may not know of it (e.g. the developer who did the work is long gone) or it may have simply been forgotten. Just because the purpose is unknown in the present doesn't mean that removing it is devoid of consequence. Those consequences may range from impacting their procedures, to financial loss, to safety.

At the end of the day, you need to understand why something exists to determine if it is still relevant. It should be removed only once you know that it is no longer relevant.

This reminds me of the story of Muntz TVs. Mr. Muntz was a self-taught engineer who made a company that produced TVs at significantly lower prices than everyone else, and there's stories of how he'd work with his engineers and just randomly remove parts he didn't think were necessary, to cut costs. Many times, it worked, so the production design adopted these changes.

The problem was, while these minimalist-component TVs seemed to work OK in the lab, or in most customers' homes, they didn't work very well in edge cases (like people in locations with poorer signal strength).

I hope they added a sign, “keep children away from train,” to the fence.

If you have good tests, the reason is often much more clear.

> in software, I would rather tear it down and find out what it was there for.

if you don't have regression testing there's a chance you don't find out until something disastrous happens

There's a reason it's called a scream test.

You take out the fence, then watch closely for the disaster. Likely the fence was unnecessary because most fences are built to accomodate for somebody's personal tastes and aesthetics

When you remove something from the software you are improving your understanding of it. I don't see how this example adds to your argument.

i'm sorry I was unclear. yes - I strongly recommend removing the fence and seeing what happens. climbing over it every day and giving it a glare just leaves you in the dark.