Practical .NET

In Praise of the Maintenance Programmer

The developers building new applications are very nice people, of course. But the real heroes of the programming world are the developers maintaining and extending existing applications.

• By Peter Vogel
• 12/16/2014

Back in 1984, I was fresh out of school and ready to be hired as a developer. I was hired by a large multi-national corporation … and immediately put on the maintenance team for an existing application. At the time, that decision seemed reasonable. In retrospect, it seems spectacularly stupid. Actually, "crazy" would be a better description.

Maintenance is much harder than new development. Putting a newly graduated, "wet behind the ears" developer like me to work maintaining an existing application was like having a newly graduated medical student operate on the President's brain -- no one in their right mind would do that. The existing applications I was maintaining were the applications that powered the company; the applications in development, on the other hand, were irrelevant to the company's operations (though they could have had some impact on the company in the future).

The distinction between development and production systems comes down to one key characteristic: No one cares if the development system goes down. On the other hand, if you take down the production system, you'll get calls from people who couldn't be bothered to notice you before (we won't ask how I know this).

I understand now the logistical realities of putting me on maintenance: The company needed lots of "hands and feet" on that side of the IT department. After all, 75 percent of an IT department's time is spent on maintenance so, presumably, they needed three times as many people on maintenance as they did on development. But, still, putting the person with the least real-world experience on the real-world applications makes no sense.

And the "hands and feet" explanation doesn't explain why the developers on new development projects were generally considered heroes. Back then, the people working on the new applications had a much higher status than us lowly maintenance programmers ... and I bet that's still true. On the basis of "value provided," maintenance programmers are far more valuable than development programmers. Maintenance developers build on an existing code base and, as a result, maintenance developers deliver more functionality with less cost than any new development team can possibly manage.

The Skills of a Maintenance Programmer
When I did, eventually, move to new development I actually dropped a number of skills that were essential to my work as a maintenance programmer. Working on maintenance, as much as I was a programmer, I was also an historian and detective.

For example, while I was on maintenance, I got assigned the problem of tracking down a bug that occasionally caused our application to crash, leaving some corrupted data in its wake. The bug's first appearance had been more than four years ago (long before I had joined the company). The bug had been dormant for a while, but it had shown up again in the last week.

Because I am a programmer, I did take a short look at the code, but, since I was the third or fourth programmer assigned the problem (and given my lack of experience) it seemed unlikely to me that I would find anything the previous developers hadn't found. If it wasn't the code, I deduced it had to be the data…which led me to plot the occurrence of the bug's reports over time. The resulting curve was interesting: While the initial occurrences were quite frequent (three or four times a day) the frequency gradually diminished until, now, the bug was happening only once a couple of times a month.

Based on that evidence I concluded that something had happened just before the first appearance of the bug which had resulted in the database being seeded with bad data. When the application hit that bad data, the application would blow up and someone would come in and fix the data. The application wasn't corrupting data, it was exposing it. When I presented this analysis to the rest of the team (who'd been around longer than I had), they instantly identified the problem: A data conversion program that had been run just before the bug first appeared. With that information we were able to find the rest of the bad data and repair it.

Maintenance programmers do this all the time: Part detective, part historian and, occasionally, a developer. They are also software archeologists (digging through layers of badly patched code) and psychiatrists (figuring out what motivated the developers who came before you).

When I did end up on new development, I was glad to get the "promotion" because it was such a relief after being on the maintenance team. Maybe that's the real reason you get moved to development: As you get older and start losing your edge, you're not put out to pasture; instead, you're moved to where you can't do any harm -- new development.