In “Software Maintenance is a Solution, Not a Problem” (an excerpt from Software Conflict 2.0), Robert L. Glass says that “maintenance is one of the toughest tasks in the software business.” Indeed.

Why is maintenance so tough? Glass provides a list of seven reasons, which he says were supplied him by an anonymous reviewer:

‘Maintenance is:

• intellectually complex (it requires innovation while placing severe constraints on the innovator)

• technically difficult (the maintainer must be able to work with a concept and a design and its code all at the same time)

• unfair (the maintainer never gets all the things the maintainer needs. Take good maintenance documentation, for example)

• no-win (the maintainer only sees people who have problems)

• dirty work (the maintainer must work at the grubby level of detailed coding)

• living in the past (the code was probably written by someone else before they got good at it

• conservative (the going motto for maintenance is “if it ain’t broke, don’t fix it”)’

I don’t disagree with any of these as characterizations of how we perceive maintenance. But the list exposes an elitist viewpoint by suggesting that “detailed coding” (is there any other kind?) is a grubby little task. Why is coding grubby? Because it doesn’t involve a lot of design and fancy UML modeling? I’m not sure how else one might interpret this viewpoint; I hope it’s not the viewpoint of Glass. My contention is that it’s this arrogance that’s at the true root of the problem. More on that later.

One big mistake we make is taking such a challenging job as maintenance and putting our least capable programmers on it. Glass recognizes this as a problem, and presents a list of “four simple steps to better software maintenance.” The first step involves finding “ways to attract people to the maintenance task.” Here’s step number four:

‘Emphasize “responsible programming.” The maintainer typically works alone. The best way to maximize the effectiveness of this kind of worker is to make them feel responsible for the quality of what they do. Note that this is the opposite of the now-popular belief in “egoless programming,” where we try to divest the programmer’s personal involvement in the final software product in favor of a team involvement. It is vital that the individual maintainer be invested in the quality of the software product if that product is to continue to be of high quality.’

As part of a conclusion, then, Glass recommends the egotistical programmer, the high capability developer, to be the hero of the maintenance world. We boost the ego of maintenance programmers by putting them into the corner and saying, “it’s all yours, baby! Make what you will of it.” It’s a really interesting concept that misses the mark entirely.

Glass is following Weinberg’s Bolden rule¹: “if you can’t fix it, feature it.” Unfortunately, there’s only so much polishing you can do to a turd before it exposes itself by smearing everywhere. Sometimes, a turd is a turd. Glass’s list of why maintenance is so tough should be enough to convince us of that.

We have a difficult enough time finding qualified individuals to build software. Suggesting to them that they will be shining shit is a sure way to scare them off. Maybe we need to invest in a different line of thinking. Maybe the better solution is to start digesting some bran to eliminate the toughness of maintenance.

We got into this mess partly because of individuals with high egos. “My code don’t stink. I don’t have to refactor my code because it rocks, and it works, and it’s darn clever. Tests? My code don’t need no stinkin’ tests!” So now, we expect the same attitudes to get us out of this mess? A lot of bad code comes from the fact that hot-shot developers know they’ll never be stuck with maintaining it (I have at least one good story that supports this contention).

Sure, bad code doesn’t derive only from hot shots slinging out clever code. It derives from novices who don’t know better, or from more senior but apathetic developers. If the egotistical programmers were more invested in the team, perhaps they’d find out just how bad the code of their teammates is. They might even discover that there’s a less clever, more direct way to solve their own programming problems. Ultimately, they might want to do something about it.

The way to fix code quality is to use the team, not suggest that team ownership of code is part of the problem. Peer pressure can go a long way to improving code quality, as long as you have enough people who care. If we put a hot-shot cowboy coder in the maintenance role to save the day, however, they’ll just go right back to creating unmaintainable code.

Even closer to the core of the problem is how we usually give maintenance programming a separate, lower berth. The better way of looking at it, as many have suggested, is to consider that we’re in maintenance mode the minute we add the first new line of code to an existing system. We’re all maintenance programmers, and we’re all in this boat together. So what are we going to about it? I don’t think sending Robert off into the corner to be the hero is going to help the rest of us anytime soon.

We need to learn more about design, and about how to continually ensure that our code exhibits high quality design. Based on what I’ve seen, “we” includes the high-capability cowboys as much as the novice or the apathetic old hand. We need to always understand the design impact of introducing new features into the system, and we need to learn how to do something about such negative design impacts. We need to make sure that maintainers (that’s us, remember) have the documentation we need to do our job, and that we can trust the documentation. We need to ensure that we can dispense of the old adage “if it ain’t broke, don’t fix it” by ensuring we have built enough tests, so that we can improve the software quality with confidence.

Maintenance is indeed “intellectually complex,” and does require “innovation while placing severe constraints on the innovator.” But we can say the same about any software development. Maintenance should be no more or less special, no different, than the rest of it.

Ultimately, the egotistical programmer alone can only solve so much. It takes a team committed to solving the bigger problems, so that we can shrink the above list of seven reasons.

Share your comment