I have this law that I call "Chesterton's Documentation". If the reason for the fence isn't documented, do not be shocked when someone inevitably comes and decides to remove the fence. If you want your fence to stick around: document the rationale. That way, later people know if the reasoning still holds. And if you're at the point where the fence is being removed: might as well bite the bullet. The way I see it, the fallout from the removal (if there is to be any) was sealed at the moment it wasn't documented.
I've come across so many of these in my career. It's not even a rare occurrence (and the author gets this, "And just like that, we are again at step 1 of our debugging journey.") While in the author's case there was a reason for the fence to exist, IME quite often there just isn't. But I've also spent a lot of time working at startups where the mentality was "move fast and clean nothing up".
Sometimes, ^F the thing you're interested in Slack. I've solved a number of code archeology mysteries with that. (But, I doubt it would help here. The author's problem lacks enough context / good search terms. It works better when you have something with a solid name, like a VM.)
I've come across so many of these in my career. It's not even a rare occurrence (and the author gets this, "And just like that, we are again at step 1 of our debugging journey.") While in the author's case there was a reason for the fence to exist, IME quite often there just isn't. But I've also spent a lot of time working at startups where the mentality was "move fast and clean nothing up".
Sometimes, ^F the thing you're interested in Slack. I've solved a number of code archeology mysteries with that. (But, I doubt it would help here. The author's problem lacks enough context / good search terms. It works better when you have something with a solid name, like a VM.)