I was reading a software development discussion board this week. One person posted a rant about how he hates maintenance programming. He said the code he was forced to work on had absolutely no comments. There was a lot of redundant code. The code base used a number of different frameworks. He thought they were at the point where they needed to dump the app. His boss did not agree. So he eventually quit. I find it interesting that this scenario closely resembles the project I am working on. I was glad to see a lot of comments to this person’s entry. I am going to take the time here to review some of the finer points of maintenance programming.Just because code is old, that does not mean it is bad. It can be used as an opportunity to hone your skills. You have a great opportunity to perform code refactoring. You can strive to remove all the warning you will get when you compile the code. Maintenance coding is the norm after all. Some people put the split as 20% new development versus 80% maintenance coding. A strong recommendation would be to initiate good unit tests if you do not already have them. If some of the code is bad, just rewrite that portion and ensure you did not break anything.
Working on code maintenance is not a waste of your time. You can find many examples of what not to do by looking at the code base. There will be plenty of puzzles to solve while fixing tough bugs in the system. It a lot of code is bad, you have the liberty to delete lots of code. You can use the situation to your benefit as well. Not many people want to do maintenance programming. And there may not be many people who do it well either. So you can potentially make more money doing it. There can be other perks as well. You can ask your boss for flexible location or work hours. And you can ask for 20% of your time be spent to explore new technologies. What kind of good manager would refuse any of these reasonable requests?
Maintenance may be, in fact, the hardest type of programming. It is a type of programming that will dominate the software work. This is because it is almost always more expensive to build a new system than maintain the old one. You will not always be just fixing bugs. You will probably be updating the legacy code to meet new business needs. Even if you work on some new development, the project will quickly turn into a maintenance phase. Somebody wise once said that “all programming is maintenance work”.
It is true that in maintenance work, most of the design decisions have already been made. And it will be tough to upgrade to the latest tools. This is due to the risk involved with such an upgrade. My own project neglected this for many years. Then it took a lot of pain to update to newer database clients and code compilers. In maintenance you can expect to spend a lot of time reading code. But as you can see, this may not be a bad thing.
