Taking a Fence Down
chesterton.org
chesterton.org
'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.'
>>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.<<
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."
Basically the point of the article is that you shouldn't act until you are able to distinguish between these two cases.
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 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???)
For those of you who are unfamiliar:
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:
What's the best Father Brown mystery? I've been meaning to try one for years.
Try also The Trees of Pride, which isn't a fr brown mystery but is quite a good mystery.
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.
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.
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.
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.)
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!
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-...
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.
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.
[EDIT] I posted the exact same Joel quote (only 2 paragraphs more of it) than some other has posted earlier. Reducted.
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.
In software jargon, I might also paraphrase it as "Never optimize before profiling."
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,
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.
"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.