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.

Review of Perl Testing: A Developer's Notebook

Perl Testing: A Developer's Notebook
Ian Langworth and chromatic
O'Reilly, 2005

This is the first book I have read from the new O'Reilly Developer's Notebook series. Although the style of these books probably won't work for every topic, it works particularly well for a book on testing. Each chapter is organized as a set of labs. These labs walk through some portion of the topic with the goal of developing practical skills.

Each lab revolves around a task. They don't delve into theory, they focus on describing how you perform the task. Unlike O'Reilly's Cookbook series, this is a directed set of tasks. Much like labs in a class, the labs in this book start with basic testing skills and work to build more advanced testing skills. The goal of this set of labs is to help you become proficient in the skills needed for doing quality unit testing of Perl code.

I have been doing testing with Perl for some years now, so the first few labs were review. But, the labs swiftly escalated to more advanced topics that I was either light on or had not explored at all. In addition to labs about Test::Simple, Test::More, and Test::Harness, the book covers:

• testing the POD documentation in your modules
• coverage testing
• testing exceptions generated by code
• testing warning generated by code
• building testing libraries to simplify testing
• mocking objects
• overriding system calls
• testing databases
• testing websites

and many more topics related to testing. This little book is packed with practical information and labs that help you improve the skills you need to build quality testing for your Perl code.

I really don't expect this book to become a well-worn reference book that stays near my desk at all times. However, I don't expect to let it get far away. Since few of us need to use all of our testing skills on every project, some skills become rusty over time. Anytime I find some of my testing skills have gotten rusty, I expect to grab this book and run through the appropriate labs to sharpen the skills I need.

If you want to know why you should be unit testing your Perl code, there are many books out there that will explain. If you are looking for an explanation of Test Driven Development, this is not the book to read. Once you have decided that testing is important to you and your projects, this is the book you need. I would not say that there are no other resources for learning this material, but this may be the fastest way to build the appropriate skills that I've seen.

It also helps that the authors have a very relaxed style that helps you feel more like they are working along side you than lecturing at you. The titles of the sections are very casual (How do I do that?, What just happened?, etc.) This makes it easy to read the next part and get back to working on the meat of the lab.

I would recommend this book to anyone writing Perl code. We all need to be doing testing to improve our code and our designs. The key difference between good testing and bad testing is the skills to make every test count. This book teaches those skills.