ジェイミー・ザウィンスキーの法則はどういう意味ですか？

Jamie ZawinskiのSoftware Envelopment の法則を適切に説明する必要があります。

すべてのプログラムは、メールを読み取れるまで拡張しようとします。拡張できないプログラムは、拡張可能なプログラムに置き換えられます。

これまでのすべての答え（およびコメント）は、声明の前半に完全に焦点を当てているようで、重要な後半が後半である場合、「膨張」についてのコメントになります。できます。

これはソフトウェアの肥大化に関するものではなく、市場の現実に関するものです。人々はシンプルな製品が欲しいと言うかもしれませんが、実際の使用法を見ると、慣れるのはユーザーがもっとできることであり、結局は機能の少ないツールを交換することになります。

問題の一部は、「単純な」という言葉が紛らわしいことです。「leave開」と同様に、ほぼ完全に反対の2つのことを意味します。人々が望むのは、複雑なタスクを単純化するものです。それは「良いシンプル」であり、それを正しく行うにはかなりの複雑さが必要です。しかし、一部の人々がそれを解釈するのは、人々が単純化した、またはミニマリストなものを望んでいるということです。このコンセプトにはニッチな魅力があるかもしれませんが、全体として、製品を設計するときに焦点を当てるのは間違った種類の「シンプル」です。あなたの仕事がどれほど良いものであっても、新しい機能のリクエストは寄せられ続けます。

例として、仕事中に取り組んでいるプログラムがあります。おそらく聞いたことがないかもしれませんが、私たちは専門産業であるメディアコントロールのマーケットリーダーです。私たちのプログラムは、おそらくあなたのお気に入りのテレビやラジオ局を実行します。顧客はそれを愛し、彼らはそれがだと言うので、より良い彼らが働いてきた何よりも。

それはまた巨大です。EXEのサイズは65 MBを超え、約400万行のコードがあり、150を超えるテーブルを備えたデータベースが10年以上の作業を経て構築されています。それでも、新しいステーションやネットワークにインストールしようとするたびに、ワークフローに不可欠なものが1つまたは2つあるようで、サポートはありません。そうしないと、顧客は既に使用しているシステムから切り替えたくないため、新しい機能を追加することになります。繰り返しますが、顧客はそれを気に入っています。

これはかなり前に起こったことを理解する必要があり、その時点では、特定のユーザーに対してコンピューターが一度に複数のプログラムを実行できることはまだ主流ではありませんでした。パーソナルコンピューター用のDOS（および場合によってはWindows 3）およびUnixユーザー用の文字ベースの端末（X11が搭載されているのはごく一部）。

あなたがしなければならなかった電子メール得ていたかどうかを確認するために、この平均終了あなたが現在何をしていたが、メールプログラム、読み取りメールを起動して終了メールプログラムを、古いプログラムを再起動します。現在のプログラムでメールを読むことができれば、それをすべて回避できることがわかると思います。

したがって、現在のプログラムがメールを読めなかった場合は、読めるようにする（これはMITの学生だったことを思い出してください）か、できる別のプログラムに切り替えてください。

最近では想像するのが難しいですが、自分自身を 、タブや余分なウィンドウがない単一のブラウザウィンドウにブックマークを使用しないことできます。

他の皆がすでに述べたように、「法律」はソフトウェアの肥大化に関するユーモラスな観察ですとスコアのクリープ、Greenspunの第10規則に非常に似ています：

十分に複雑なCまたはFortranプログラムには、Common Lispの半分の、アドホックで、非公式に指定され、バグに乗った、遅い実装が含まれています。

説明するように法律は、Netscapeブラウザで以降のNetscapeメール＆ニュースとのZawinskiの仕事を反映し、ここで、によっても、自分自身：

次に、Netscape Mail and Newsクライアントのバージョン2.0〜3.0を設計し、Terry Weissmanと実装しました。これは、、ソフトウェア開発法の：

「すべてのプログラムは、メールを読むことができるようになるまで拡大しようとします。拡大できないプログラムは、読み取り可能なものに置き換えられます。」

Netscapeブラウザは、当時最も人気のあるブラウザでしたが、多くの機能を備えていると批判されることがよくありました。恐らく、GeckoとTridentの2つのレンダリングエンジンをサポートした最後の（人気のある）ブラウザであると誤解していません。たとえば、Ben Goodgerは、Netscapeの肥大化を、Firefox ^1の作成につながる（多くの）理由の1つとして特定しています。

MozillaのUI機能不全

Netscape製品のユーザーインターフェイスデザインのほとんどは、Netcenterの要件に対応するNetscapeスタッフによって行われたため、Mozillaユーザーインターフェイスが影響を受けました。Netscapeがニーズに合わせて製品を構築できるクリーンなコアである代わりに、Mozillaスイートはまったく正しいとは感じませんでした。Netscapeのプライベートソースリポジトリ（「商用ツリー」）のオーバーレイによって埋められるだけである、厄介なUI構造が多数ありました。

この機能不全をさらに悪化させたのは、プロジェクトが、CPD内の異なる、時には接続の不十分な部門の100人以上のエンジニアによって開発されていたときです。Netscapeは過去数年で急速に成長しており、他の人からより多くの支援が必要であることを示唆する能力を備えた不均等な雇用バーエンジニアがいたため、機能の設計と実装にはあまりにも多くの自律性がありました。ユーザーエクスペリエンスの支援はまばらであり、その結果、アプリケーションは急速に肥大化しました。

_{¹ Ben Goodgerの今は機能していないブログのアーカイブバージョンから。}

それはありません本当の法則（適切に管理されていない場合）、それがどのようにソフトウェアプロジェクトの風刺コメントですので、大規模で複雑な成長することができ、彼らは何とか最終的に（それは持っていない場合でも、電子メールのリーダーを含め何もプロジェクトの本来の目的で行うために） 。私がかつて持っていたマネージャーは、「十分に複雑なシステムには、中にLISPの実装が含まれている」という似たようなフレーズが好きでした。

これは、一部のソフトウェアプロジェクトがどのように機能を拡張および追加し続けているかのコメントです。

多くのプロジェクトは、必要かどうかにかかわらず、機能の追加に抵抗できないようです。

論理的な結論は、すべてのソフトウェアがメールを送信することになります。

Scope Creepも参照してください。

少なくとも3つの表示方法があります。

1つは、メールの読み取り自体を無視し、ツールの本来の意図とは関係がないかもしれないにもかかわらず、人々はほとんどすべてのタスクに柔軟に対応できる製品を好むように見えるという声明と見なすことです。我々はそれをこのように見ると、Photoshopのような製品のプラグインアーキテクチャは、それがいることを柔軟に十分であるため、メールの読み取りが異常ではありませんサポートしていない可能性があり、メールの読み取りをサポートしていないとしても（私の知る限り）ものの、そのようなプラグインが存在します。この視点は、「柔軟性が専門化に勝る」ため、より明確に要約することもできますが、元々はそうではありません。

2番目の表示方法は、Jamie Zawinskiの焦点が狭いため、Photoshop、PowerPoint、ほとんどのゲームなど、何年も前から存在し、メールの読み取りをサポートせず、 tは、いずれかを行う他のものに置き換えられているようです。

3番目は2番目とは少し反対になります。ほとんどの人はバックグラウンドでメールリーダーを実行しているため、本質的に製品間の統合は事実上メールの読み取りがすべてに統合される程度に行われたためです。その時間と十分にすばやく/簡単に切り替えることができ、他のものとカットアンドペーストするなど、メールリーダーが別のアプリケーションとしてパッケージ化されている細部が無関係になります。