by Jim Waldo
December 9, 2003Jim Waldo
2003年12月9日
(Original article: Jim Waldo, Worse is worse
. Japanese translation by Hisashi Morita.)
Summary概要
The classic essay on "worse is better" is either misunderstood or wrong. And in citing it in our design arguments, we short change both our customers and our craft. I revisit this essay, and reflect..."worse is better"に関する有名なエッセイは、誤解されているか、あるいは間違っているか、そのどちらかだ。我々が設計に関する主張でそれを引用するとき、我々は我々の顧客と我々の作品の両方をごまかしていることになる。私はこのエッセイを改めて取り上げ、考えてみたい。
Recently, I was interviewed by a reporter who was doing a story on the difference between east coast engineers and west coast engineers (yes, that old chestnut is again being revisited). This in turn got me thinking about Dick Gabriel's classic note "Worse is Better", which is often credited with first articulating the distinction between the MIT (or east coast; after all, what else is there on the east coast) approach to engineering (do the right thing, no matter how complex it makes the code) and the Berkeley (or west coast) approach to engineering (make the code simple, even if it makes the user do more work). 最近、東海岸の技術者と西海岸の技術者の違いに関する記事を担当しているリポーターからインタビューを受けたことがある（そのとおり、この手垢のついた話がまた取り上げられているというわけだ）。そのせいでDick Gabrielの有名な"Worse is Better"の記事のことを考えるようになった。これはしばしば、エンジニアリングに対するMIT式（あるいは東海岸式――結局のところ、東海岸には他に何があるというのか）のアプローチ（コードがいくら複雑になろうとも、正しいことをせよ）と、Berkeley式（あるいは西海岸式）のアプローチ（ユーザの負担が増えたとしても、コードを単純に保て）の違いをまずはっきり述べているものとして知られている。
The notion that worse is better has become something of a truism in the programming industry. The usual examples are the C language (worse than lisp, but it dominated anyway), Unix (or more recently, Windows) as opposed to Multics or VMS, and (in a completely different arena) VHS tape over Beta. Each of the dominant technologies, it is pointed out, was worse than the alternative, but the worse technology became the standard anyway. The moral to the story, or the reason that people bring the principle up in argument, is to convince whoever is on the other side of the argument that we should set our sights on the quick and dirty, less elegant solution to a problem, because "worse is better." worse is betterという概念は、プログラミング業界において自明のことのように扱われはじめた。よくある例はC言語（Lispより劣っているがとにかく浸透した）とUnix（あるいは最近ではWindows）をMulticsやVMSと対比させ、（全く違う分野では）VHSテープをBetaと比較するものだ。優位に立つ技術はどれも、指摘されるようにもうひとつの選択肢よりも劣っていたが、劣っているほうの技術が結局標準となる。この話の教訓、あるいは議論でこの原則を持ち出す人の理由は、やっつけ仕事のがさつな解決策に注目すべきだと議論の相手を説得するためだ。なぜなら「worse is betterだから」。
Of course, this received wisdom is just so much crap. The arguments simply don't hold up. But the damage that this principle has done to the technology industry is real, and we should start pushing back before we do any more harm than we already have done. もちろん、この一般に信じられている知恵は全くのでたらめだ。この主張は明らかに正しくない。しかしこの原則がテクノロジー業界に与えた損害は大変なもので、我々は、これ以上損害を広げてしまう前に立ち上がって押し戻すべきだ。
First, the arguments. Gabriel's original writing (which can still be found, like everything else, either through Google or by going here) makes an interesting read, and a number of good points. Reading it again not only reminds one of how well it is written, but debunks a lot of the usual common knowledge about the article. For example, the piece never contrasts the east coast and west coast engineering styles; the two groups it talks about are the MIT/Stanford style (one group) and the New Jersey style of design. Not nearly so interesting in these days as the notion that the contrast in styles is between west coast and east coast. まず、主張について。Gabrielのもともとの著述（今でもGoogleで探すかここに行くかすれば読める）は興味深い読み物で、良い点がいくつもあった。これを読み返すと、それがいかによく書かれているかを思い出すだけでなく、一般にこの記事について信じられていることがの多くが誤りであると気づく。例えば、記事では一度も東海岸と西海岸のエンジニアリングスタイルの違いを対比したりしていない。記事で扱われている2つのグループは、MIT/Stanfordスタイル（一つのグループ）とNew Jerseyスタイルの設計だ。今時の、西海岸と東海岸におけるスタイルの対照という思いつきほどに面白いものではない。
The rest of the paper is an excellent analysis for why Lisp lost out to C as a programming language, even though Lisp was a superior language. Or at least superior on the grounds that Dick found most important. But this doesn't necessarily show that Lisp was in fact superior to C; it can just as easily be taken to show that the metrics that were cited in the article were not the ones that were taken to be most important by those choosing a programming language. The fact that C produced faster code, was easier to master, was easier to use in groups, and ran well on less expensive hardware were not considerations that Gabriel found important. But others did. On those metrics, the dominance of C as a programming language was an example of better is better, not worse is better. 論文の残りは、Lispがより優れた言語であったにもかかわらず、プログラミング言語としてCに負けた理由の、素晴らしい分析だ。言い換えれば、少なくともDickが最も重要だと思った基準において優秀だったにもかかわらず。しかしこれは必ずしもLispが実際にCよりも優秀であったということではない。記事中で引用されている基準が、プログラミング言語を選ぶ人にとって最重要なものとは限らないということが、簡単に読み取れる。Cは高速なコードを生成し、ものにしやすく、グループで使うのに適しており、より安価なハードウェアでうまく動いたという事実は、Gabrielにとって重要ではなかった。しかし他の人々はそれらを重視したのだ。それらの基準に基づいて言えば、プログラミング言語としてCが普及したことは、better is betterの例であり、worse is betterの例ではない。
The old chestnut of beta and vhs is open to the same sort of alternate interpretation. On the "worse is better" interpretation, the superior quality beta was beaten out by the clearly inferior vhs tape format because of some inexplicable perversity of human nature (or the machinations of clever marketing people, or the hubris of Sony, who owned the Beta brand). But the vhs tapes were capable of recording longer programs on a single cassette, and could be played on cheaper recorders, and had a number of different suppliers. Thus there were a set of metrics on which vhs was the superior technology, and these metrics seemed to be the ones that most in the market found to be important. Vhs beat out beta not because worse is better, but better in some dimensions (cost, time to record) beat out better in other dimensions (picture quality). betaとvhsの陳腐な話も、同様に別の解釈ができる。"worse is better"に基づく解釈では、優れた品質を備えたbetaは明らかに劣ったvhsテープ形式に負け、その原因は、人というものの不可解な強情さ（利口なマーケティング部門の策略や、Betaブランドを持っていたSonyの傲慢でもいい）に帰せられる。しかしvhsテープは一つのカセットでより長時間録画でき、より安価なレコーダーで再生でき、さまざまなメーカーから製品が提供されていた。ゆえに、vhsのほうが技術的に優れていたと言える基準があり、それらの基準は市場の大半によって重視されたものであったように思える。vhsがbetaを打ちのめしたのは、worse is betterが理由ではなく、いくつかの側面（コスト、録画時間）において優れたものが、他の側面（画質）において優れたものを打ちのめしたのだ。
Even the case of Unix vs. Multics misses an important point. While
Multics may have been a better operating system, Unix had the twin
advantages of actually existing, and running on a wide variety of fairly
cheap hardware. Windows (and DOS) ran on even cheaper hardware, and
though it was easy to argue on any technical grounds that you wanted
that Unix was a better OS than DOS, the property of existence on really
cheap hardware turned out to the the metric of goodness that appealed to
the customer. The emergence of Linux as a real choice is beginning to
give us more evidence in this particular choice; perhaps a better OS
In all of these cases, there is an alternate interpretation of the choices that were made that lead us to the conclusion that worse is not better. Instead, what we see is that better is a complicated notion, and can depend on a variety of different metrics. It may be disappointing to find out that what we geeks think of as better may not be what our customers think is better. But finding this out shouldn't surprise us too much. これらのケースすべてにおいて、選ばれた選択肢には、悪いほうが良いわけではないという結論を導く別の解釈がある。むしろ我々に分かるのは、優れている（better）とは複雑な概念であり、さまざまな別々の基準に依存しうるということだ。我々geekたちが優れていると考えているものが、我々の顧客が優れていると考えているものではないかもしれないと悟るのは、がっかりすることかもしれない。しかしそうだと知ってもさほど驚くことではないはずだ。
Of course, worse is better is a much catchier slogan than better depends on your goodness metric or some other, equivalent phrase that would actually reflect what was going on. And there is wisdom and insight in the original article that can be used by designers, even under the catchier (but less historically accurate) slogan. もちろん、worse is better（悪いほうが良い）のほうが、better depends on your goodness metric（優れているかどうかは優良さを測る基準による）などの現実を反映した表現よりも、スローガンとしてずっと心を捉える。そして元の記事には、たとえキャッチーな（歴史的には正確でない）スローガンの下でさえ、設計者が参考にできる知恵と洞察が含まれている。
My problem with the slogan is that it has become a catch phrase for those who either haven't read the original article, or have read it and either have forgotten what it really talked about or never understood it in the first place. As a catch phrase, it is often used to justify shoddy design, or following the crowd rather than doing what is right, or as short-hand for the real claim that our customers are too stupid to either appreciate or deserve high quality products. Why spend the time doing things right, this line of reasoning goes, when we all know that worse is better. You are far better off giving the customer something that you know is less than what you could produce, because they (those simple customers) will think that it is better. 私がこのスローガンを問題にしているのは、元の記事を読んでいなかったり、あるいは読んだけれどもその真意を忘れてしまったかそもそも理解しなかった、そんな人たちによって利用されるキャッチフレーズになってしまっているところだ。この文句はキャッチフレーズとして、粗悪な設計を正当化したり、正しいことをせずに大勢の後を追ったり、あるいは略語として、自分たちの顧客は馬鹿すぎて高品質な製品など正しく評価することもできないし必要もないという意味で、しばしば使われる。この手の論法はこう続く。なぜ正しくやるために時間を費やしたりするんだ、誰もがみんなworse is betterだと知っているというのに。顧客には、提供できるよりも劣っていると分かっているものを与えておけばいい、彼ら（あの無知な顧客たち）はそれが優れていると思うだろう、と。
The end result of this thinking is sloppy products that don't work, are hard to use, or are unreliable (or all of the above). We try to convince our customers that this is the way software has to be, and then turn around and convince ourselves that they won't pay for anything better. But we short-change our customers, and we cheapen our craft, when we put up with this sort of thinking. When the original article was produced, I don't think that this is what the author had in mind; even if it was, it is time for us to reject the simple-minded interpretation of the slogan, and start putting out software that really is better (on the dimension of goodness that our customers have, not necessarily our own). この考え方の行き着くところは、役に立たないか、使いにくいか、あるいは信頼できない（またはこれら全部を併せ持った）ずさんな製品だ。我々は顧客を説得して、これがソフトウェアのあるべき姿だと信じ込ませる。そして振り向いて自分たち自身に向かい、顧客は優れたものにお金を払う気はないのだと信じ込ませる。しかし、この手の考え方を受け入れている時、我々は、我々の顧客をごまかし、我々の作品を貶めているのだ。元の記事が生み出された時、それが著者の意図するところだったとは、私は思わない。仮にそうだったとしても、我々はこのスローガンを愚かしく解釈するのを止め、そして（必ずしも我々自身のではなく、顧客の持つ優良さの基準において）本当に優れたソフトウェアを送り出しはじめるべきだ。
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. Jim WaldoはSun MicrosystemsのDistinguished Engineer（特別招聘技術者）であり、同社ではJavaベースの分散プログラミングシステムJiniのリードアーキテクトを務めている。Jini以前はJavaSoftおよびSun Microsystems Laboratoriesで働き、オブジェクト指向プログラミングおよびシステム、分散コンピューティング、およびユーザ環境の分野で研究に従事した。Sunに入社する以前は、Apollo ComputerとHewlett Packardに8年間勤務し、分散オブジェクトシステム、ユーザインタフェース、クラスライブラリ、テキストと国際化の分野に取り組んだ。HPでは、最初のオブジェクトリクエストブローカーの設計と開発を率い、その技術が最初のOMG CORBA仕様に取り込まれるよう尽力した。