Software maintenance is traditionally thought as a process that will happen in the distant future, and will be needed only during bug fixing operations and to keep an existing piece of software current with new versions of a compiler or operating system. Maintenance is also viewed by many as an afterthought that doesn’t need to be dealt with until something happens and there is a clear requirement to modify an existing application.

The hidden truth, however, is that maintenance is an ongoing process that happens during the whole life cycle of the application. It is not only necessary after the system has been delivered but, on the contrary, it happens even after the first line of code has been created.

From the point of view of a developer, any code that has been created, doesn’t matter how long ago, is in maintenance. Of course, if it is fresh in your mind, the task becomes easier. Just edit the file in question to update a function, for example. However, in many situations the process may not be so easy, even if the software has not been released yet.

Keeping the content of a program in your head is just one of the challenges of becoming a programmer. Today’s software is huge, and all that complexity must be addressed on a daily basis. Even the best programmers will have some difficulty to remember exactly what a method or class does in particular.

That is why it is so important to write code as if it were in constant maintenance mode. The first thing that this implies is that you need to make it easier to understand what a piece of code is doing. That’s because, most of the time, the maintainer of the functionality will be yourself. Without good practices it is easy to forget what a class or method is supposed to do, for example.

Entering Maintenance Mode

The number one goal of maintenance is to make things obvious. Despite this, a lot of code we have is still created in “write-only” mode: a programmer creates something that may work (or not) but the result is so difficult to understand that it is easier to rewrite the whole thing than modifying it.

A major flaw of many developers is writing code that is hard to read and modify. Just notice that if something is hard to read, it will be difficult to understand, even if it was written by yourself. This is even harder to deal with in software that was written by somebody else, but don’t forget that it can happen on your own code.

For example, clever algorithms may be completely clear for you when they are fresh in your memory. However, after a few months (or even days), what was a clear strategy may now seem as a complicated mess. It is important to look at the future readers of your program as a real audience that you need to address.

Try to answer the following question as you write code: would someone else understand what this class or function represents? Even though it may seem easy to answer such a question as you are in the middle of a coding session, what about doing the same thing 6 months from now? If there is any double about the answer for this question, spend more time trying to make the code as clear as possible. Remember that it is better to spend a little bit more time describing what you mean now than spending several hours later to understand what is going on.

The same idea is valid for fixing bugs. Why not spending a few minutes checking the code that you just wrote, while the algorithm is fresh in your mind, instead of doing it when a client is waiting for your answer? Catching mistakes in code is so much easier to do right after you wrote some code that it doesn’t make any sense to wait any longer.

Performing Regular Maintenance

The other maintenance technique you can adopt is to be proactive in everything you write. Sometimes there is no time to identify every problem in a program. However, it is still possible to spend at least a few minutes every day doing maintenance work. I would recommend to use any available down time to perform regular maintenance tasks, such as:

• creating test cases
• removing dead code
• fixing code formatting
• checking for simple mistakes
• improving the build system

These are tasks that, over the lifetime of a project, will amount to a huge difference in terms of software quality. If only a few bugs can be removed by this simple process, it can result in a dramatic reduction in future maintenance costs.

Conclusion

Maintenance is considered to be an afterthought by many developers. However, instead of pushing this task to the future, it makes more sense to embrace maintenance activities during the life cycle of the project. It is easier to perform such changes when the code is still fresh in your mind. It is also much cheaper than doing this after a major bug has appeared in the application.

Similar Posts:

• Tips to Read Other People’s Code
• How to Handle Debugging Problems
• Day 29: Fix the Cause, Not the Symptom
• How to become a better developer in 30 days
• Day 14: Understanding Software Libraries