The Art of Software Maintenance

Software Maintenance Blog

William A Clements

The Art of Software Maintenance
            Not to be confused with the Art of the Motorcycle Maintenance, this entry is about an article I recently read. I have found that when you have come up with a good way of explaining something, someone always has a better way. “The Art of Maintenance Programming” by Nemanja Trifunovic explain nine practices every software maintenance engineer should strive to master. In summary:

• Get to Like It
• Disadvantage: “Developers dream of being chief architects in their teams, and when they end up maintaining existing software, it feels almost like punishment.”
• Advantage: “…Employers actually value people who solve problems; and maintenance programming can be a good chance to demonstrate your problem-solving skills”
• Get Familiar with the Functionality of the Software You Maintain 
• Read the existing documentation 
• Dig out the test plan, and go through it 
• Find out how the software is being used 
• If you are a power user of the software you maintain, chances are you will spend less time in the debugger 
• Get Familiar with the Architecture of the Software You Maintain 
• You would expect to inherit detailed and up-to date design documentation, including requirements, functional specifications, high-level and low-level design, as well as well-commented code, right? – Ah Nope 
• Look at the code 
• Try to understand the roles of classes, modules and components
• Use the debugger 
• Step through different scenarios of use
• Be sure to write down your findings and organize them in some form
• It can be some formal method like UML diagrams, or something informal but easy to understand
• Communicate with the Users
• When they report a problem, get back to them immediately, even if you don’t have a solution at that moment – just let them know you are looking into it and not ignoring them. Keep them updated about the status of their problem. Finally, be honest; if you can’t meet their request for any reason, tell them.
• If Possible, Communicate with Original Developers
• Don’t expect them to do the actual coding for you, but they can throw you an idea how to accomplish something, explain you why something works the way it works, and provide you with lots of helpful hints.
• Keep the History of Changes
• An accurate history of changes is invaluable for successful maintenance, even if nobody else before you took care of it, and you get only a partial list of changes.
• Be Conservative
• Many times during the maintenance work, you are going to get frustrated with the existing code in some module, and just want to toss it away and rewrite it from scratch. Before you actually do that, ask yourself some questions:
•  How would it benefit your organization and its customers? The fact that some code is ugly, or looks ugly to you is not per se a reason to rewrite it. If a customer wants a feature that can’t be added to existing code, that could be a reason to consider rewriting it. 
• Are you sure you understand what this code does and how it works? 
• Are you sure you understand how it interacts with other parts of the system, and which modules and functionality depend on the code you want to rewrite? 
• Are you sure you can make it better? Maybe you run into the same problems the original developers did, and make it same or even worse.
• Refrain from refactoring
• Try to do it the right way immediately, later will never come. 
• Test after Every Change You Make
• First coding task you need to do after taking some software to maintain is to write a comprehensive regression-test suite.
• A good practice is that for each defect report you get, write a test-case to reproduce it.
• Adopt Existing Code Conventions Even If You Don’t Like Them
• Try to stick to whatever conventions exist in the code you maintain, … don’t introduce yet another one

In my own experience, I have learned each of these principles, sometimes I learn them the easy way, others the hard, and they are extremely helpful in keeping the software from turning into spaghetti code.