Reading the title, I first thought of a situation related to the one you describe, where someone ponders the pros and cons of fencing an open path, and after giving it thoughtful consideration, decides not to, for good reason.
So it’s not a question of removing the fence, but that it was never even built, it is “missing”. Yet the next person that comes upon the path would be ill-advised to fence it without thoroughly weighing the pros and cons, given that someone else decided not to fence that path.
You may think this all sounds abstract, but if you program often this is actually a situation you come across: programmer P1 spends a lot of time considering the design of a data structure or a codebase and so on, rejects all considered possibilities but the one that they implement, and perhaps document if they have time. But they will usually not document why they rejected and did not implement the N other possibilities they considered.
P2 then comes in thinking “Gee that sure would be convenient if the code had feature F, I can’t believe P1 didn’t think of that! How silly of them!”, not realizing that feature F was carefully considered and rejected, because if you implement it bad thing B happens. There’s your missing fence, never was built in the first place, and with good reasons.
the problem here is that sometimes the past programmer didn’t considered it all, and present-progeammer don’t have a way to distinguish between those possibilities. which is also the problem with the Fence, except in programming it’s easier to try, and roll back if you need to.
in the last place i worked, going by this heuristic would have been bad idea. the answer was mostly that they didn’t think about it, or that the code is old and you can use something better now, and should.
Reading the title, I first thought of a situation related to the one you describe, where someone ponders the pros and cons of fencing an open path, and after giving it thoughtful consideration, decides not to, for good reason.
So it’s not a question of removing the fence, but that it was never even built, it is “missing”. Yet the next person that comes upon the path would be ill-advised to fence it without thoroughly weighing the pros and cons, given that someone else decided not to fence that path.
You may think this all sounds abstract, but if you program often this is actually a situation you come across: programmer P1 spends a lot of time considering the design of a data structure or a codebase and so on, rejects all considered possibilities but the one that they implement, and perhaps document if they have time. But they will usually not document why they rejected and did not implement the N other possibilities they considered.
P2 then comes in thinking “Gee that sure would be convenient if the code had feature F, I can’t believe P1 didn’t think of that! How silly of them!”, not realizing that feature F was carefully considered and rejected, because if you implement it bad thing B happens. There’s your missing fence, never was built in the first place, and with good reasons.
the problem here is that sometimes the past programmer didn’t considered it all, and present-progeammer don’t have a way to distinguish between those possibilities. which is also the problem with the Fence, except in programming it’s easier to try, and roll back if you need to.
in the last place i worked, going by this heuristic would have been bad idea. the answer was mostly that they didn’t think about it, or that the code is old and you can use something better now, and should.