Monday, January 3, 2011

Code Maintenance - You Can't Afford to Not Do It

Exercise is something that many of us who sit behind a computer all day don't get enough of. The reasons may be different for each of us but they typically boil down to the same thing - not enough time. Yet in the long run, is this true? Being fit tends to increase life expectancy, giving us more total time. Being fit gives us the energy and ability to do things that we wouldn't otherwise be able to do. Being fit decreases our odds of many different diseases, which gives us time to do things. Exercise even tends to increase our mood, which can allow us to be more productive. So even though exercise takes up time in the short term, it will probably more than pay for itself in the long term. So stop reading this and exercise!  (or read this while exercising).

your code base is probably out of shapeHave you ever had a code base that was so ugly that the easiest path forward was just to blow it up and start over? Have you ever wanted to (or been asked to) add a feature which is logically easy to add, but ends up being a ton of work because of the structure of the existing code base? Do you spend a lot of time tracking down and fixing bugs? If you answered yes to any of these questions, your code base is probably out of shape.

Most code starts out fit. However, no matter what methodology you are using, new features and requirements always come up. At first, since you started with a clean design, it is fairly easy to add these new features. In theory the original design is supposed to be updated and reworked to incorporate these new features, formally if using waterfall and via aggressive refactoring if using Agile. In practice this stage is often not given enough attention. While the first tacked on feature isn't a big deal, this affect snowballs over time until your beautifully fit and sculpted code becomes a blob of interconnected modules and features that is afraid to go out in public for fear of catching bugs.

Its up to you to take the time to keep your code fit. If you don't have the support of management, then build the time into your schedule. Don't "complete" a requested feature until you have taken the time to make sure it is clean. Sooner or later you'll have to take the time. If you don't take it now it'll be when the preponderance of bugs appear in the future. It is your professional responsibility to choose when it makes sense to take the extra time.

Oh, and just as exercise can have immediate, if not tangible, benefits (like improved mood), so can code maintenance. Analyzing and rethinking how code is written and how it could be written is one of the best ways to improve your own design and development skills making you a better programmer.

Obviously, it is possible to go overboard with code maintenance. Just as some people spend there whole life in the gym trying to have the perfect body but then never have free time to enjoy it, so too is it possible to spend all your time cleaning code and never actually creating anything new.  So what is the right amount of code maintenance? You'll have to figure out what makes sense for your environment. However, if you ever try to make a change that ends up being a lot more complicated than it should be, it is time to clean up your code.

So consider this a friendly public service announcement to maintain your code.  And exercise!

1 comment:

Jennifer said...

Good post. Though sometimes it can be tricky to convince others that it is better to take the time *now* to implement the new feature in the cleanest way possible, especially if everyone is under pressure and the 'hack solution' can be implemented more quickly. After doing this for 10.5+ years, I just assume that refactoring and trying to implement things cleanly the first time is part of my time estimate for getting things done. When I started at my current job 6.5 years ago, I would initially ask my boss for time to refactor; now I realize it is best to just do it.


One quibble: I don't know that I agree that 'most code starts out fit'. Sometimes, when requirements are initially unclear, the best thing to do is hack something up quickly that will be quite 'unfit'. Once you have code that does *something*, requirements can suddenly become clearer, and then the original code can be refactored/rewritten.