Sincerity, Jim Waldo said, we live in a standard era. We often do not help but believe in the standard. If a thing is standardized, we think it is open, stable, safe, easy to use; contrary, we don't dare to trust it.
However, today's standards are also different from before. In C and Corba, first of all the people around the world use them, they feel that they are necessary and then set up standards for them. In the Web Service, the situation is completely poured: Before seeing any practical value, the manufacturer has already turned all over the standard, and the technical discussion has already become political, commercial dispute - and we have not used money as a user. Vote.
Too many standards. Do we need so many standards? Excessive emphasis on standards and even dependent on technology innovation and development? To Be Standardized or no to be, this is the question.
Artima Weblogs
Why standards?
By Jim Waldomay 18, 2003
Summary
Common wisdom, especially in distributed computing, says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history, and is curtailing innovation and rewarding bad behavior in our industry.
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 do not 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 ITNLOGICAL PATHS in The Quest to Follow Standards Which Have Never Been Implement and aren 'ket.
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 Description hey 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 will not These are the de jure standards groups. And they is the ruin of ou inde.
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 los t 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 not 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 did not 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 are not trying to solve problems in new ways.; they are trying to lead parades, or keep their jobs, or show that they have influence. They are not 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 is not 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.
So the next time you are talking to a manager and he or she tells you that you have to use something "because it is a standard", push back. Ask why only standards can be used. Ask if the standard has actually been implemented, or if the standard will really solve the problem under discussion. For that matter, ask if the manager really knows what the standard is. If any of these questions can not be clearly answered, may the standard is not the way you should approach Your Problem.
Talk back!
Have an Opinion? Readers Have Already Posted 8 Comments About this Weblog Entry. Why not add yours?
RSS feed
If You'D like to be notified whene Jim Waldo Adds a new entry to his weblog, subscribe to his rss feed.about the blogger
Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object- oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he LED The Design and Development of the First Object Request Broker, And Was Instrumental in Getting That Technology Incorporated Into The First Omg Corba Specification.
THIS Weblog Entry Is CopyRight © 2003 Jim Waldo. All Rights Reserved.
