Software Maintenance: Heroes
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This column is dedicated to the smartest people in the programming business.
It is said that programming is "the art of debugging a blank sheet of paper." Any real programmer can tell you that a blank sheet of paper is the easiest thing in the world to debug. There are no legacy issues, no poorly designed code to rewrite or work around, no programming styles to conform to except your own.
A lot of books are dedicated to this easy part of programming. The question is, what will you do when you're confronted with a million lines of somebody else's code? Besides wince, that is.
The Software Engineering Institute's Capability Maturity Model calls such operations heroics. It's the lowest level of maturity. They consider it derogatory that your organization would need heroes to function. I like the term. No matter how "mature" your organization is, every once in a while it's all going to come down to the guy who has to track down the error.
That person probably is you.
And it has to be done yesterday.
As time goes on, more programming is maintenance programming. Software is expected to do more and more, so the programs get larger. Programs have long lifetimes, and the maintenance programmer must not only debug what's there, but extend it into new realms. The longer the program lives, the more likely it is that you'll be brought onto the team well after the fun, easy, "blank sheet of paper" part of the development. The original developers have left, and taken all of their deep understanding of the software with them. The only clues they've left behind are piles of C or Java code which, if printed out, would fill your cubicle.
Have You Got What It Takes?
Here are some of the marks of a good maintenance programmer:
Incredible memory. Maintaining a program is like trying to spot all the typos in the entire Lord of the Rings series, including the names of all those Elves. Being able to dig out the meaning of a symbol that you read three days ago is crucial.
Powers of deduction. "I didn't change anything" from a fellow programmer always means, "I did a bunch of stuff, none of which is supposed to affect anything you're working on." The ability to trace through the entire execution of a program (combined with your amazing memory, just to recall how it's supposed to work) will zero you in on the problems.
Dogged persistence. When debugging the blank sheet of paper, the programmer generally has substantial room to back out and try something different if the direction isn't working out. In maintenance, however, you don't often have the luxury of rewriting large sections of tested, functioning code. Your direction is largely predetermined, and the only question is whether you'll figure it out.
Insatiable curiosity. If a program works today but you don't know why, it's going to make more trouble for you tomorrow. The maintenance programmer can rarely live with "it just works." You have to know why.
Aesthetics. The difference between the Right Thing and the Wrong Thing is usually a matter of intuition, developed over years of practice. The maintenance programmer can often tell with his or her aesthetic sense where a problem is likely to be, before applying the analysis to determine exactly why the code is wrong. This aesthetic sense is able to narrow down a problem to a manageable size.
A delicate touch. The users depending on your program don't want to hear that you can fix all their problems if you just rewrite some enormous piece of the architecture over the next six months. They want their bug fixed or their feature added today, and the rest of the system must remain exactly the way it is. You certainly can't risk breaking three old features when you add one new one. The ability to come in and make the smallest possible tweak is a distinction of the maintenance programmer.
Deep understanding. Unlike the "blank sheet of paper" programmer, as a maintenance programmer you can't avoid APIs you don't understand, language features you don't quite grasp, or programming environments you haven't used. You have to know or be able to quickly learn everything that every programmer who ever worked on the project knew.
Flexibility. You're going to encounter code with every style of indent, comment, and technique, and you won't have the option of reformatting or redesigning every piece of code you touch. You have to be a chameleon, seamlessly merging your code into the existing system, squelching your own style in favor of the good of the system.