3 ms·

There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare ed

There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare edge case and you just don't see how, yet.

brazzy 2y ago
That as well is "not doing the right thing", namely adding a comment that explains the need for it.
kqr 2y ago
The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.
- MrJohz 2y ago
  The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)
npsimons 2y ago
> you just don't see how Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).
- YZF 2y ago
  I would soften this to always consider that possibility. The probability that something is just wrong, or the requirements have evolved in a way that makes it wrong, is probably not that different than the probability the original author had a very strong reason for doing something a certain way and that really did survive the test of time. Considering everything preexisting to be perfect is overly conservative and almost certainly wrong in most real world software engineering scenarios. The history of software engineering is full of examples of things that got replaced with much better things because the original was just not good enough.

brazzy 2y ago

That as well is "not doing the right thing", namely adding a comment that explains the need for it.

kqr 2y ago

The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.

MrJohz 2y ago
The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)

npsimons 2y ago

> you just don't see how Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).

YZF 2y ago
I would soften this to always consider that possibility. The probability that something is just wrong, or the requirements have evolved in a way that makes it wrong, is probably not that different than the probability the original author had a very strong reason for doing something a certain way and that really did survive the test of time. Considering everything preexisting to be perfect is overly conservative and almost certainly wrong in most real world software engineering scenarios. The history of software engineering is full of examples of things that got replaced with much better things because the original was just not good enough.