3 ポイント 投稿者 GN⁺ 2025-05-14 | 1件のコメント | WhatsAppで共有
  • ソフトウェア最適化を本当の優先事項に置けば、予想以上に多くのシステムが 旧式ハードウェア 上でも動作できる
  • 希少なコンピューティング資源に 市場の価格シグナル が働けば、より効率的なソフトウェアを作る圧力が強まる
  • インタープリタ言語と マイクロサービス ベースの製品を、モノリシックなネイティブコードベースへ作り直す方法がその一例となる
  • ただし、超低コスト・高スケーラブルなコンピューティングがなければ、革新的な新製品 を試し市場に出すことははるかにまれになる可能性がある
  • 性能最適化だけでは十分ではなく、安価でスケーラブルなコンピューティングが製品実験とリリース頻度を左右する

最適化優先の思考実験

  • ソフトウェア最適化が本当の優先事項なら、予想以上に多くのシステムが 古いハードウェア 上でも運用できる
  • 希少なコンピューティング資源に価格シグナルが強く働けば、市場はより効率的なソフトウェアを求めるようになる

実現方法と制約

  • 一つの例として、インタープリタ言語と マイクロサービスベースの製品 をモノリシックなネイティブコードベースへ作り直すことが挙げられる
  • ただし、超低コスト・高スケーラブルなコンピューティングがなければ、革新的な新製品 ははるかに少なくなる可能性がある

