Programmer Musings

Maintenance Programmer vs. Original Programmer

In the book Software Exorcism, Bill Blunden described a problem caused by the maintenance programmer not usually being the same person as the programmer who wrote the code. Often the maintenance programmer comes in with a less-than-complete understanding of the original problem or of the design decisions made for this problem. Usually, there are also time pressures that prevent the maintenance programmer from taking the time needed to really understand the code before making changes.

These are all important difficulties with the issue of maintenance programming work. One other issue is that maintenance programming normally goes to less experienced programmers or programmers new to the project/company/etc. This puts the maintenance programmer in a position of having far too little context to always make the best fix for a problem.

Despite these handicaps, many people excel at fixing problems in this environment. In fact, really good maintenance programmers are able to model the design of the code well enough to make actual improvements rather than just patch the old code. In situations where the original design information is available, either through documentation or oral tradition, a good maintenance programmer can do an amazing job of improving code.

In the book, however, Blunden makes the curious assertion that the original developer would know enough to make changes to the project without having to relearn everything, but they are never around. He also points out that there wouldn't be bugs in the programs if the original developers had just done things correctly.

I find these assertions baffling. I have been an original developer and a maintenance programmer. I have also actually maintained code that I wrote for several years after I originally wrote it. I think it is safe to say that each of these assertions is naive at best. Given six months and a complicated enough program, the original developers may not be able to remember why they made the decisions they made. Not all of the design decisions are completely documented. Sometimes nobody wrote the decision down because it was obvious (then), but is actually not obvious a few years later. (I've also seen times when the novel idea was documented, which seems surprising later because the novel idea has become accepted practice.)

This experience is in direct contradiction to Blunden's assertion that the original programmer would be able to trivially fix any bugs in the code. This is also not just my experience, many people I've worked with over the past couple of decades have had similar experiences.

More importantly, the reason for a large number of maintenance fixes in my experience have been due to changes in requirements after the product is live. This means the assertion that if the original programmer had just done things correctly there would be no bugs does not match reality. No amount of careful programming practice could account for bugs caused by changing environments and requirements.

You could make the argument that flexible enough software should have accommodated the new requirements. But, there are a few problems with that. One example that I can think of from my past involves a user interface issue requested by one of our clients. They requested a feature that could be interpreted by the user to work one of two different ways. We suggested a different design that only had one interpretation, but we were overruled. They stated that only one of the interpretations could possibly make sense. We will call that interpretation Approach A. The client asserted, quite firmly, that the other viewpoint (Approach B) would never be reasonable.

Six months later, a bug report came in that stated that this feature was broken. According to the bug report, the feature was not using Approach B, which is the only reasonable interpretation of the feature. We reported back that this was what had been requested, but once again we were overruled. So the code was changed to match Approach B. A few months after that a new bug report came in on that feature that stated in no uncertain terms that we had broken the feature and Approach A should be restored. When the third bug report on this feature came in, we passed all of the emails and documentation of the original feature back to the project manager and the client. We told them that this would be the last time this issue was touched. They had to choose one approach and that was the only change we would make.

This story is obviously an extreme case, but it is nonetheless a true story. No amount of prior planning or careful design can overcome this form of problem. In this case, I had been one of the original programmers and one of the maintenance programmers. So I could pull together the original information and the new requests to allow the project manager to discuss the issue with the client with the relevant information in hand. But other than that, there was no solution to the problem.

Sometimes the changes in requirements that generate fixes come from environmental changes that no one could have predicted. Over the past decade, a large number of programs have been retrofitted to run as applications on the Web. There was no way to predict in 1990 that anything like the Web would take business by storm and that ordinary people would come to depend on it the way we currently do. Despite that, many programs have been fixed to be compatible with the new business reality.

Although I agree that the maintenance programmer is often at a major disadvantage when modifying an existing program. I disagree that the original programmer would necessarily have a major advantage over the maintenance programmer. In some cases, the original programmer can be at a disadvantage if the goal of the software has changed significantly and the original programmer can not let go of his or her original design. The maintenance programmer may find it easier to embrace the new environment and modify the code appropriately.