4 ms·

Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence reforms should not be made until

Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence reforms should not be made until the reasoning behind the existing state of affairs is understood

stellar_rocket 5y ago
The Chesterton Fence AKA an undocumented obstacle from the perspective of anyone new. Of course we need to understand the system before changing it. But we shouldn't browbeat those wanting to improve the stuff we left no guidance about.
SpaghettiX 5y ago
What's the difference between this and "don't change things you don't understand". It would make it clearer that this is a type of approach rather than a law. Sometimes, that legacy system or class is replaced without fully understanding it, because it's cheaper to reimplement it's interface than fix it.
- yxhuvud 5y ago
  What happens then though, is that the replacement take a lot longer than expected, because it turns out that the complexity in the old system had more motivation than expected and had a lot more problems it solved than was obvious. Fixing these issues then make the new system into almost as big of a problem as the old one, with the only difference in that now you at least have some people that understands it. For a while until enough people have left to again forget the workings of the system. Sometimes the easiest way for a company to relearn about a problem space is to rewrite it though, so it is not necessarily a bad thing to do. It can also be that the market has shifted and some of the complexity in the old system was no longer necessary, so the new system ends up easier. In any case, spending time understanding the existing system (including developers that point out corner cases and nonobvious cases) make the end result so much easier than adjusting a solution to handle a complication angle that wasn't part of the original plan.
- hyperpallium2 5y ago
  > reimplement it's interface Implicitly assumes we know what that interface is (and this assumes that that "interface" really does include all the relevant interactions - this is, the literal interface between systems). If we really did know this true interface, the implementation is absolutely irrelevant. In practice, all abstractions are leaky, and it's routinely simpler to look at the source to work out what it does. This covers the gamut of interactions, from minor undocumented API details, to complex semamtocs of corner cases, to time/space/resource usage patterns.

stellar_rocket 5y ago

The Chesterton Fence AKA an undocumented obstacle from the perspective of anyone new. Of course we need to understand the system before changing it. But we shouldn't browbeat those wanting to improve the stuff we left no guidance about.

SpaghettiX 5y ago

What's the difference between this and "don't change things you don't understand". It would make it clearer that this is a type of approach rather than a law. Sometimes, that legacy system or class is replaced without fully understanding it, because it's cheaper to reimplement it's interface than fix it.

yxhuvud 5y ago
What happens then though, is that the replacement take a lot longer than expected, because it turns out that the complexity in the old system had more motivation than expected and had a lot more problems it solved than was obvious. Fixing these issues then make the new system into almost as big of a problem as the old one, with the only difference in that now you at least have some people that understands it. For a while until enough people have left to again forget the workings of the system. Sometimes the easiest way for a company to relearn about a problem space is to rewrite it though, so it is not necessarily a bad thing to do. It can also be that the market has shifted and some of the complexity in the old system was no longer necessary, so the new system ends up easier. In any case, spending time understanding the existing system (including developers that point out corner cases and nonobvious cases) make the end result so much easier than adjusting a solution to handle a complication angle that wasn't part of the original plan.
hyperpallium2 5y ago
> reimplement it's interface Implicitly assumes we know what that interface is (and this assumes that that "interface" really does include all the relevant interactions - this is, the literal interface between systems). If we really did know this true interface, the implementation is absolutely irrelevant. In practice, all abstractions are leaky, and it's routinely simpler to look at the source to work out what it does. This covers the gamut of interactions, from minor undocumented API details, to complex semamtocs of corner cases, to time/space/resource usage patterns.