David Curran pointed out the following parable from G. K. Chesterton in reply to something I’d said on Google+. Though Chesterton had other things in mind, Curran pointed out that the quote applies to software maintenance.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
This paradox rests on the most elementary common sense. The gate or fence did not grow there. … Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious. There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. … If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, that they have since become bad purposes, or that they are purposes which are no longer served.
10 thoughts on “Software fences”
Reading Chesterton is endlessly wonderful. I don’t think there has ever been another English writer with a comparable combination of insight and wit.
Among his novels, my favorite is Manalive. I mention that only because it seems to be quite obscure, relative to things like The Man Who Was Thursday and The Napoleon of Notting Hill.
Back to the original topic, I am somewhat reminded of the scene from The Hitchhiker’s Guide to the Galaxy:
Arthur Dent: “I wonder what happens if I press this button here…”
Ford Prefect: “Don’t!”
Arthur Dent: “Oh.”
Ford Prefect: “What happened?”
Arthur Dent: “A little lamp lit up, saying ‘Please do not press this button again.’ “
Clearly, the fence builder should have practiced a bit of documentation: “Warning: Lion Habitat”
I like the parable, but I am mindful of it’s weakness: Sometimes the purpose for which a fence was built no longer exists, no one remembers what it was in the first place, and we cannot rediscover it. When told that after much thought, we still have no idea what the purpose is, what does the second reformer say?
There’s a little practical distinction between assuming that the actions of our predecessors were wise, and just blindly following them. If we offer too much deference to precedent, then we will bind ourselves into a particularly unimaginative existence – and perpetuate every error and accident that we can’t immediately identify as such.
From my point of view, this is describing the sort of paralyzing state that software can get into when you do not have tests to exercise all of its features.
Note that you do not need complete or thorough tests of any of the features. You just need enough of a test to be able to tell when the feature is missing, and perhaps to give you some illustrative data so you can know how to read the code.
Mark Dominus made an analogous point about analyzing another’s work. I call it Dominus’s Razor (in allusion to Hanlon’s Razor): Never attribute to complete stupidity what can adequately be explained by ordinary stupidity and a good reason.
Back at Dell in the late 80s, I was part of the BIOS team, which was very small at the time. We took a core BIOS from Phoenix Technologies and made lots of changes to accommodate our machines. Near the beginning of the bootup code, there was a JMP instruction to the next address, which serves as kind of a slow NOP. The comment beside the instruction was “someone thinks we should delay here”, but no one at the company knew what the purpose of the delay was. Every single developer who looked at that line was tempted to remove it. None were brave enough to do it.
That sounds like onions in the varnish. Paul Graham explains this as “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://paulgraham.com/arcll1.html
There are loads of these in modern software. Checks and delays and optimizations that made sense at the time but the reasoning has since been lost
My company is a fierce, Chesterton-reading team of consultants and we really think we are better for it. We get to read a lot of funny things, too!
I’m with IJ Kennedy: The correct answer is to test WHY the thing is there. If no use can be fine, one should remove it on a test system and see what happens. (Unless you are in a ‘don’t fix it’ environment (A nuclear reactor for example, where you never upgrade the software if you can avoid it. If it has been running fine on pre-pentium chips for 20 years, don’t try and upgrade to modern chips, etc).
However, if you aren’t willing to examine and remove then you will always be bogged down by cruft. Really, there comes a point at which a total rewrite might be a better option.
@rdm a test doesn’t necessarily help. If every day a robot rolls out and measures the height of the fence to make sure the fence is 6′ tall that doesn’t tell you whether the fence is or is not still necessary.
@james-iry You are correct. Mostly.
Code tells you (and the machine) how something gets done.
Tests tell you (and the machine, if they are coded) what is being done.
Documentation tells you why something is being done. (But machines do not have the depth of experience necessary to comprehend “why”).
Documentation can come in various forms, including:
1. Names (only good for concise expressions of purpose).
2. Inert text (or media)
3. (especially in early stages of development and release) contact information for someone that understands
I said “mostly” at the beginning of this message, because tests do give you a place to hang documentation, which can be especially valuable in the context of “cross cutting features”.