4 ms·

"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood." In the matter of

by brador 10y ago

"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood." 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."[1] Source - Wikipedia.

crazygringo 10y ago
Chesterton's Fence is a great example of why code comments are critical. If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there. "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.
- btschaegg 10y ago
  A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand the problem it's trying to solve. In my experience, that part is usually much easier, since you're working in hindsight. There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in a) understanding what a specific piece of code is supposed to do and b) rewriting it so it actually would do it properly. Of course there's much to be said on when this approach is overkill and when it isn't. [1]: https://en.m.wikipedia.org/wiki/Coders_at_work https://en.m.wikipedia.org/wiki/Coders_at_work
- Can_Not 10y ago
  > "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.

by brador 10y ago

crazygringo 10y ago

Chesterton's Fence is a great example of why code comments are critical. If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there. "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.

btschaegg 10y ago
A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand the problem it's trying to solve. In my experience, that part is usually much easier, since you're working in hindsight. There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in a) understanding what a specific piece of code is supposed to do and b) rewriting it so it actually would do it properly. Of course there's much to be said on when this approach is overkill and when it isn't. [1]: https://en.m.wikipedia.org/wiki/Coders_at_work https://en.m.wikipedia.org/wiki/Coders_at_work
Can_Not 10y ago
> "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.