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.'
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.<<
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.
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.)
"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."
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.
This accurately catches the reasoning behind my approach to testing though. When you fix a bug, write a test that reproduces the bug first. That way, when someone tries to refactor the messy code, they'll know that they broke something that was causing a real big.
I generally try to have two type of test: nominal "happy case" tests that verify basic functionality of modules when used in a normal way, and bug fix tests that are labelled as such, with a reference to the bug in the bug tracking system. So now when you see my warty code and try to clean it, the test fails, and you can even find a description of the original problem that the warty code addresses. Now you know that you either have to find a cleaner solution, or just leave the warty code alone.
This system means that most of the tests I write are targeted at things that really cause bugs, not just busy-work testing of things that would never go wrong, but rigidify code bases (the more tests you have, the more you have to modify when refactoring, and how do you know if the test or the code is wrong during the refactor???)
Should be an the real world do oftentimes just not match.
Clearly these cases should be clearly marked, but how often do you encounter these undocumented remnants of lost institutional knowledge. What Chesterton would imply here is to try to understand what these do and after doing so maybe deciding on a better way - even, if this means just documenting the stuff.
I feel like there's also a lesson here on the importance of commenting. If all of those inexplicable hairs had been properly commented, you wouldn't have to wonder.
On that note though if you compare the old code to say a water pipe, the old code could be a pipe with tons of duct-tape over every leak and a new pipe could in fact be a good choice. It's not always a great idea to rewrite from scratch but it isn't always the best to keep old code around either.
I have many favorite Chesterton quotes and could recommend at least half of what he's written, but this is probably my favorite because it is completely inverse to how we treat ourselves and the people and places around us.
Let us suppose we are confronted with a desperate thing-- say Pimlico. If we think what is really best for Pimlico we shall find the thread of thought leads to the throne or the mystic and the arbitrary. It is not enough for a man to disapprove of Pimlico: in that case he will merely cut his throat or move to Chelsea. Nor, certainly, is it enough for a man to approve of Pimlico: for then it will remain Pimlico, which would be awful. The only way out of it seems to be for somebody to love Pimlico: to love it with a transcendental tie and without any earthly reason. If there arose a man who loved Pimlico, then Pimlico would rise into ivory towers and golden pinnacles; Pimlico would attire herself as a woman does when she is loved. For decoration is not given to hide horrible things: but to decorate things already adorable. A mother does not give her child a blue bow because he is so ugly without it. A lover does not give a girl a necklace to hide her neck. If men loved Pimlico as mothers love children, arbitrarily, because it is THEIRS, Pimlico in a year or two might be fairer than Florence. Some readers will say that this is a mere fantasy. I answer that this is the actual history of mankind. This, as a fact, is how cities did grow great. Go back to the darkest roots of civilization and you will find them knotted round some sacred stone or encircling some sacred well. People first paid honour to a spot and afterwards gained glory for it. Men did not love Rome because she was great. She was great because they had loved her.
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.
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.
Ok, I put it here: 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.
The father brown mysteries are (afaik) all short stories, now available in collections. Blue Cross is excellent and also introduces two characters besides father brown who have arcs over some of the other stories.
Try also The Trees of Pride, which isn't a fr brown mystery but is quite a good mystery.
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.
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.
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.
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.)
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!
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-...
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.
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.
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?
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.
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."
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.
Not particularly. This is more about unexpected/unintended consequences following from changing something you don't fully understand. The thing you want to change may very well be broken, but if you try to fix it without understanding why it was put there in the first place, you may not fix your problem — or, worse, may un-fix the original problem.
'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.'