Chesterton's Fence is always worth keeping in mind when maintaining code too.
Sometimes you'll come across some crazy nested conditional that seems to be checking for cases that can't even happen. It's tempting to say "this is nuts, I'll just rewrite this whole overgrown method into two lines!". Sometimes that's even a good idea. But some programmer before you thought that crazy code was worth writing, and you might want to check `git blame` and see if you can figure out why.
Example: A while back I ran across a pretty rare race condition in some pretty gnarly distributed code. But there was an obvious fix, so I opened up the file where the fix should be made and found...
...someone else already had made that fix. Except it was in a conditional block which boiled down to "if (false) {...}". The fix would never run! No matter, it would be the work of 10 seconds for me to fix the conditional and push this code to production.
But first, I checked the logs. One of my colleagues had written this code (so that the fix would run) about two years ago. And then 20 minutes later he had committed a hotfix to stop the code running. Reading between the lines, the "obvious fix" clearly broke something less obvious and even more important somewhere else in the gnarly distributed code. That "broken" conditional wasn't a bug, it was a fence, and it had been erected for a good reason. And the race condition I found was really rare, and the whole gnarly distributed code is slated to be refactored next year, so...I left it.
(Now, the lack of comments explaining all that in the code base, and the fact the broken code was still in the code base just locked behind an always false conditional...those were issues. Then again, stuff like that happens in real code bases, even if they shouldn't. If you expect live to be completely tidy and well behaved, reality is going to be really confusing sometimes.)
"Put very simply: don’t destroy what you don’t understand."
The Chesterton's Fence story has always bothered me. The moral puts all blame on the person challenging the fence for not coming to the same conclusions as the builder.
For the person building the fence, it's easy to assume that the purpose of your work is self-evident, but the truth is that it is hard for anyone else to put together the facts as you saw them, and it's harder still to reason the same way you did. So just thinking really hard about the reasons for the fence's existence will not necessarily lead to a correct -- or even desirable -- result. The story's moral may as well have been: "What I did is more important than what you want to do." Or: "Fear change."
I'd rather see a dual lesson drawn from the same story: "If what you are doing is important, it's just as important to make it clear why it is important."
This particularly applies in the context of software development, when a little effort to make the rationale of some code more clear can pay off over the dozens to hundreds of times the code must be read and rejustified.
It doesn't put any blame on anyone. It encourages us to stop and think in such a way that there is no blame for anyone. (Typically, the people who built the fence are not here any more, so we can't make any more requirements on them, only on ourselves.)
Responsibility is not the same as blame. Blame could only be assigned for the consequences of dismantling the fence - which could be good or bad depending on the actual outcomes.
Responsibility is about the manner in which decisions are made. We should always be a little cautious about change for the same reason that we look both ways before crossing the road.
* the machine that depends on the data was brought into service before you were born
* the programmer who wrote the original software in VB died of cancer--10 years ago
* the first machine operator who spec'd out the software retired--after a long and full career
But you, having been here 6 whole months, decide that it's time to move this folder because it's stupid that it's not with all of the other similar files?
Thus: Steve's Rule of Enterprise Systems: if you yourself don't fully understand why it is the way it is, don't touch it.
This article presents a thoughtful topic worth considering...
...too bad that it seems wrapped around (imho) making a case for bigotry against same-sex marriage (and seemingly presenting it from a Mormon perspective).
Do I agree with the idea that one should "look before you leap"? Certainly; maybe the old process had a purpose and should be kept.
But not when it is to the detriment or isolation of a particular class or group of people (especially on seemingly pure quasi-religious grounds).
I've always had a problem with Chesterton's Fence precisely because it is a sort of status quo bias that can be (and is) used as an argument in favor of backwards social norms and traditions. It's one thing to say "Don't touch that piece of code you don't understand." It's totally different to apply that line of reasoning to norms and laws that actively hurt people. Sometimes there's a reason for the way things are and the reason is just plain stupid and cruel.
The fact that you think the reasoning behind traditional marriage is "just plain stupid and cruel" is probably the best example of Chesterton's Gate I've yet seen. It indicates that (a) not only do you not understand the reasoning, but (b) our society has changed so much, and so subtly, that it's almost impossible to get anyone to understand that reasoning. Needless to say, I don't think this bodes well for us over the long-term.
(Ducking all the incoming downvotes - I'm keenly aware of how unpopular this position is, and how bigoted it seems to most folks these days - which sort of proves my point.)
The other possibility that you seem to implicitly dismiss is that the original reasoning is understood perfectly well, has been debated to death, and has been found to no longer align with what the majority of people want out of society.
Chesterton's Gate argues against removing the fence out of haste and ignorance, but not against removing it after intense debate and careful consideration.
And yet somehow, within a decade, we've redefined (almost out of existence) the single most fundamental human institution, an institution which has lasted for thousands of years and which virtually every great thinker prior to the last 15 years has understood as the prerequisite and foundation for any civilized society. This radical redefinition of marriage - and in its wake, of what it means to be human - couldn't have happened without incessant propagandizing and cheerleading from every element inside our popular and our news media. And yet how often did you hear this media allow through a coherent statement of the views opposing SSM, as expressed by, say, Ryan Anderson? How often was debate shut down a priori, as mere bigotry?
Careful reconsideration? I don't see how that played any part of this recent shift.
"It’s not entirely that simple. Both societies seek to solve the same fundamental problem — to assure that all children arriving will be cared for. Betans make the choice to do it directly, technologically, by mandating a biochemical padlock on everyone’s gonads. Sexual behavior seems open at the price of absolute social control on its reproductive consequences. Has it never crossed your mind to wonder how that is enforced? It should. Now, Beta can control one’s ovaries; Barrayar, especially during the Time of Isolation, was forced to try to control the entire woman attached to them. Throw in Barrayar’s need to increase its population to survive, at least as pressing as Beta’s to limit its to the same end, and your peculiar gender-biased inheritance laws, and, well, here we all are."
- Lois McMaster Bujold, "A Civil Campaign"
We just happen to be living in a society that's in the middle of its way from point A to point B.
Society has changed hugely due to two key innovations, one physical, one social: contraception and consent. From those all else follows.
People kept trying to explain their reasoning against same-sex marriage but failed, which almost everyone sensible takes to mean that line of reasoning is now invalid. I never heard an argument against it that was even coherent, other than the pure theological command ones.
Can you lay out how everything else follows, or how consent is a recent innovation? Neither is not obvious to me.
The line of reasoning I've heard is that intersex marriages produce families, which societies value.
Same-sex marriages do not produce children, as a simple result of biology. I don't deny that a same-sex marriage can form an effective family through adoption or surrogates, nor that an intersex marriage can fail to produce children, but the default result is children in intersex marriages and no children in same-sex marriages.
If society wants to encourage children and families (for obvious reasons), one simple route is to encourage intersex marriage. Same-sex marriage is, in this supposed society, 'discriminated against' because it doesn't produce the same result as intersex marriage, in the same way that you can't marry yourself, or 'donate' your income to buy a new car for yourself instead of to a charity and expect a tax break, or spend your retirement savings tax-free before retirement.
I also don't deny that this simple route of encouraging the raising of children by encouraging intersex marriage isn't perfect, and the imperfections cause harm. But it's kind of baked into our culture and legal system. Suggestions that simply extend the encouragement to same-sex marriages to eliminate the harm without fixing the encouragement are also incoherent, failing to see the reasoning for the fence. I wish you good luck if you want to take away the benefits from childless intersex marriages, or not extend them to childless same-sex marriages. And a lot of the noise around the issue is based on emotional, theological or incoherent reasoning, which makes sensible communication difficult.
Consent as recent innovation: until horrifyingly recently (1986 in the UK, similar dates around the West), there was no legal concept of rape within marriage. Consent was a one-shot deal on your wedding day for the rest of your life. Going a bit further back, it was only in the mid-20th century that the law stopped supporting husbands from physically retrieving fleeing wives. Divorce - the withdrawal of consent from a domestic situation - is really a 20th century innovation. And back before the 20th century, wives could not own property. Marriage is already quite literally not what it used to be.
Following from contraception: the focus on marriage in history as the only legitimate form of sex was "about" prevention of children, not encouragement. Often achieved with considerable brutality towards women who produced children outside of marriage (Magdalene Laundries passim).
Marriage has changed in the 20th century as a recognition of the equal rights of women as individual human beings. It has further changed in the 21st as we recognize that homosexuality does not disqualify people from equal treatment as human beings either.
What does same-sex marriage have to do with the article? Yes, you can apply "Chesterton’s Fence" to the question of marriage law, and then decide that the justification (Mormon or otherwise) for banning same-sex marriage are not convincing. For example, you may decide that our modern nation does not need to compel everyone to reproduce as quickly as possible, so there is no need to ban non-reproductive marriages.
> What does same-sex marriage have to do with the article?
Read the article again; toward the end it discusses this. It'd be one thing if I brought it up and it wasn't talked about in the article - but it clearly is discussed...?
Did the link quietly change? Based on this thread and a google cache link in https://news.ycombinator.com/item?id=13065097 it looks like the original link was to an article in ldsmag.com, but now points to a post at abovethelaw.com.
Other than referring to Chesterton's Fence, they don't really intersect.
It's also possible that whoever posted the cache link accidentally copied the wrong URL from the Google results page. The title of the abovethelaw.com article matches the title of this HN story ("The Fallacy of Chesterton's Fence"), but the cache link points to an article entitled "The Parable of Chesterton’s Fence".
(From what I've observed, when the moderators change a story's link, they always add a comment saying they've done so - so that doesn't seem to be what happened here.)
I'm not sure why the article refers to Chesterton's fence as a fallacy when it basically agrees with the principle that you shouldn't blindly push reforms without understanding the reasoning behind the existing state of things.
That's not to say I disagree with the content of the article. I think it presents a good approach to promoting improvements to processes, the key takeaways being:
1) Observe the process and try to understand all aspects of it (not just that which affects you).
2) If you still feel that it can be improved, come up with a plan to improve and implement the process in a limited scope over which you have control.
3) If successful, break down why it was successful, and evaluate whether it is suitable to be expanded to the general case.
4) Find the owner of the existing process to discuss it with them, and present your proposed improvements.
I think there's an argument to be made that you should talk to the owner of the process before you start coming up with improvements, which could save some time on understanding it. But I suppose that depends on the situation.
It's referring to the "I don't see the use of it, let's remove it" part as a fallacy, and agreeing with the "no, come back after you see the use of it" part.
Sometimes you'll come across some crazy nested conditional that seems to be checking for cases that can't even happen. It's tempting to say "this is nuts, I'll just rewrite this whole overgrown method into two lines!". Sometimes that's even a good idea. But some programmer before you thought that crazy code was worth writing, and you might want to check `git blame` and see if you can figure out why.
Example: A while back I ran across a pretty rare race condition in some pretty gnarly distributed code. But there was an obvious fix, so I opened up the file where the fix should be made and found...
...someone else already had made that fix. Except it was in a conditional block which boiled down to "if (false) {...}". The fix would never run! No matter, it would be the work of 10 seconds for me to fix the conditional and push this code to production.
But first, I checked the logs. One of my colleagues had written this code (so that the fix would run) about two years ago. And then 20 minutes later he had committed a hotfix to stop the code running. Reading between the lines, the "obvious fix" clearly broke something less obvious and even more important somewhere else in the gnarly distributed code. That "broken" conditional wasn't a bug, it was a fence, and it had been erected for a good reason. And the race condition I found was really rare, and the whole gnarly distributed code is slated to be refactored next year, so...I left it.
(Now, the lack of comments explaining all that in the code base, and the fact the broken code was still in the code base just locked behind an always false conditional...those were issues. Then again, stuff like that happens in real code bases, even if they shouldn't. If you expect live to be completely tidy and well behaved, reality is going to be really confusing sometimes.)