We are living in the era of standards. Technology that is a standard is good because it is a standard; if something is blessed as a standard it can be seen as open, non-proprietary, and gets the blessings of the IT managers and the analysts. Something that is not a standard is closed, proprietary, and to be avoided at all costs. This is the received wisdom in our industry; it is so obviously true that we don't even question it, and we seem to get uncomfortable around those who ask why standards should always be used.

This kowtowing to the god of standards is, I believe, doing great damage to our industry, or craft, and our science. It is stifling innovation. It turns technical discussions into political debates. It misunderstands the role that standards have played in the past. Worst of all, it is leading us down absurd technological paths in the quest to follow standards which have never been implemented and aren't the right thing for the problems at hand.

Let's get back to first principles...standards have historically played two roles in our industry. The first role has been to codify what is already common practice in the industry. Such standards are attempts to capture what everyone is already doing, perhaps ironing out some minor inconsistencies along the way. But such a standards effort is at base a descriptive one. The original IP standard was such a beast; so was the ANSI C standard. Neither attempted to invent much of anything; both simply tried to make clear what everyone was already using. The standards being described were already de facto standards; writing them down was a documentation job that either got it right or missed the mark.

This is very different from a standards effort that attempts to invent the standard from the ground up. Such a standards effort is not descriptive, but rather an attempt to invent by committee. There is no common practice to describe; instead the standards group is trying to tell everyone what they should be doing in the future. The ANSI C++ committee, which started out as a descriptive body, became one of these sorts of standards groups when it was decided that they should "improve" the language. Many of the Object Management Group (OMG) Common Object Request Broker Architecture (CORBA) Common Services groups were this sort of standards body. There are lots of others around now; I'm sure you can name many of them so I won't. These are the de jure standards groups, and they are the ruin of our industry.

Those of you who have been part of a de jure standard effort know what I mean when I say that they turn all technical questions into political ones. Discussions may appear to center around the technology, but the real decisions are made either in setting up the requirements (beware the use case, my son) or in meetings outside of the general discussions between subsets of the committee who trade votes like Chicago precinct bosses. The ultimate threat in such organizations is that some of the founding (or important) members will split off and start a competing standards group, which seems to be happening on a weekly basis in some of these discussions. The real goal in all of this, of course, is to get your competitors to (unknowingly) agree to some approach to technology that you and your company already have in a product (either shipping or ready to go). Then what would otherwise be proprietary can now be seen as an "open" standard. Just an open standard that only you have.

What gets lost in all of this, of course, is whether the technology being blessed by the standard actually helps the customer to solve a real problem. Can the standard be implemented? Will the implementation perform adequately? How much will it cost? All of these sorts of questions are not appropriate in the era of de jure standards.

What is also forgotten in all of this is how fragile the de jure standards have been in the past. I can't think of a single standard that was invented by committee that has survived in the marketplace. The long-standing standards are those that were first de facto standards, and were described (no invented) by the standards bodies.

Such standards didn't start out in a standards body. They started out solving problems. Because they solved the problems, people used them. The use drove the standard, not the other way around. This allows innovation, this allows technical progress. Things that work get used by people who are trying to solve problems.

This does take the decision making power out of the hands of the managers, and the IT departments, and the technical analysts. They aren't trying to solve problems in new ways; they are trying to lead parades, or keep their jobs, or show that they have influence. They aren't the engineers that can actually understand the solutions, but they do (for the most part) understand politics. Standards groups cater to their expertise, not the expertise of the engineer.

Of course, this hard dichotomy is something of a caricature. There are substantive discussion of technical merit in standards groups that are trying to invent. But that isn't all that goes on. And certainly there is little evidence that the best technology wins in such groups. Just look around you for evidence of that.