Section 10.2. What Is Product Maintenance?

10.2. What Is Product Maintenance?

One simple definition is that it's everything that comes after the first release, whether adding new functionality or fixing bugs. It's certainly true that for many products much of the code is written for that first release and then never drastically changed, unless it's eventually discarded for a completely different set of files. Another way to define maintenance is that for many companies and projects, all releases except the next onethe one that is still to comeare in maintenance mode. This includes any version of the product that is actually in use by customers.

Being in maintenance mode usually means that fewer people and resources are assigned to that version of the product, and sometimes these are the less experienced or less expensive people and resources. There are fewer and less-frequent changes committed to the source code, and there are quite likely fewer builds. Less effort is spent testing, so fewer bugs are found, at least by the developers and official testers. In the maintenance phase, bugs are reported mostly by customers.

Figure 10-1 shows some estimated life spans of typical software products; note that products spend most of their life in maintenance. For example, if a short-lived product has one major release each year, and each major release is expected to have a useful life of at least three years by the time everyone has upgraded from it, then two-thirds of its life span is spent in maintenance. The amount is about the same for long-lived products.

Figure 10-1. Life spans of typical products

Since so much of a product's lifetime is spent being maintained, it's worthwhile seeing how a development environment can help with it.

10.2.1. Developing for Easier Maintenance

How to write code is not the main focus of this book, but here are a few suggestions for making your source code easier to maintain. The next section, Section 10.3, also discusses tools and books that can help when it comes to understanding code.

• Remember that source code is a communication from human to human, as well as from human to machine.

• The less code there is, the less there is to maintain. Eliminate all commented-out code and code surrounded with the ugly #ifdef NOTDEF directive. It's still in the SCM tool if you need it later. If it's code for logging or debugging, use a proper framework for these, not ad hoc commented-out code.

• Avoid or clearly document functions and methods that need to be called in a certain order or that should not be called more than once. Treat functions with side effects with great caution; avoid writing them if at all possible.

• Describe the current implementation before you change it. This helps to make the changes clear for you, and it's useful as a reminder later on of how it all used to work.

Finally, consider why code rot occurs in your project. Perhaps it is due to particular changes that occur regularly or to individual practices by certain people. If you can see a pattern, then you may be able to change it.