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

原创 2003年05月25日 03:06:00

诚如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

CSDN_Dev_Image_2003-5-25303071.jpg 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.

福兮祸兮?

工作已近6年,不管校园生活还是这6年的工作生活,好像没有碰到让人一直警惕着心况的长者或领导,但如今这样的人出现了,是祸是福? 自己能否受得了这些的煎熬,毕竟自己向来简单明了。或者自己能扛过去,经过这...
  • fftw2010
  • fftw2010
  • 2016年06月06日 16:19
  • 88

医疗产业走进大数据时代:祸兮?福兮?

医疗产业数据量增加储存的要求给医疗产业带来了巨大压力,但有关键信息显示,在这样"追求高质量同时低价格"的服务压力之下收到的效果却是积极的。 背景:各路人士纷纷要求压低医疗费用,而却同时提出面对日...
  • tianshi_1105
  • tianshi_1105
  • 2013年08月13日 10:58
  • 1448

祸兮福兮?--疏忽引发的学习机遇

解答“倒排索引查询”题目(见后)时,我疏忽把题目中的“1[1],提交答案报告时遇到“RuntimeErrror”。 一开始不知道上述疏忽。于是我怀疑自己写的集合求交集、并集和差集的代码出问题。依稀记起...
  • yedouble
  • yedouble
  • 2015年11月21日 11:39
  • 281

谷歌离开 Android中国路祸兮福兮

3月22日夜,随着www.google.cn的域名直接跳转到www.google.com.hk,谷歌中国高唱“离歌”已成定局。“谷歌中国退出事件”又将成为新闻界关注的热点,但作为移动通信终端行业,特别...
  • pet_products
  • pet_products
  • 2010年03月23日 10:27
  • 228

福兮祸兮?- 议Google收购摩托罗拉移动

2011年8月15日晚,据传Google 将以 40 美元现金每股,总价 125 亿美元,收购摩托罗拉移动。其收购总价比照上周五的收盘价格溢价 63%,这次收购正在等待双方董事会批准。如果此事为真,那...
  • sunstars2009918
  • sunstars2009918
  • 2012年03月21日 14:33
  • 2278

天地为炉兮 造化为工 阴阳为炭兮 万物为铜

大暑到了,真是感受到了天地为炉的感觉了芸芸众生在此中煎熬,在教室里不活动,汗都刷刷的往下流闷闷的空气几乎不流动看着周围的学友都在努力,自是也不敢放松了 小朱同志是个教育系的研究生,一次突发感慨:看到一...
  • friendliu
  • friendliu
  • 2004年07月22日 18:34
  • 2162

祸兮福之所倚,福兮祸之所伏

福祸只是代表当时事物发展的短暂结果而已,此时的福可能带来后续的祸,此时的祸也有可能转化为后续的福。在生活中无论是顺境还是逆境,都要以一种平常心对待。在顺境时也不要得意忘形,炫耀,一个人能永远都是在顺境...
  • wbj1234566
  • wbj1234566
  • 2010年02月28日 22:20
  • 953

且夫天地为炉兮,造化为工;阴阳为炭兮,万物为铜。合散消息兮,安有常则?千变万化兮,未始有极,忽然为人兮,何足控抟;化为异物兮,又何足患!

《鵩鸟赋》  单阏之岁兮,四月孟夏,庚子日斜兮,鵩集予舍。止于坐隅兮,貌甚闲暇。异物来萃兮,私怪其故。发书占之兮,谶言其度,曰:“野鸟入室兮,主人将去。”请问于鵩兮:“予去何之?吉乎告我,凶言其灾。淹...
  • vieri_ch
  • vieri_ch
  • 2006年07月17日 13:50
  • 10785

asp.net连接MySQL 浮兮影视

ASP.NET默认的数据库是MS SQL Server,微软的数据库产品。事实上,如果不计成本因素的话,Windows Server + IIS + MS SQL Server + ASP.NET是网...
  • hsx799
  • hsx799
  • 2017年12月24日 23:16
  • 50

【Unity】Shader编程 基础总结

Shader编程一直是一个比较难入门难上手的主题,本篇对Unity Shader编程的一些基础和要点进行了总结。 包括Shader编程相关知识图谱、Shader编程相关数据类型、Shader核心结构体...
  • lotusiki
  • lotusiki
  • 2015年06月19日 11:13
  • 1927
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:技术标准化——福兮?祸兮?
举报原因:
原因补充:

(最多只允许输入30个字)