3 ms·

Fascinating, can you give a couple examples of pre-existing rationale that make it impossible to replace an unneeded fence?

haswell 3y ago
Not OP, but I’ve encountered this in situations where legacy code involved in mission critical business functionality was nearly impossible to remove due to the potential risk of unforeseen impact. In other words, if the potential impact of an unforeseen breakage is high enough (costs us or the customer $$$), it’s not worth risking the change even if we can find absolutely no good reason for the current behavior to exist. Example: complex spaghetti that touches billing calculations. These things are better addressed by a full rewrite/redesign followed by a long period of running both things in parallel until we’re confident that we didn’t miss anything. Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.
- paulsutter 3y ago
  Sounds like you did the right thing by not changing the code! The rule worked What would have been the advantage, in this situation, to ignoring the rule? What problem here is the Chestertons Fence rule causing? EDIT: (responding to below, your issue has nothing whatsoever to do with Chestertons Fence. Making careful code changes to test then effect of removal is a great way to apply the rule. Building a separate system and testing in parallel would be an even cooler way to apply the rule)
  - haswell 3y ago
    The benefit of rearchitecting the code would have been high. As it stood, the status quo was blocking progress on other initiatives and making it difficult to meet the needs of customers. If we had ignored the fence and nothing broke, we could have immediately made major improvements that our customers had been begging us for. The reality is that we don’t know if it worked. It’s possible that our conclusion that this had no reason to exist as written was accurate, and that doing nothing didn’t actually prevent anything bad from happening. It’s also possible that we saved ourselves from something we didn’t understand. I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it. Edit: I can't really respond to your response in its current form without these comments getting really difficult to understand. I disagree that this has nothing to do with Chesterson's fence. It's essentially a failure mode that can occur when applying the ideas behind the principle, i.e. there are times when learning everything we can about a barrier and believing with a high degree of confidence that the barrier isn't needed still isn't enough to remove it due to other factors. This points to the fact that this is a guideline, not a law.
    - funcDropShadow 3y ago
      > I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it. I don't understand this. Implementing billing from scratch and running it in parallel to the old code is a form of doing due diligence. I.e. it is an application of Chesterton's fence. It might be an expensive application but it is one. To me, this anecdote shows the value of documenting the why of software. I've read some time ago, to add code to systems such that, it is simple to remove it again. This discussion deepened that insight for me. This is preparing for Chesterton's fence.
      - haswell 3y ago
        > it is an application of Chesterton's fence That's why I closed with: > Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on. In other words, it's still learning from the cautionary tale of the fence, but the end result isn't a classic removal or non-removal of the fence itself. And it's not as if the idea has hard and fast rules :) I agree regarding the value of documentation. None of us involved in the project were at the company when the code was written, and so we were left with a dangerous task.
  - deleted 3y ago
    [deleted]

haswell 3y ago

Not OP, but I’ve encountered this in situations where legacy code involved in mission critical business functionality was nearly impossible to remove due to the potential risk of unforeseen impact. In other words, if the potential impact of an unforeseen breakage is high enough (costs us or the customer $$$), it’s not worth risking the change even if we can find absolutely no good reason for the current behavior to exist. Example: complex spaghetti that touches billing calculations. These things are better addressed by a full rewrite/redesign followed by a long period of running both things in parallel until we’re confident that we didn’t miss anything. Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.

paulsutter 3y ago
Sounds like you did the right thing by not changing the code! The rule worked What would have been the advantage, in this situation, to ignoring the rule? What problem here is the Chestertons Fence rule causing? EDIT: (responding to below, your issue has nothing whatsoever to do with Chestertons Fence. Making careful code changes to test then effect of removal is a great way to apply the rule. Building a separate system and testing in parallel would be an even cooler way to apply the rule)
- haswell 3y ago
  The benefit of rearchitecting the code would have been high. As it stood, the status quo was blocking progress on other initiatives and making it difficult to meet the needs of customers. If we had ignored the fence and nothing broke, we could have immediately made major improvements that our customers had been begging us for. The reality is that we don’t know if it worked. It’s possible that our conclusion that this had no reason to exist as written was accurate, and that doing nothing didn’t actually prevent anything bad from happening. It’s also possible that we saved ourselves from something we didn’t understand. I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it. Edit: I can't really respond to your response in its current form without these comments getting really difficult to understand. I disagree that this has nothing to do with Chesterson's fence. It's essentially a failure mode that can occur when applying the ideas behind the principle, i.e. there are times when learning everything we can about a barrier and believing with a high degree of confidence that the barrier isn't needed still isn't enough to remove it due to other factors. This points to the fact that this is a guideline, not a law.
  - funcDropShadow 3y ago
    > I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it. I don't understand this. Implementing billing from scratch and running it in parallel to the old code is a form of doing due diligence. I.e. it is an application of Chesterton's fence. It might be an expensive application but it is one. To me, this anecdote shows the value of documenting the why of software. I've read some time ago, to add code to systems such that, it is simple to remove it again. This discussion deepened that insight for me. This is preparing for Chesterton's fence.
    - haswell 3y ago
      > it is an application of Chesterton's fence That's why I closed with: > Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on. In other words, it's still learning from the cautionary tale of the fence, but the end result isn't a classic removal or non-removal of the fence itself. And it's not as if the idea has hard and fast rules :) I agree regarding the value of documentation. None of us involved in the project were at the company when the code was written, and so we were left with a dangerous task.
- deleted 3y ago
  [deleted]