Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
From Zero to Hero
Maintenance programming is often considered the scutwork of the programming world. It shouldn't be. Maintenance programmers don't have the glamour attached to the Software Architect who begins from scratch, applying the latest tools and techniques in pursuit of a vision, affecting the project for years to come. That role is often assigned to the best programmers on the staff, because you want all your new stuff to be great code, not like all that old crummy code out there that's so nasty to work with.
But I say that good maintenance programmers are the smartest, most talented, and best educated programmers out there. They take on the hardest jobs, and often the most necessary ones. New software projects fail more often than not, and if they do there's always somebody to blame before you move on to the new task. Maintenance programmers don't have the luxury of failure; they have to support users who need the work done, and they usually need it done right now.
I've done an awful lot of both kinds of programming. Occasionally, the original software architect who so stupidly mangled the code is me, and I'm forced to slash through hundreds of badly designed modules where I don't even have the pleasure of badmouthing the fool who put this thing together in the first place.
The pleasures of maintenance programming are perhaps less profound than those of new software development; in my kitchen it's more fun to cook than it is to clean. However, maintenance is not without its own sort of joy, because you're doing something that absolutely must be done, and unlike washing pots, it involves more and different skills. In future columns I'll explain tips and tricks of maintenance programming from decoding cryptic methods to reading comments, and I'll show you why I take so much pleasure in maintenance programming and being a programming hero.