C/C++ Users Journal October, 2005
Creeping complexity is everywhere these days. It's not enough to keep selling a successful product; each new version must do all the things its predecessor did and a few more. For American consumers in particular, this trend is almost the book definition of progress. And businessmen with successful products think it's great because it raises the barrier to entry for competitors. Neither constituency sees how creeping complexity slows innovation and limits product lifetimes.
I first noticed the phenomenon about 40 years ago, but thought it was confined to the software business. In those days, the IBM System/360 enjoyed a wide spectrum of operating systems, each one more complex than the next. I knew it was out of control for a variety of reasons. Experts argued over whether a particular feature was present, and which release introduced it. Each new release seemed to take longer to get out the door, and was followed with more patches. Large customer sites sometimes employed one person full time to just put change pages in the manual sets, which were way too large for any one person to comprehend.
It wasn't until the minicomputer revolution got well under way that people accepted much simpler software systems, and the complexity clock got set back. In fact, I believe it was the stunning elegance of UNIX and C that practically reset the clock and won us an extra decade of time to sprawl once again. But sprawl we do, nevertheless.
These days, I get occasional glimpses of what Microsoft has to go through to push a major release out the door. They're very professional about it, and they've learned from the past to be sure. But they still labor mightily to get a new batch of improvements working with a great mass of existing code. There doesn't seem to be an easy way to do it.
Our little company Dinkumware is also staging a new product release. We have all the same problems in miniature. We do profit from having only a handful of people to coordinate, but we also are limited by having only a handful of people to do the work. It's a net advantage, on balance. Still, creeping complexity remains our biggest bugaboo.
We software folks are hardly alone. Tana and I just bought a new Saab, to replace the the one we bought new 17 years ago. (It was beginning to show its age.) I was amazed, and somewhat frightened, at all the extra gadgets and features those Swedes have piled on over the years. Lights fade on and off, the steering wheel adjusts up and down, the brakes are way smarter than my trained right foot. The thing is obviously chock full of computers where once relays and on/off switches did the job. It's a great car, but I dread the prospect of a dead battery, either in the car or in the pocket remote control that now takes the place of an ignition key. (The owner's manual has several essays on how to get into, and out of, an inert car.)
I bought my first new car in 1964. It was a German economy car with a high-performance engine. For all its improvements over my dad's 1949 Ford, however, the two cars were more alike than different. Engine adjustments, lights, and switches looked pretty much the same on both cars. I was pretrained to maintain it — and had to, with my income. Perhaps you could argue that the introduction of embedded computers is to blame for the current automotive complexity boom, but that doesn't wash. The luxury cars of the 1960s had plenty of motors, springs, and relays in their stead. I now know how those Caddy owners felt when their front seat wouldn't adjust.
Another recent purchase was one of those GPS dashboard navigators. I read up on 'em and got the very latest with good reviews, a recent model upgrade for a gadget with a strong track record. I got to play with it for 15 minutes before the screen went gray, and stayed that way. Several weeks and many phone calls later, I got it back from the manufacturer. It worked for several hours before the screen went gray again. This time I had enough sense to ask Amazon to swap it for a new one. So far so good.
I won't mention any brand names because I could have just gotten a lemon. I mention the incident because all my interactions with the manufacturer made it clear to me that they are in complexity overload, both with product support and new product development.
I'm rooting for them because I want this gadget to work. And our new Saab. And Dinkumware's new product line. And Microsoft's. And the software industry, in general. Entropy, however, is not on our side.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com