On Fences

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.

– G.K. Chesterton

There is a tendency in all of us to tear down fences built by others for reasons we do not immediately understand. It takes real effort to put ourselves in others’ shoes and divine their intentions. David Foster Wallace called it our default-setting, a natural instinct to self-centeredness. Instead of understanding someone else’s reasons, we prefer to assume the worst or the uselessness of people, the things they have built, the situations they are in. When someone cuts us off on the road, we fume and yell and assume he is an asshole. Perhaps he is. But perhaps he is late for a job interview because his kid had the flu and the driver has spent all morning at the emergency care office. Perhaps his sister is at the hospital having her first child. Perhaps a million other things. It is so much easier to say “you asshole” because we operate in a default setting of self-centeredness. Understanding other’s reasons and situations requires effort and empathy, an emotion on a long, slow, steady decline in our world of connected disconnectedness.

This happens in my line of work where someone will approach a piece of software and think “This is stupid and makes no sense. I will clear it away and build something else.” This is an expression of the same self-centeredness. It is easier to assume our omniscience than it is to see both (or ten!) possible sides of a problem. Instead of asking “Why is this fence here?”, we refuse to put in the work required to achieve understanding. And yet, there are always reasons why something was done the way it was. True, they may be as simple as “we didn’t have enough time to do it right.” But there were reasons. We ignore them at our peril because if those reasons still exist, we will tear the fence down and rebuild it exactly as it was, stone upon mistaken stone, until we have recreated the problem different in author only.

In software, this results in a constant reinventing of the wheel and an inability to maintain that which was created. A car has thousands of moving parts and requires regular maintenance to continue operating in decent shape. This is a fact no one will dispute. Few people in the software industry are so enlightened, often believing that maintenance is lost dollars thrown away at the expense of creating something new. But just like with cars, maintenance dollars spent now prevent massive breakdowns or entire replacements in the future.

Part of the problem is the infancy of our industry and no clear guidelines on when we should change the oil and rotate the tires in our applications. Part of that problem is that unlike in a car where the tires are in the same place and changing the oil is a straightforward operation, there is no scheduled maintenance manual for our software. Maintenance is fraught with the danger of breaking some unknown piece buried off in a rat’s warren of complexity. Imagine if one out of five times you changed the oil in your car, the brakes stopped working. Or maybe it caused the heater to always be on. You would acquire a certain hesitancy towards regular car maintenance because the last time it caused you to crash into a tree. Yet this is exactly the situation most software is in today. It is a live, moving, functioning system that needs maintenance just as badly as your car and yet changing pieces of most software systems may cause it to crash into a tree immediately upon leaving the garage.

Hearing this, you might wonder why it’s called software engineering. You wouldn’t call someone who built a bridge that had to be replaced in five years and couldn’t hold trucks over 2 tons after two years a civil engineer. There are places that are truly doing software engineering. Google, Facebook, Amazon. These places are doing engineering. But a huge chunk of the software out in the wild today is about as close to engineering as the pine box derby car you built in Boy Scouts. Because software is rarely engineered, it is rarely maintained. A bridge gets built and then over the years is examined by independent authorities and is resurfaced and is kept up but rarely added onto. Few bridges ever get a second deck or a helicopter pad or a brewery. A piece of software is built and may have any of these metaphorical things or more bolted onto it through the course of its lifetime. What we do is much closer to art and the maintenance of our systems is much closer to restoration than it is engineering. Restoring a painting is painstaking, delicate work completely unlike changing the oil in a car. You need a restorer’s touch to maintain most software systems along with a strong fear of failure.

The reasons for this are legion. Your average everyday software developer is qualitatively different from your average everyday Google software engineer. This isn’t a slight, just a fact of the bell curve. Also, most business software is a living, breathing, evolving thing, the opposite of what a bridge or a dam or an electrical circuit is. There are only about 3 ways to interact with a bridge and one of them involves removing yourself from the gene pool. When we engineer a bridge, the inputs into the system are known and finite. With software, the inputs are typically unknown and approaching infinity. This isn’t just at the user level but also at the design and requirements level. Things change all the time during development and just when you think you have a firm grip on what this particular piece of software is supposed to do, you’re asked to make it peel a banana or change a diaper. And suddenly you have a mess on your hands. When it gets pushed out to users, it only gets worse. A piece of software is constantly evolving and like our DNA, that evolution results in duplication, left over junk and vestigial appendices. It’s also why that piece of code you don’t think actually does anything never gets cut off. We don’t delete possibly unused code any more than we do elective appendix surgeries.

Which brings us back to that fence. The next time you run into a piece of code that you don’t understand or doesn’t make sense or you want to call stupid, remember that people with above average intelligence wrote it. They probably didn’t want it to be a pile of crap. They probably genuinely thought it was going to be fantastic because if they are nothing else, developers are optimists. But through forces of nature and evolution and shitty requirements, the perfection they were hoping for turned into something else. Perhaps it was intentional and you don’t understand the intention yet. Perhaps it was a Friday evening and they were fixing a production bug. Or perhaps they just weren’t very prepared. But give them the benefit of the doubt before you take a sledgehammer to their fence. Chances are that at some point someone will look at a fence you built and wonder how you could have been so stupid. Instead go away and think for a bit. Only when you can come back and understand the fence may you possibly tear it down.