分享
 
 
 

技术标准化——福兮?祸兮?

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

诚如Jim Waldo所说,我们生活在一个标准的年代。我们常常不由自主地相信、选择标准。如果一个东西被标准化,我们就认为它开放、稳定、有保障、好用;反之,我们就不敢信任它。

但是,如今的标准也和以前不一样了。在C++和CORBA那里,首先是全世界的人使用它们,他们觉得有彼此兼容的必要,然后为它们订立标准。到了Web Service这里,情况完全倒了个:在看到任何实用价值之前,厂商已经为标准吵翻了天,技术讨论早已变成了政治、商业之争——而作为用户的我们还没用货币投票呢。

太多的标准。我们需要这么多的标准吗?对标准的过度重视甚至依赖是否会损害技术创新和发展?To be standardized or no to be, this is the question.

Artima Weblogs

Why Standards?

by Jim Waldo

May 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 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.

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't be clearly answered, may the standard isn't 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 whenever 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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有