The Code Whisperer

Given the choice of developing new code or correcting/enhancing existing code, most developers will opt for developing new code. It allows them to do it their way without fighting through a number of different programming styles and convoluted logic to fix problems introduced by someone else. An enhancement of any great substance often results in calls for a re-write. It’s no surprise that maintenance is seen as “B” team work.

I’ve worked at a number of installations where the new recruits work on maintenance to “learn the system”. I think this is wrong. Someone once compared software maintenance to surgery in that cutting a body or software open leaves a scar. In the same way that in an operating theatre you would want the experienced surgeon who will make the smallest possible incision, with your software application you don’t want a developer who is going to check out half of the source code and make changes all over the place. You’ll end up with more checked out code and changes that you need or want. Please note I’m not suggesting that surgery and development are on a par in any other way.

I firmly believe that software maintenance needs developers with a specific mindset, which, quite likely, will be the best developers in your team. Here’s a few qualities you should look for:

• Doesn’t shout “re-write” within 10 minutes of looking at any problem. There are times where a rewrite may be required, but generally it’s easier to re-write than understand the existing code, hence the cry, but losing years of testing and bug fixing in the process
• Can work without documentation. Regrettably many computer systems have poor, non-existent or out of date documentation, which makes maintenance a nightmare. The maintenance programmer in these cases must be able to understand what is going on from the code and debugging sessions
• Understands that sometimes the seemingly rubbish bit of code in front of him or her may have been done that way for a good reason and doesn’t dismiss it out of hand. If this was the case I would hope there were comments to support the decision made, but this isn’t always the case
• Knows that in a complex system making a change can have a knock on effect elsewhere and investigates fully before making the change. Recently I saw the effect of not appreciating this, and not testing fully - it wasn’t pretty
• Fully tests all changes, even a one line change. This goes hand in hand with the previous quality - testing the implications of the change made
• Good problem solver and doesn’t give up easily
• Prepared to implement a good quality fix or enhancement, not a quick bodge

I’m going to end this post with a quick note about enhancements to existing code. Sometimes code isn’t designed with extensibility in mind, which makes adding new features tricky. When this happens you need your best developers in charge of the technical design. It’s important that the designer can look at several different ways of implementing a change and select the one that works best with the existing architecture and is the least intrusive, and not simply the first one thought up.