Code Maintenance

The idea that once our code is working, we are good to go is a very bad idea. An idea that needs to be reevaluated and reanalyzed. When you buy a car, it works at first, then it begins to develop faults. Do you have to wait for the car to develop faults before you begin maintaining it? Well, the answer is obvious and the answer is NO.

But why then do we have to do the same thing to our code? Once a piece of code works or passes that test, we close that code and never ever look back. Even the car at Toyota passed the test before it was delivered to the client, but it also had to be maintained. Some people would argue that code maintenance is far different than maintaining a car, but I would beg to differ. That which is maintained in whatever form is much better than what is never maintained.

So how do we go about maintaining our code? Same as maintaining a house. Maintain it just a little at a time. You should also start on the first day. Maintaining a code base is about finding better ways of doing what you used to do. The software business is about writing code to solve a client’s problem, but it is not always about solving the problem. How you solve the problem also matters, so you need to evaluate that piece of code often.

Also, before going around changing your whole code base all in the name of maintenance, always make sure you have a test structure that ensures that at least everything is at least the way you meant it to be. Just better now. Never have a mind to overlook minor issues when you see them. You might not have the time now, but all you need to do is to note it down and look at it when next you are free. But who knows when next you would be free? It would be of great importance if organizations would set aside a time to always come together to evaluate the code base. It bolsters friendship and communication among the team members. Better ways of handling issues are suggested and the code base gets better by the day.

Always remember that software development is not only about developing new features; it also involves developing what was written earlier. Even the language you are using develops every day. Old features are deprecated and new features are added; the same happens with your product. Consider when you last deprecated a feature in your code base.

The goal is not to go around breaking your code base all in the name of maintaining it, it simply means to evolve new ways of doing things you used to do which would overall improve the efficiency of your code base.

It is really important that product owners and managers set aside time to review old code and proffer new ways of handling it. Remember, it is not what we do, it is how we do it that makes all the difference.