Is Maintenance Programming Really More Challenging??

As Dave Thomas would quote it, “All programming is maintenance programming, because you are rarely writing original code.” I have to agree but then in this topic let us refer to the definition of maintenance programming shall we? Maintenance programming is defined as the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.

I think a lot of programmers will agree that creating your own programs or systems are easier and finishes faster than editing programs made by other people. I have already personally dealt with a situation like that and I found out that programmers opt to write their own function because it's easier and more fun than figuring out how the old function works. In the latter, you would have to familiarize if not study the whole code of the old system to know where to change it and add upon it. Familiarizing and making the system adapt to the changes you are about to subject to it are rather troublesome than just starting off from scratch. As Joel Spolsky would quote it, “It's harder to read code than to write it.” This is one of the reasons why a programmer would rather make a new program than do maintenance programming.

Maintenance Programming is intellectually complex, technically difficult, unfair, no-win dirty work and conservative. Thus, a maintenance programmer should be knowledgeable with his trade, patient, disciplined, creative, up to the challenge or willing, conservative and has good communication skills. A maintenance programmer should like what his doing so as to have the will and tenacity that this challenging task requires. As already stressed above, he should have good communication skills since he needs to communicate well with the users of the systems and to the original developers of the system.

Many software developers are introvert persons who prefer to deal with technology rather than with people. However, the software is written for people to use it, and in the case of maintained software, we already have users. It is crucial to find out how they use the software, why they use it, what problems are they trying to solve, what functionality they need. To find that out, don’t wait for them to come to you; be proactive and go to them. If possible, communicate with original developers. If you are lucky, some of the original developers are still with the company, and they can be a tremendous help and save a lot of your time. 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.