This Old Code

When faced with something new, it’s usually comforting to equate it to something old and familiar. This is fairly commonplace in the world of software development. It’s much easier for programmers to think of software in the terms of things that have been around much longer. This is the root of our association of software development as an engineering discipline. These analogies can be very helpful in allowing us to understand the often overly complicated world of software development, however, when these analogies prove false, they can lead up down some very dangerous paths.

Take, for example, the idea of code maintenance. The idea that code needs maintenance comes from our associate of software development to any of the many historical engineering disciplines. Civil engineers, for example, build buildings which then require constant upkeep to keep them clean and stable. Mechanical engineers build complex machines that need to be oil and tuned so they don’t seize up. Electrical engineers build circuits that, over time, heat up and deteriorate. At a very basic level it makes perfect sense to associate the development of software with the building of a house, they both revolve around the creation of something new from basic building blocks.

So, that being said, let’s try to invasion our software system as a house. Our house needs constant maintenance. The floors must be swept, the driveway sealed, and the garden weeded. In fact, if we had the funds, it would be beneficial to have a gardener on staff all year round to mow the lawn, pull up weeds, trim the trees, and water the flowers. Someone needs to do all these little tasks which are required to keep our garden growing. Along the same lines, who among us would frown at the idea of a live-in servant who would dust and clean and keep every part of our house in near immaculate condition? As with any sensible idea, however, we as the owners of software systems, or house in this case, often take this idea to the radical extreme.

We have a plumber around the house at all times in case we spring a leak. We have a carpenter on hand in case a neighborhood kid sends a ball through our window. We have an electrician on the books in case someone blows a fuse plugging in too many Christmas lights. The end result of this being that we now have a huge staff that we have to pay, even when they’re not doing anything. Not only that, but they’re always in our house. Even the gardener, who’s very busy during the summer, has nothing to do in the winter. So we find other little tasks for them to do and they end up spending their free time making little enhancements to our house. They add new faucets, or new trim, or maybe a few dimmers. They’re not needed, but since we have these people in our house, we might as well use them.

This is the view we have of software. We need a dedicated database admin just in case the database goes down. We need a programmer or two just in case some weeds start to grow in the code. We need a few testers around to ensure the logic hasn’t started to rust. However, we’re ignoring the core truth here; that code does not need maintenance. It does not rust, it does not decay, it does not degrade, weeds do not grow in it, and therefore it does not need maintenance. There are only two ways an error can occur in code. First, you put it there yourself. As hard as it is to admit, we don’t always get it right the first, or second, time. Or second, an external dependency of the system has changed. It might be a service we rely on, it might be the hosting environment, or it might be as simple as your disk has run out of space. However, the key point here is that something must change; otherwise the code is just going to keep running as it’s always run.

So, why do we have this fallacy of code maintenance? First, we’re building on an inaccurate analogy. Code, unlike the physical world of house and cars and hardware, doesn’t deteriorate over time. Second, the broad heading of maintenance gives people the leverage to have their very own gardener, servants, plumber, carpenter, and electrician at their beck and call. And, honestly, who can blame them, it’s much handier than having to call a plumber in the middle of the night because you have a leak As long as the process allows this, you’d be silly not to take advantage of this and safeguard yourself this way. Third, we are afraid that if our pipes ever do spring a leak, we won’t be able to find a plumber. So we keep one around just in case.

So why don’t we just have a plumber in every house? First off, it’s also not very cost effective to have a skilled resource assigned to a project, just in case something goes wrong. The lost cycles of productivity are astounding. Second, it’s also not fair to all the other people who need a plumber. Plumbers do not grow on trees. They are a limited resource and must be shared. Third, having your plumbers sitting around all day just waiting for a problem to occur does nothing for their skill sets. They will become out of practice and will never gain new and valuable experience. Fourth, and most importantly, you are condemning your plumbers to careers of boredom and stagnation. Who would want to work for such an organization?

So how do we deal with this problem? Well, first off, we need to stop believing that code needs maintenance. Yes, maybe the colour of the paint should change, and the drapes are outdated, and the car runs like a pregnant yak. But that’s okay, it all still works. And if you want to change it, demonstrate the business value that our changes will add and it might get funded. Next, we need to give up on the idea of our small little empires and embrace the idea of a commonwealth of professionals. We can’t all have our own personal household full of servants to do our bidding. If your changes have real business value, then you should be able to justify your changes as real, fully fledged, projects. And finally, if you spring a leak, call a plumber; don’t have him sitting around all day. Have a service level agreement in place that if something serious happen, you can get your staff. It may slow down system lower on the totem pole, but that’s why we have priorities.

Most important of all, be happy. You live in a house whose foundation will not rot, whose roof will never leak, and whose lawn never needs to be mowed. And, as long as the neighborhood kids don’t put a ball through your window, you can live happily ever after.