
The Fallacy of Chesterton’s Fence (2014) - Tomte
http://abovethelaw.com/2014/01/the-fallacy-of-chestertons-fence/
======
Lazare
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.)

------
jcl
"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.

~~~
MikeTaylor
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.)

------
steve444
Ahh, yes:

* 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.

~~~
gohrt
Steve's Corollary of Enterprise Systems: Don't touch anything ever.

------
cr0sh
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).

~~~
careersuicide
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.

~~~
smithkl42
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.)

~~~
Jordrok
You're right, society has changed quite a bit.

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.

~~~
smithkl42
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.

------
tantalor
[http://webcache.googleusercontent.com/search?q=cache:Xgy2VV9...](http://webcache.googleusercontent.com/search?q=cache:Xgy2VV99lwYJ:ldsmag.com/the-
parable-of-chestertons-fence/&num=1&hl=en&gl=us&strip=0&vwsrc=0)

~~~
LeifCarrotson
This is not the same article linked in the post. You linked to

[http://ldsmag.com/the-parable-of-chestertons-fence/](http://ldsmag.com/the-
parable-of-chestertons-fence/)

But the primary link is to

[http://abovethelaw.com/2014/01/the-fallacy-of-chestertons-
fe...](http://abovethelaw.com/2014/01/the-fallacy-of-chestertons-fence/)

Neither currently seem to require a cache link.

~~~
tantalor
At the time, the primary link was ldsmag.com, and did not work.

------
ColinCochrane
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.

~~~
kej
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.

