Chesterton's Fence
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. Excerpted from Wikipedia Emphasis added.
Once, many years ago, I was on a software development team. One of the younger developers called the lead developer over and asked “what does this method do?” The lead developer looked at it and said was skeptical. “Wow...yeah, what does this do? This is terrible. What is even going on here? Who wrote this?” They used the git-blame feature and discovered, of course, that the lead developer had written it. Once he saw his own name on it he saw it in a different light. “Well, okay, I guess I see what I was going for. Yeah, okay, this makes sense. Yeah, this is really good...”
And you see the same thing all the time in software development. We don't understand something, so we determine that it's useless.
Go back further in time with me, when I was myself a young programmer. I was asked to modernize some legacy code. I read through it, tried to comprehend it, got the gist of what it was going for but was deeply skeptical of the method the developer had used to get there.
So I started rewriting it. Fast forward a month, when I look at my code, and realize how closely I had re-created the original code. Many of the “pointless” methods were only pointless because I didn't understand the requirements. Things I saw as needless complications to a simple process were there to protect the code against the vagaries of the most likely users.
Like Chesterton's “modern type of reformer” there is a strong desire to wipe the slate clean and start over when you're taking on software projects. And there is a definite need to remove things that are outdated, worthless, or downright harmful. But before we remove something let us at least try to understand it fully, then when we know it has outlived its purpose we can cut it out of our systems.
I’m publishing this as part of 100 Days To Offload. You can join in yourself by visiting 100 Days To Offload.
#100DaysToOffload 33/100