C/C++ Users Journal February, 2005
"Progress is our most important problem."
I don't know if Brian Kernighan coined this puckish twist on an old tag line, but he certainly enjoys repeating it. And no, it doesn't mean that our problem is to find ways to make progress. Rather, it's a wry observation that many things billed as progress cause more problems than they solve.
Consider the simple act of fixing a bug in a software product. It should be obvious that this is progress. But that's only true if you don't introduce yet another bug in the process. Even if you avoid adding a new bug, you can still lose ground. Your fix can be fragile, because you don't understand the code well enough to think through all the special cases. Or you have to make a structural change to the code, and minimize the work by introducing a kludge or two. (Yes, we all do it.) In any of these cases, you've made the code harder to maintain, so the next time it's touched, by you or anybody else, the odds are greater that a change will introduce more problems than it solves.
Making progress like this is borrowing against the future. It leads to a form of atherosclerosis, a hardening of the arteries that makes code ever less flexible and more expensive to keep alive. At some point, it becomes cheaper to rewrite the code than revise it yet again; at that point, the code is effectively dead. You can delay code death by writing it as cleanly as possible to begin with, with maintenance ever in mind. Then you make maintenance changes with equal care. But the only way to keep a nontrivial program healthy indefinitely is to budget time for periodic review and cleanup. I know very few enterprises that do that sort of thing. I know fewer managers who would count preventive maintenance as anything resembling progress.
In fact, about the only thing that most managers consider progress is adding new features. You can't blame them, given the usual market forces that drive product evolution. Whatever the product did well last year is now old news. You can't sell customers an upgrade on the promise that they'll just get the same old same old with fewer bugs. It's a much easier sell to point out the new functionality, particularly if at least some of it was requested by past customers. But you can seldom remove any existing features, no matter how quaint they have become, so the product gets nothing but bigger.
I won't let the developers off the hook here, either. We programmers love to tinker, and we're always thinking of stuff we could do better the second time around. Fred Brooks long ago identified what he called the "Second System Effect." It's the tendency to pile into the first major upgrade all the stuff left out of the first version. In my experience, you have to write everything at least three times before you start getting it right. It's a rare development project that budgets time for that sort of thing. Managers would rather the developers were making, ah, progress.
Creeping featurism is bad enough, but we seem to be suffering an epidemic of galloping featuritis. Perhaps it's those multigigabyte disks that are now commonplace, and the CDs full of compressed files that feed them. Most people don't even notice the loss of the odd gigabyte of real estate to a bunch of extras you barely know exist and have no intention of ever using. I can live with that trend, mostly, but when the working code itself silts up, I start looking for a simpler substitute.
Over the years, I've watched more than one product succumb to terminal obesity. I was an early adopter of Ventura Publisher. But it changed ownership a couple of times, getting fatter and harder to use with each overhaul. Corel finally ended up with it and paved over its essential virtues, including the ability to maintain text and pictures with the utilities of your choice, not just through the Ventura engine. Of course, they did add lots of clip art to make up for that, but I didn't need clip art.
Quicken was the first product that actually made it easy for me to balance my checkbook on my computer. I was an early and persistent adoptee. But after a few version changes, I got tired of learning ever more complex interfaces. I got off the upgrade treadmill about four versions ago, and I've never been sorry. Now I'm wishing I'd stopped one version back with Laplink, another old favorite. Sigh.
Programming is supposed to be about controlling complexity. But I guess you can't keep entropy from increasing. That's progress, thermodynamically at least.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com