
Taking a Fence Down - luu
http://www.chesterton.org/taking-a-fence-down/
======
sjackso
Chesterton reiterated similar ideas to this in several of his writings. I like
this expanded metaphor, from the book Heretics:

'Suppose that a great commotion arises in the street about something, let us
say a lamp-post, which many influential persons desire to pull down. A grey-
clad monk, who is the spirit of the Middle Ages, is approached upon the
matter, and begins to say, in the arid manner of the Schoolmen, "Let us first
of all consider, my brethren, the value of Light. If Light be in itself good—"
At this point he is somewhat excusably knocked down. All the people make a
rush for the lamp-post, the lamp-post is down in ten minutes, and they go
about congratulating each other on their unmediaeval practicality. But as
things go on they do not work out so easily. Some people have pulled the lamp-
post down because they wanted the electric light; some because they wanted old
iron; some because they wanted darkness, because their deeds were evil. Some
thought it not enough of a lamp-post, some too much; some acted because they
wanted to smash municipal machinery; some because they wanted to smash
something. And there is war in the night, no man knowing whom he strikes. So,
gradually and inevitably, to-day, to-morrow, or the next day, there comes back
the conviction that the monk was right after all, and that all depends on what
is the philosophy of Light. Only what we might have discussed under the gas-
lamp, we now must discuss in the dark.'

------
hn9780470248775
Reminds me of the old story of the onion in the varnish. As recounted by pg:

>>In The Periodic Table, Primo Levi tells a story that happened when he was
working in a varnish factory. He was a chemist, and he was fascinated by the
fact that the varnish recipe included a raw onion. What could it be for? No
one knew; it was just part of the recipe. So he investigated, and eventually
discovered that they had started throwing the onion in years ago to test the
temperature of the varnish: if it was hot enough, the onion would fry.<<

~~~
analog31
Another anecdote: A colleague of mine visited an aluminum casting plant, and
saw bags of potatoes sitting around. She asked what the potatoes were for. The
answer: They used to throw some sort of large pill into the aluminum, to get
rid of the bubbles, so the casting would be more solid. Then they heard that a
potato worked just as well.

