Why I Don't Mind Maintenance Programming

From AndrewMoore

This is obviously a work in progress.

In talking with my fellow engineers about what kinds of positions they'd most like to have, many times they mention that they want to work on a new project, not maintain an old one. It's viewed as more fun to move into uncharted territory than it is to maintain a system written by someone else. That may be true, but I have a few reasons that being a maintenance programmer isn't as bad as it's cut out to be.

If you outperform stagnant, you're a hero

When I take over a running application in order to just maintain it and keep it running, often all that is expected of me is to keep the application running as it is. If I just keep it running as it is, don't let it breakdown, and add no more features to it, I've satisfactorily done my job.

But, I naturally like to do better than satisfactorily. If I take that old application, and refactor and clean up some code, then I can improve or extend it much more easily than before. If you make even some small amount of progress toward adding a new feature or fixing a defect, you've outperformed your goal.

But, it gets better. It's often really easy to do this to an existing application, simply because you're not the person who wrote it. Your different perspective seems to make it pretty easy to spot areas for easy improvement. Within a few weeks, you'll start hearing things like "we never expected that application to do that" because the previous engineer wasn't thinking of the same things you are.

You can easily turn a cost center into a profit center

Sometimes when I look at an installed base of code, I find places where there is useful information that is not being exposed. The database knows some statistics about the business that are not being given to decision makers. Sometimes this wasn't done before because it's not obvious when something is being built what kinds of statistical information it will collect. Sometimes it's not done because it's just not the lowest hanging fruit (yet).

Whatever the reason, I really love it when I can take a piece of software that used to be considered a cost of doing business, and from it extract something that can give my organization a competitive advantage. Often by mining some data or adding a small feature, I can produce an asset to the company. If this can be done quickly (cheaply), then I've created value. What could be better than that?

So, you see, I don't mind maintenance programming so much.