6 ms·
Reliable rule, and not just for software. Seems like a good place for mentioning 'Chesterton's Fence'.... In the matter of reforming things, as distinct from d
by pjmorris 9y ago
Reliable rule, and not just for software. Seems like a good place for mentioning 'Chesterton's Fence'....
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
- msla 9y agoSometimes, a thing is there because it's there, and nobody knows the original purpose, so by Chesterton, nobody would be able to tear it down, because nobody can see the use of it. Chesterton's Fence neatly saves the utterly pointless fences in our lives, regardless of the damage they can cause.
- brianpan 9y agoIt's a principle, not an unbreakable rule. The point is to take some time for the due diligence of understanding why. Fences (or laws or code) don't just appear out of nowhere. Someone spent time and energy to put it there. If you don't immediately see its use, you should do some more thinking/archeology.
- bluGill 9y agoHow many bad situations have been prevented though? I've seen many situations where someone did try to remove something pointless that really wasn't pointless.
- Cyranix 9y agoI think your conclusion is a result of oversimplifying the concept of Chesterton's Fence. The idea can be restated as "Don't remove what you don't understand", but that doesn't imply "This thing is impossible to understand and may never be removed". A lack of understanding at a point in time doesn't imply a permanent inability to understand. Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).
- bsder 9y agoA fence also requires maintenance. An intact fence means someone wants the fence bad enough to put it there and maintain it. IPv6 designs are only similar to the first half of that statement. If it's in IPv6, it's because someone wanted it there. The people designing IPv6 had almost 2 decades of operational experience running IPv4 to draw from. Things were intentional.