1件のコメント

 
GN⁺ 2025-05-14
Hacker Newsの意見
  • 市場はバグが多く非効率なソフトウェアも、完成度の高いソフトウェアと同じくらいよく買う傾向があり、そのどちらかは作れる中で最も安いソフトウェアだ、という理屈が成り立つ
    これは「レモン市場」の話に似ている。市場はすべての商品が高品質であるかのように売るが、限界費用を下げるためにひそかに品質を落とす。買い手は購入前に高品質と低品質を見分けられないため、需要が人為的に似通ってしまい、その原因は情報の非対称性にある
    AIではすでにそうなっており、今後さらに悪化するだろう。ユーザーは精巧な機械学習アプリと、洗濯機の脱水コースをAIと呼ぶものを区別できない。AIラベル自体が価格プレミアムを生み、ユーザーは洗濯機に大幅に払いすぎることになる
    ひどいソフトウェアを技術者や専門家が設計し書いたものだと信じて過払いするのも、本質的には同じだ。ソフトウェアの99%はIC1〜3が書いており、ほとんどのテック企業ではQA担当者1人が「受け入れ基準を満たす」以上に品質を高める唯一の仕組みになっている。たまにインターンの集団が「LGTM」の呪文を唱えるが、それすらまれだ
    https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...

    • 品質で差別化してソフトウェアスタートアップを作ろうとして、あまりに当たり前の気づきを後から得た
      より良い製品なら人々を説得でき、バイラルに成長するはずだと確信していたが、そうはならなかった。成長はしたが遅すぎて、損益分岐点に達する前に数年で資金が尽きた
      気づいたのは、競争市場では低コスト、つまり低品質が競争優位になるということだ。製品の規模が大きくなるほどコスト削減圧力も強まり、人々は安いものを求めるため、誰かが「コスト」、つまり品質を削ってより安くする。会社は生き残って利益を出すために必要な最低限だけを支払う
      若い会社が高品質を作ろうとしたり、一時的に支出を増やしたりすることはあるが、結局は安定した平凡さへ滑り落ちる流れが生まれる。これはレモン市場とは少し違い、市場の崩壊というより、あちこちが平凡になる結果に落ち着くように思う
    • ここでは「高品質」という表現がかなり多くを背負っている。低性能がすなわち低品質だという含意が見えるが、このスレッドで性能が低いと言及されているTeams、Slack、Jiraなどには、いずれもはるかに高速な競合製品がある
      しかし平均的な人にSlackと高速なIRCクライアントであるWeechatのどちらかを選ばせたら、ターミナル風UI、ビデオ通話なし、Webhook連携なし、カスタムアバターや絵文字なしのほうを低品質と見る可能性が高い
      性能も機能の一つだ。Internet ExplorerがChromeに押された大きな理由も、登場当時のChromeがはるかに速かったからであり、Python開発者がuv/ruffへ急速に移行しているのも性能改善が理由だ。ただしSlackの起動が10msではなく5秒かかる程度になると、気にする人は非常に少なくなる
    • 必ずしもレモン市場ではないと思う。レモン市場には情報の非対称性が必要だ
      バグの多いソフトウェアでそういうことが起きる場合もあるが、概して人々はより少なく支払いたがり、その過程でいくつかのバグは受け入れる。すべてのコード行を複数のエンジニアがレビューし、厳格なQAに多くの時間を費やす手順を踏むなら、いくら請求しなければならないかを考えればよい
      パドヴァに住んでいたとき、小さな書店向けのソフトウェアを作ったことがある。友人だったので素早く作り、高い料金は取らなかった。完璧ではなかったが、問題が起きれば直したし、問題も多くなく、友人はその取引に満足していた。安く請けていると分かっていたので、彼にも忍耐があった
    • 大企業で、ひどい人事、経費精算、勤怠、保険ポータルを強制的に使わされたことがあり、料金を払っている人たちは実際に製品を見たことがあるのかと疑うほどだった
      もし自分たちのチームが顧客に「プロジェクトは終わりましたが、このバックオフィスプラットフォーム並みにバグとUIの悪夢が多いです」と言ったら、叱責され、降格されるか解雇されるだろうと何度も話していた
    • 市場が実際に買っているのは、バグのないソフトウェアではなくサポート
      ここには人的サポートが乏しいGoogleのような会社も含まれる。サポートはさまざまな形で現れる。ドキュメント、動画、ブログのような情報があり、「お母さん、Googleはこう使うんだよ」と助けてくれる人がいて、OS・ブラウザ・形式といった利用対象への対応があり、Excelのように自分の作業方法そのものを支えてくれるものもある
      最後に実際の人間がいる。これが地球上で最悪のERPすら生き残らせる最大の要因だ。マーケティングと営業もサポートがあるというシグナルになる。企業顧客にエンジニアしか見えない場合、それは悪いシグナルかもしれない。開発者は他のことができない場合が多く、その「他のこと」が重要なサポートだからだ
      良い製品でもサポートがなければ死ぬ。より悪い製品と戦うには、自分のチームのコストを下げるために、バグ、性能問題、プラットフォームのようなサポート需要を減らすのが賢明だが、別の次元のサポートは必ず追加しなければならない。小さなチームにとって最も簡単なのは、最も希少なサポート資源であるを付けることで、その次には創意工夫が必要になる
      また、利点をうまく伝えなければならない。「コードを所有できること vs プロプライエタリ製品」のように、特定の種類のサポートをより重視する人もいる。多くの人は、コードよりもサポートのあるプロプライエタリ製品を好む
  • 1980年以降、コンピューティング性能はおおむね1000倍向上したと見ることが多い
    動的配列の境界チェックに5%のコストがかかるとしても、実際にはそれよりずっと小さく、あらゆる場所で有効にしてもコンピュータはせいぜい950倍速い程度になるだけ
    1980年に戻って「950倍速く、大きなカテゴリのメモリ安全性脆弱性がなく、デバッグが数桁は簡単なコンピュータ」と「1000倍速いが、ソフトウェアは相変わらずバグだらけ、あるいはさらに悪く、デバッグが悪夢のようなコンピュータ」のどちらかを選べと言われたら、人々は950倍だけでも衝撃を受けていたはず
    ところが私たちが選んだのは後者で、個人的には1000倍派が他の人々を台無しにしたと思う

    • ただし、その1000倍を境界チェックに使ったのではなく、数多くの抽象化レイヤーと非効率に浪費した
    • バグが多く遅いベンダー製ソフトウェアをSparc 20で動かさせたところ、ベンダーはUltraを求めて強く抗議した
      結局、彼らがSparc 20で効率よく動くように最適化すると、会社がより広い市場で成功する基盤ができた。最適化は競争優位として扱うべきであり、場合によっては最も重要な競争優位かもしれない
    • 配列の境界チェックのコストは、そこまで単純には働かない。画像処理アルゴリズムがピクセルあたり2命令を使う場合、アクセスごとにチェックを追加するとコストが3〜4倍になることがある
      そのため境界チェックを強制すると、特定の作業ではその言語が競争力を失う
      大多数の場合はまったく重要ではなく、5%よりはるかに小さい。安全/非安全、または一般用途/性能重視の範囲を分ける方式がよい解決策だと思う
    • クロック速度は80年代より2000倍高く、SIMDまで考慮すると命令あたりのスループットも80倍高い可能性があり、さらにコア数を掛ける必要がある
      主流のCPUは80年代のマシンより100万〜200万倍速い側に近い。数百ドルあれば、今でも100万倍速いカテゴリの再生品オフィスPCを買える
      今のコンピュータが遅く、遅く感じられる現象は、単にコンピュータが遅いからではなく、それでも実際に起きている。スクリプト言語が小さな演算のたびにメモリを割り当て続け、動的型付けのせいで変数ごとにポインタをたどることも一因であり、すでに悪い環境で極端に非効率なプログラムを使っている人たちもいる
      最近のほとんどのプログラムは、ユーザーが望むやり方ではなく、作者が働きたい方法で書かれている。多くの人は最適化の概念や、何がより速く実行されるのかという感覚がなく、動くようにしたあとで「このプログラムはこの速度なのだ」と考える
      同じソフトウェアがもっと速くなり得るという発想自体がニッチな考え方で、Hacker Newsでも全員がそう考えているわけではない
    • 境界チェック自体のコストは低いが、安全な言語を一般的に使うコストははるかに大きくなり得る
      ガベージコレクション言語は、メモリを何倍も使う場合が多い。もう使っていないメモリを即座に解放せず、そもそも割り当てもより多く必要としがちである
  • GoogleとFacebookで働いてみて、ハードウェアがどれほど安く、ほとんどの場合コード最適化の価値がどれほど低いかを実感した
    Googleは10年以上前からデータセンター資源の使用量を管理し始め、プロジェクトごとにCPUコア、ハードディスク容量、フラッシュストレージ、ディスクスピンドル、メモリといった予算があった。これらの資源はおおむね相互換算でき、相対コストを見ることができた
    当時フラッシュストレージはハードディスクより約20倍高かったが、スピンドルのボトルネックのため、総コストでは安くなる場合が多かった
    これらすべては「mili-SWE」、つまりSWE 1人が1年働く労力の1000分の1に換算できた。プロジェクトはハードウェアを節約して人を増やすことも、人を減らして現在の予算内でハードウェアを多く受け取ることもできた
    CPUコア何個がSWE 1人に相当したかは正確には覚えていないが、数千個だったように思う。プロジェクト全体の最適化にSWE 1年を費やしてもCPUコア5000個を節約できないなら純損失である
    非常に大きなプロジェクトはそれよりはるかに多く使うため最適化に意味があったが、特に書いたコードがいつか置き換えられる可能性が高いなら、最適化が適切でない場合が多かった
    一方でWebには一般的なユーザビリティ問題がある。Webは今のように多くの資源を使うべきではない。データ入力業務をしたことがある人を知っていれば、マウスがかなり非効率だと分かるはずだ。30〜40年前のテキストベース端末は、資源をほとんど使わずに非常に効率的なインターフェースを提供していた
    いつかWebは、一般的に期待される技術スタックが定まり、別の問題へ移る形で「解決」されると思っていたが、そうはならなかった。今でも「今週のフレームワーク」があり、マウスホイールとうまく合わないスクロールバーをユーザーコードで再実装するという愚かなことをしている。この問題をどう解けるのか、そもそも「解決」できるのかも分からない

    • 私もそこで働いていたが、ここで言う性能はプロジェクト別のCPU最適利用という観点である
      Googleは、別の2つの性能面であるレイテンシと全体の機器利用率には膨大な努力を注いでいた。どちらも上からの指示で、何千人ものエンジニアの時間と注意を吸い込み、人件費も大きかった
      しかし機器が制約なら、個々のコアが安くても理由なく遊ばせておきたくはない。新しいデータセンターの構築を待つ機会費用が大きいからだ。利用量がレイテンシに非常に敏感なら、ハードウェア費用の削減ではなく事業指標のためにミリ秒を削ることに意味がある
    • Googleのようにエンジニアリングコストが高く、追加ハードウェアのような支出を賄える厚いマージンがあり、エンジニアが取り組むプロジェクトが多い会社を自分で選んだ事例である
      評価は限界費用で行うべきだ。1ドルあたり年間数セントを節約する程度でも、エンジニアが暇をしているよりはその仕事をしたほうがよい
      問題は、ほとんど誰もそうしていない点である。意思決定の方法が経済的な計算と無関係で、たいていはただ「Googleがやっていること」をまねるだけだ。だから多くの機能不全が説明できる
    • この論理はGoogleのような組織には当てはまる可能性が高い。規模のために「1コア」が平均よりはるかに安く、給与は平均よりはるかに高いからだ
      しかし普通の企業、たとえ大企業であってもそこまでではない。「Facebook/Google/Netflixなどは別階級であり、彼らの慣行の大半はあなたには通用しない」という典型例に見える
    • その問題は「解決」されないだろう。そもそも問題ではないからだ
      人的資源を最適化に注ぎ込む別の宇宙を想像することはできるが、その宇宙は今とはまったく違うものになる。最適化にエンジニアを1人余分に使えば、機能開発エンジニアが1人減る。何のために? CPUサイクルを少し節約するため? 冗談じゃない、という感じだ
    • Googleがより優れた圧縮やバイナリシリアライズ形式を作るのは、面白半分ではなく、収益に役立つからである
  • タイトルだけ見ると、Carmack が十分に最適化されていないソフトウェアを批判し、古いハードウェアで性能を改善しようと主張しているのかと思った
    実際のツイートはそのどちらでもなく、ハードウェアの進歩が止まったという思考実験を扱いながら、「超低コストでスケール可能なコンピューティングがなければ、革新的な新製品は当然はるかに珍しくなるだろう」と結論づけている

    • 昨日のスレッドに関連する内容のようで、おそらくそれを見ていないのだと思う
      https://news.ycombinator.com/item?id=43967208
      https://threadreaderapp.com/thread/1922015999118680495.html
    • 「超低コストでスケール可能なコンピューティングがなければ、革新的な新製品ははるかに珍しくなるだろう」という結論は興味深い
      むしろスマートフォン以後の18年間、大きなイノベーションはあまり見ておらず、資本が消費者に本質的には既に持っているものと同じ製品を売るためにハードウェアの進歩に頼っているからだと思う
      もちろん最初のツイート以降は読めなかった
    • その主張はよくないと思う。しばらく機能追加を止めて息をつく余地を作れば、機能はまた勢いよく戻ってくるはずだ
      停滞はあるだろうが、持続的な停滞にはならないだろう
    • まさにそこが核心だ。人々は「肥大化」が単なる無駄ではなく、経済的動機から生まれた開発者生産性の向上だという点を無視している
      より複雑でない言語で人を採用して生産的にできるなら、労働者市場は広がり、コストは下がる
    • ここには Carmack の現在のAI での取り組みが背景にあるのかもしれない
      原文で Carmack は本質的に、「優秀で賢い開発者は高価で、より大きな仕事があるので、コードやシステムを徹底的に最適化させるためにお金を使わない。そのためソフトウェアは遅い」と主張しているようなものだ
      したがって、優秀な開発者が突然とても安くなれば、誰もが彼らを買って最適化に使い、多くのソフトウェアが突然速くなる可能性がある、という含意がある。では、なぜ優秀な開発者が突然安く出回ることがあり得るのだろうか?
  • ハードウェアの寿命を「計画的陳腐化」の後さらに5年、10年延ばせるなら望ましい
    そうすれば電子廃棄物を大きく減らし、希土類を地中に残し、温室効果ガス排出も大幅に下げられる
    しかしソフトウェア生産の市場の力は、そうした外部効果に対して費用を支払わない。性能のために計画し設計するより、早くリリースし、テストし、反復するほうがはるかに安い。ゲーム業界の一部の組織は、良い性能と販売本数を同時に得る方程式を見つけたが、均等には広がっていない
    エンタープライズ向け・消費者向けソフトウェアでは、要件に性能基準を入れる動機は大きくない。ユーザーが耐えられる水準に合わせて設計し、変更と機能を継続的にリリースしなければならないため、できるだけ余裕を持たせる。すべての変更は性能とユーザー満足に影響し得る負債なので、エラー率を許容できる予算上の余裕を確保する
    「準備ができるまで」密室で設計・開発していたやり方とはかなり違う

    • 最初のポイントが、長期的に成長/負債の経済モデルがよくない理由だ
      私たちはケアと保守を中心にした経済を持つべきであり、少数の認知された富ではなく、人類全体の善を中心にマクロな取り組みを合わせるべきだ
      古い車両の維持や古いコンピューターの再利用などに注力していれば、成長に比べて埋立地はもっと小さかったはずだ
      もちろん、保存主義者が客観的に劣った戦略であることを示すゲーム理論上の構成もありそうだ
  • 取引所全体の注文マッチングエンジンを単一スレッドで動かせるようになってから、すでに10年以上になる
    厳密に直列化されたトランザクション処理という特定の種類の計算能力は、他の指標が示唆するほど速くは成長していないと思う。コアを31個追加しても注文マッチングエンジンが速くなるわけではなく、むしろ遅くなる可能性がある
    製品が毎秒数百万件未満のトランザクションを処理しているのにマシンクラスタを探しているなら、15段階くらい後ろに下がって最初からやり直すべきだ

    • この部分には本当に腹が立つ。システム「アーキテクト」たちは、自分の価値を証明し、足跡を残そうと躍起になるあまり、多くのシステムを過度に複雑にし、その結果として新たな問題を大量に解き放った
      元の設計だけでもユースケースの99%は今なお満たしていただろうし、最近のローカルコンピューティング能力を考えれば、市場全体を単一のマシンで動かすことすらできる
    • 並列ソートのようにログ縮約を使って、注文を並列にマッチングできないのか気になる
      時間と価格でソートする以外に、計算することが十分にないからなのだろうか?
    • 各トランザクションで単純な処理をしているから可能なのだ
      トランザクションごとにもっと複雑な処理が必要だったなら、それほど多くの件数は処理できなかっただろう。ただし、どのようなより複雑な処理が必要なのかは、そのドメインの人間ではないので想像しにくい
  • そのとおり。これは経済の問題、つまり資源配分の問題です
    誰かにソフトウェア最適化へより多くの時間を使わせるのか、それともより多くの機能を作らせるのかという選択です。後者がより多くの現金を生むならその仕事をさせるし、前者がキャッシュフローにとって重要になればその仕事をさせるでしょう

    • 経済の問題だという点は正しいが、どのような経済問題かが違うと思う
      これはソフトウェア会社が大衆に課している負の外部性の明確な例です。ほとんどのソフトウェア会社は、エネルギー、失われた時間、追加の電子廃棄物の実際のコストを払っていないため、最適化を気にしません
    • この経済は、金融負債を積み上がるゴミと技術的負債へ移し、そのコストを他人に払わせる仕組みです。実質的には盗みに近いです
      徹底的な最適化にあまり意味がない場合も多いですが、書き直す代わりにサーバーを追加すればよいという発想は悲しい状態です
    • 一般的には、変化のためだけに新機能を追加するより、開発者がソフトウェアを最適化するほうが望ましいです
      macOS、Windows、Androidの新機能の大半は使いません。欲しいのはアプリを動かすための効率的な環境とセキュリティ改善です。macOSの設定アプリのような多くの改善も、あまり満足できるものではありません
      デザインソフトウェアも同じです。Adobeが入れた新機能の大半は使っておらず、10年前のIllustratorやPhotoshopでも十分幸せでいられます。欲しいのは、肥大化の少ないソフトウェアです
      オーディオや音楽制作では、ワークフローがまだ改善中なので新機能は欲しいですが、効率を犠牲にしてまでではありません
      コードエディタはVSCodeの機能で十分です。これ以上必要なものはなく、より良いLSPは欲しいですが、エディタの中核ではありません。ただ、VSCodeがもっと速く、メモリ消費が少なければと思います
    • 効率は日常でも重要です。たとえばおやつを取りにキッチンへ行くとき、ゴミや食器も一緒に持っていって、1回の移動の利益を2倍にします
      ソフトウェア最適化も同じように魅力的です。しかし問題が「高価なエンジニアリング時間を何時間もかけて最適化する」ことと「安いRAMを追加する」ことなら、より安い選択が勝ちます。時には問題が十分大きく、最適化する価値がある場合もあります
      市場がどの選択を追求する価値があるかを決めるでしょう。ハードウェアをさらに投入する方式が収穫逓減に達すれば、ソフトウェアを最適化するようになります。ムーアの法則は減速していますが、まだその地点には達していないようです
    • 結局は需要の問題です。消費者がより高性能なソフトウェアを求めるなら、プレミアムを支払うでしょう
      しかし現実はむしろ逆に近いです。より安い価格が付くなら、性能の低いバージョンも好まれるでしょう
  • Carmackへの反論というより、時々考える具体的な事例があります
    Electronアプリは、消費者にとっては性能問題を我慢する対象と嫌悪する対象の中間あたりにありますが、職場でLinuxノートPCを実用的に使えるようにした単一のイノベーションである可能性が高いです。たとえばインストールなしでMS Teams会議に参加できるのは本当に便利です
    だから皆が、最近はWinampのように緻密にコーディングされたものがないと嘆きますが、前の3文字を忘れています

    • Wineがあるので、高性能なWindows専用ソフトウェアのほうが、今日のElectronの寄せ集めよりずっと良いと思います
      Linuxでも動く可能性はかなりありますが、Electronソフトウェアはどのプラットフォームでもひどいです
  • 2010年に清掃員として働きながら、IT責任者の仕事を副業のようにしていました
    当時、会社には過去5年ほどのノートPC、だいたいNehalem以降の製品ならスプレッドシート作業には十分な性能があると伝えました。彼らの仕事は実質的にそれだけで、2コア、RAM 16GB、500GB SATA SSDで十分でした。マーケティング担当の数人だけ少し強い機材が必要でしたが、大きな差ではなく、最新の最高級ノートPCを買わずに多額の費用を節約できました
    今はそこでは働いていませんが、今でもそのコンピュータはスプレッドシート用途には十分立派なはずだと確信しています。業務フローは大きく変わっておらず、変わったのはソフトウェアです。アップデートを続けていたなら、今のMS Windows 10や11を「動かせる」かどうかも分かりませんが、肥大化、とくにオンライン専用スプレッドシートによって生産性が大きく落ちていた可能性が高いです
    そこのインターネット環境もひどいものでした。選択肢は「ビジネス」向けという理由で月300ドルの約16Mbit非対称DSLか、月500ドルのComcast 120Mbitケーブルだけでした。120Mbitでもオンライン専用スプレッドシートには何とか耐える程度で、16Mbitでは明らかに不足です。さらに悪いのは、インターネットが切れると事業が止まることです
    他のコメントが言っていた盗みの実態がまさにこれで、全面的に同意します。オフィスでスプレッドシートを編集・更新するノートPCが、インターネットや途方もない計算・ストレージ資源、大きな帯域幅を要求する理由はまったくありません
    今日のコンピュータのひどい性能には、顧客、つまり個人と企業の双方にコストを押し付けていること以外に言い訳はありません
    https://news.ycombinator.com/item?id=43971960

  • 世の中は、優雅で高速でバグのないソフトウェアではなく、機能の上で回っている
    エンドユーザーにとって、機能がないこととバグは違わない。性能が悪くてある作業を完了するのに5分かかることと、機能がないためにユーザーが同じことを手作業で5分やらなければならないことにも、意味のある違いはない。どちらも「遅い」のである
    エンドユーザーの価値を最大化し続けると、必然的に遅くてバグの多いソフトウェアを作ることになる。しかもユーザーに、より高速でバグが少ない代わりに機能が減ることを望むかと聞くと、驚くことに望まないと言う。さらに重要なのは、企業の世界ではソフトウェアの購入者がエンドユーザーではない場合が多く、彼らは機能をより多く求め、性能や優雅さはそれほど求めないことだ
    機能セットが同じなら、ユーザーも購入者も最も高速で、バグが少なく、優雅なソフトウェアを選ぶだろう。しかし機能が1つでも欠けていれば負ける。ソフトウェアを高速で優雅に保つべき理由は、そうしてこそ機能を追加し続けながら、機能の少ない製品にならずに済む可能性が最も高いからだ
    高速で優雅な解法は良いレビューを受け、使い心地が良いと褒められることがある。そのため、それが重要な要素のように見えるかもしれない。しかし結局、やりたいことができなければそもそも買わない。必要な中核機能があるなら、遅くていら立たしく、バグだらけの混乱したものを選ぶ

    • 技術者ではない友人や家族のほとんどが、ある時点で必ず使わなければならない肥大化し、過度に複雑なソフトウェアに不満をこぼしたことがある
      Microsoftが今では、ユーザーを蹴飛ばし悲鳴を上げさせながら次のWindowsバージョンへ引きずっていかなければならない、という点も思い出すべきだ。ユーザーに自分で決めさせていたら、多くの人はWindows XP以降アップグレードしなかっただろう。後続バージョンに見栄えのする新機能がたくさんあったにもかかわらずだ
      企業や投資家が機能そのものを欲しがるという点には同意するが、ユーザーは明らかに違う
    • まったく逆だ。会社がユーザーの望まない機能を押しつけるのは、旧バージョンを打ち切り、強制アップグレードで販売するためだ
      可能なら、誰ももう何もアップグレードしないだろう。Microsoftが人々をアップグレードさせようとどれほど苦労しているかを見ればよい。Windows、Office、Slack、Zoomなどの新バージョンを欲しがっていたという人を聞いたことがない
      Photoshopのようなあらゆるものがクラウドへ強制される理由もこれだ。大多数の人は提供される新機能を望んでおらず、それは企業の購入者も含む。売上を維持する答えは、機能の提供有無にかかわらず、人々に買わせることだ
    • 機能と優雅さのトレードオフには同意する
      ただし既存ユーザーはすでにそのソフトウェアで必要なことをしているので、新機能は別のソフトウェアを不要にしたり、新しいことを可能にしたりし得る。しかし本当に非常に重要な新しいことなら、すでに別のソフトウェアを探して使っていたはずで、今までなくても何とかやってこられたということだ。だから既存ユーザーが本当に内省的なら、まず性能改善を求め、小さな改善をいくつか望む程度だと思う
      逆に潜在ユーザーは、まだそのソフトウェアを知らないか、有用だと感じる前に何か別の機能を必要としている。新機能を合理的に求めるのは彼らだ
      したがって「機能 vs 性能」の決定は、開発者の優先順位が新規ユーザーの追加なのか、既存ユーザーの満足なのかを示すシグナルでもある。技術者が後者を好むのは当然だ。すでにこのゲームを経験しており、獲得される過程ではなく、実際に長く使う時間において優先されたいと分かっているからだ
      バグが多く遅いが機能豊富なソフトウェアが市場を支配するのも、企業が成長をまず優先するからだ。歴史は、ユーザーが懐かしむ美しく優雅なソフトウェアで満ちているが、会社が存続できるほど広く普及しなかった
      トレードオフは双方向に実在する。ほとんどの人は、潜在ユーザーとして過ごす時間よりもユーザーとして過ごす時間のほうが長い。これが、最近のソフトウェアとコンピュータが信じられないほどひどいという一般的な認識の大きな原因である可能性が高い
    • 的確な表現だ。ソフトウェアの性能改善にもっと時間を使うべきだと主張する人たちは、誰がその費用を払うのかを考えていないようだ
      家庭用・オフィス用コンピュータでRAMやより良いCPUに使われるお金は、その上で動くすべてのソフトウェアを、より安く、より多くの機能を備えた状態でリリースできるようにしている