Complexity as a weapon

For years I've lamented the growing perceived and actual complexity of things.

The engine compartment and the dashboard of my 1998 Dodge Caravan are a far cry from the ones in my 1917 American LaFrance and in the late-1970s van I once owned. In spite of this, operating the Caravan is actually easier than operating the LaFrance or the Ford.

The operation is simple in spite of the underlying complexity. That does not mean the underlying complexity is not a worry. I used to be able to repair the engine on the Ford, but did not even bother to get the owner's manuals for the Caravan.

Sometimes there seems to be no reason for the complexity. One of the most common and frustrating examples of this is setting the time on a VCR. It seems vendors go to great lengths to ensure that VCRs will blink 12:00 whenever they are powered up.

In the past, I've assigned blame for such complexity to interface design engineers who have no human factors training. But there may be more to the complexity than that.

Two weeks ago someone at Microsoft leaked an internal document discussing strategies that the company could use to counteract the push by some organizations and companies toward an open source software (OSS) model of software development. An annotated version of the memo has now been posted on the World Wide Web under the somewhat pejorative name "The Halloween Document." Most of the document discusses assertions that Microsoft could make to blunt the appeal of the open source process used by many Internet developers, including Netscape. But a small section of the document refers to the danger that simple systems represent.

The memo says, "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."

This is scary, not because it is a Microsoft person saying this, but because it could explain all too much of what we are now seeing in the standards development world. Many of the standards proposals are far more complex than problems would seem to require.

Once upon a time, simplicity was a design goal for IETF protocols, best expressed in RFC 1958, "Architectural Principles of the Internet." It says, "Keep it simple. When in doubt during design, choose the simplest solution."

We now seem to have purposeful complexity, designed to make it difficult for small organizations and individuals to implement protocols. This is not good.

David Isenberg, the author of The Stupid Network, the other day asked me, "How many IETF working groups are trying to make the 'Net simpler?" The only working group I could point to was the one for Differentiated Services. It's time to get simplicity back as a design goal.