Infovark

Hi. I’m Dean, and I was a maintenance programmer.

I’ve just spent the last two days refactoring the infovark storage and retrieval API. It wasn’t that anything was broken, exactly, it was just that it was… messy. There are a lot of things I should have been working on instead, but I couldn’t resist tidying up the object model a bit. It’s a weakness of mine.

You see, “maintenance programmer” is generally considered a pejorative label in the software development industry. Programmers that do maintenance — minor bug fixes, performance improvements, functionality tweaks — are generally on the lowest rung of the development team.

That’s how I got my start in software. My first coding jobs were technical support and troubleshooting gigs. You can ask anyone who’s worked with me on a development project, and they’ll tell you I’m fastidious — some might say fussy — about the structure of my code. And, truth be told, I’m picky about everyone else’s code as well. Since my first experiences with programming were maintaining large codebases written by other people, with no specifications or even a user manual to go by, I’ve developed certain habits of mind.

No respect?

If great hackers are the poets of the software world, then maintenance programmers are the copyeditors. Great hackers produce elegant code. Their deeds are legend in the computer science community, and some have passed into history. Some are so good they’ve been celebrated in free verse. Their code soars in cathedrals of light, pure in its mathematical beauty.

By contrast, the code churned out by the maintenance programmer is solid, workmanlike, and perhaps unimaginative. But it works and will continue to work. There won’t be any odes sung to the maintenance programmer, but at least a few respected developers out there, like Eric Sink and Jeff Atwood, have spoken up for us. There’s even How to Write Unmaintainable Code, a humorous treatise on the many ways to drive a maintenance programmer crazy — and a tribute to all of us that have suffered at the hands of sloppy development techniques.

So we’re beginning to get some respect. And I’m proud of the work I do. I realize that being a stickler about naming variables properly or commenting logical branches only slows down development. But I take comfort in knowing that my code will stand up to some abuse out there in the real world.

Maintenance programmers of the world, unite!

Do you think you might be a maintenance programmer, too? Here are the seven warning signs:

1. You feel a sense of accomplishment after refactoring.
2. You have more than one book of design patterns on your bookshelf.
3. You think that program files should contain more comments than code.
4. You introduce coding standards for any project consisting of more than one person.
5. You don’t trust the compiler and you don’t trust the unit tests.
6. You actually like having code reviews.
7. You know that no program is ever truly “done”.

Sound familiar? If you get the same feeling of delight at sorting out spaghetti code as you did reading Eats, Shoots, and Leaves, you might be a Maintenance Programmer. There’s good news for you, however: You’ll always have a job to do. Because no matter what happens in the computing world, there will always be code in need of a rewrite.