------
cwyers
I love the parable of Chesterton's fence. And I feel it's very, very
applicable to a lot of discussion I see here on HN (I feel like the rhetoric
around Bitcoin vis a vis the current financial system could do with a good
infusion of Chesterton's fence, for example, as could NoSQL/NewSQL databases.)

~~~
neckro23
It's very applicable to software development in general. "Who wrote this crap?
I'm rewriting it!"

~~~
cwyers
Yeah, I'm reminded of Joel Spolsky's essay on Netscape and why rewriting from
scratch is a bad idea:

[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

"The idea that new code is better than old is patently absurd. Old code has
been used. It has been tested. Lots of bugs have been found, and they've been
fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting
around on your hard drive. Au contraire, baby! Is software supposed to be like
an old Dodge Dart, that rusts just sitting in the garage? Is software like a
teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to
display a window, but it has grown little hairs and stuff on it and nobody
knows why. Well, I'll tell you why: those are bug fixes. One of them fixes
that bug that Nancy had when she tried to install the thing on a computer that
didn't have Internet Explorer. Another one fixes that bug that occurs in low
memory conditions. Another one fixes that bug that occurred when the file is
on a floppy disk and the user yanks out the disk in the middle. That
LoadLibrary call is ugly but it makes the code work on old versions of Windows
95.

Each of these bugs took weeks of real-world usage before they were found. The
programmer might have spent a couple of days reproducing the bug in the lab
and fixing it. If it's like a lot of bugs, the fix might be one line of code,
or it might even be a couple of characters, but a lot of work and time went
into those two characters.

When you throw away code and start from scratch, you are throwing away all
that knowledge. All those collected bug fixes. Years of programming work."

~~~
chris_wot
I find what Joel says problematic - firstly, you touch that code and you might
break something, so it's fragile already, and secondly if it dealing with
corner cases, then it should be documented.

~~~
technomancy
Saying that it should be documented isn't going to do anything to change the
fact that it's not documented.

~~~
chris_wot
Words to live by.

------
jawns
Wow! I didn't expect to see something from Chesterton.org on the front page of
Hacker News.

For those of you who are unfamiliar:

[http://www.chesterton.org/who-is-this-guy/](http://www.chesterton.org/who-is-
this-guy/)

A bunch of G.K. Chesterton's books -- novels and nonfiction -- are in the
public domain and can be downloaded at:

[http://www.gutenberg.org/ebooks/author/80](http://www.gutenberg.org/ebooks/author/80)

~~~
dang
If we're going to talk Chesterton, _The Man Who Was Thursday_ is tremendous
fun, though I can't recommend it without an ethical dilemma nor say what the
dilemma is without spoiling the whole thing.

What's the best Father Brown mystery? I've been meaning to try one for years.

~~~
midnightmonster
I'm very curious to know what your ethical dilemma is. I've read the man who
was Thursday a couple times, and I'm having a hard time thinking what you
might find objectionable about it that isn't giving away pretty early in the
story or "spoiled" by a passing familiarity with Chesterton.

I don't see suitable contact info in your profile, but if you have a minute
I'd be glad to receive an email via the address in mine.

~~~
dang
Ok, I put it here:
[http://pastebin.com/1rGPcjZ4](http://pastebin.com/1rGPcjZ4). Anyone who is
curious and doesn't care about having a great plot spoiled can take a look.
Anyone who does, keep out! It really is one of the most audacious plots ever.

Re contact info, anyone who wants to contact me is welcome to email
hn@ycombinator.com. Suitability is the least of our worries. If it's a
personal conversation I'll just redirect to a personal address.

------
lexicality
While everything gets done for a reason, that reason isn't always sane. I'm on
the refactor tractor at the moment and "fuck it ship it" has a lot to answer
for in terms of unexpected and unwanted fences.

~~~
cwyers
That's absolutely true. Sometimes the reason is wrong, in which case it
shouldn't have been done that way. The point of Chesterton's fence isn't that
everything gets done for a reason and therefore should be left alone, it's
that everything gets done for a reason and you can't evaluate whether or not
that reason was correct if you don't know that reason.

~~~
lexicality
Which is why you should try to make sure people know your reasons when making
decisions in the first place. Someone once said "write your commit messages as
if they're going to be read by a maniac with a machete who knows where you
live" (I forget who.) Some days after a particularly intensive git blame
session that moves through multiple refactors and terminates in a commit
message like "fix stuff lol" I feel like buying a machete and breaking into
the employee database.

------
cpr
GKC is little-remembered today among the general public, but when he died in
1936, all of England mourned.

An incredible and gifted man, and a paradox himself. (The paradox was his
favorite writing tool; it makes extended reading of his non-fiction a bit
tiring, but it's worth it.)

------
gojomo
Sometimes understanding the original purpose of the fence can make you more
confident it's now OK to come down, because the same protections are available
in better ways.

Taxi regulations made a bunch of sense when:

* rates were hard to discover

* distances/routes were hard for a customer to evaluate

* after each transaction, every car/driver disappeared into an undifferentiated fleet

* getting in a random car meant at least a _tiny_ chance you could be abducted/victimized, with no record of your assailant or last-known location

Handheld internet/GPS devices, and dispatching/payment via a network service
with persistent reputations, solve all these better than the old regulations.
So tear down that fence!

~~~
thanatropism
So what happens when my Uber driver/kidnapper turns off the GPS as he finds
out I'm famous/wealthy?

~~~
gojomo
Your phone has GPS. To be matched at all, Uber had to know both the driver and
you, with some mixture of identification/credit/payment information. They
relayed your request to just one specific driver, for a pick-up in a specific
location. Even if the driver immediately cancels and goes rogue, that's a
better record of your-last-known-contact than any other transport system.

Uber relays to you a photo of the driver and the make/color/license-plate of
their car – so anyone who pays a little attention won't get in any unvetted
cars. The driver gets your chosen alias as another lightweight mutual
authentication step – when they call you by that name, they've proven they're
in the system.

Taxis still offer none of this. The only check before getting in is, "does it
look like a city taxi?" Only flimsy pieces of paper, stuck inside the vehicle,
tell anything more about the driver. Turns out, these paint-job and paperwork
signals-of-authenticity have historically been easy to fake:
[http://missionlocal.org/2009/05/mta-poised-to-crack-down-
on-...](http://missionlocal.org/2009/05/mta-poised-to-crack-down-on-
unlicensed-taxis/)

------
MaysonL
One should probably also consider this, from Robert Frost's poem "Mending
Wall":

 _Before I built a wall I’d ask to know

What I was walling in or walling out,

And to whom I was like to give offence.

Something there is that doesn’t love a wall,

That wants it down._

------
legulere
This is quite the antithesis to the experiment with the five monkeys and the
ladder:
[http://i.stack.imgur.com/MyQki.jpg](http://i.stack.imgur.com/MyQki.jpg)

Often it's not possible to find out the reasons and in the end you will end up
with lots of useless stuff.

how can we get away from both bad sides? Document why you are doing what.

------
beat
I'll see your fence and raise you a Lava Flow Antipattern...

[http://www.antipatterns.com/lavaflow.htm](http://www.antipatterns.com/lavaflow.htm)

------
fanglewitte
Things like fences and traditions and biological organs persist in the world
for _multiple_ reasons, even where they were created for spurious ones. We can
never be sure what they all are. Hence piecemeal change essential.

------
siliconc0w
On the flip side, sometimes the only way to learn why the fence was there is
to take it down and see what happens. Otherwise you live in a world of old
rusting fences everyone is afraid to take down.

------
lmm
But sometimes there was no reason. Sometimes someone built a fence just
because, in the dead of night, and told no-one about it. Must we leave such
fences to stand forever?

------
coldtea
Related text:

[EDIT] I posted the exact same Joel quote (only 2 paragraphs more of it) than
some other has posted earlier. Reducted.

------
autokad
is this the same as: "if its not broken, don't fix it"?

~~~
CocaKoala
No; "If it's not broken, don't fix it" boils down to that if something is
acceptable, you shouldn't spend time or energy messing with it.

This is more along the lines of "Not understanding the purpose of something
does not mean that it doesn't have a purpose". If you don't know why the fence
is there, don't take it down; it could be doing something you don't know, and
taking it down would destroy some existing relationship that you were unaware
of. If you can thoroughly explain why the fence exists, why it was put there,
then you can think through the ramifications of removing it and make sure that
whatever solution you implement in place of the fence will fulfill the same
functionality.

~~~
logfromblammo
I disagree. This is a form of "Not broken; don't fix." Though I'd probably
classify it more as a corollary, or the pseudo-contrapositive, "If it has been
fixed, don't re-break it."

In software jargon, I might also paraphrase it as "Never optimize before
profiling."

~~~
nucleardog
You're already thinking too far ahead in the process.

This isn't about what to do with a problem - this is just saying that if you
wish to fix things rather than break more things, you need to understand the
system before changing it.

It starts:

    
    
      In the matter of reforming things, as distinct from deforming them,
    

Drawing an explicit distinction between re-forming and de-forming, I'd
interpret reforming as meaning 'changing in an attempt to make better'.

And it ends:

    
    
      Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
    

It doesn't say "Then when you can come back and tell me you see the use, and
it's wrong, you can destroy it.". It says you "may be allowed to destroy it"
\- that once you understand the system, then we can begin discussing changes.

"If you want to make a system better, you must understand it before changing
it."

Or, to put it back into software... You're talking about how to deal with a
bug in the code. Chesterton is saying that if you're trying to build a better
application, you have to understand what the application is even trying
accomplish at a high level before you can begin writing code.

