- 現代のソフトウェアは、ハードウェアの進歩を効率・簡潔さ・完成度として還元するよりも、「コンピュータは十分に速い」という前提に頼り、非効率を常態化させてきた
- Web のスクロール、Google Inbox でメールを開くのに13秒、Windows 10 のアップデートに30分、テキストエディタの入力遅延のように、基本的な作業でさえ期待より遅く感じられる
- Android システム 6GB、Windows 10 4GB、Google Keyboard 150MB、Electron アプリや Slack の事例は、アプリとプラットフォームの肥大化が性能・複雑性・信頼性のコストにつながることを示している
- OS・アプリ・ブラウザのアップデートや、iOS 11 による32ビットアプリ対応終了のように、かつて問題なく動いていたソフトウェアも、時間がたつにつれて遅くなったり壊れたりし得る
- より良いソフトウェアを作るには、エンジニアが自分の作ったシステムの性能・構造・限界を理解し、より少ないリソースで高速かつ予測可能な結果を出す必要がある
性能を浪費するソフトウェア
- 現代のソフトウェアは、可能な性能の**1%または0.01%**で動いても構わないと受け入れられることが多い
- 自動車、建築、航空機は物理的な限界や最適な形に近づいていく一方で、ソフトウェアは非効率を「コンピュータは十分に速い」という言葉で正当化する
- 「プログラマの時間はコンピュータの時間より高価だ」という格言は、コンピュータ時間が前例のないほど浪費されている現実を覆い隠しかねない
- 毎日実行する Python プログラムを Rust で書き直して1.5秒から0.06秒に短縮したが、その6時間を取り戻すには41年以上かかるというツイートは、効率をめぐる議論の代表例として使われている
耐えがたいほど遅い基本体験
- 最新の携帯型コンピュータは月面着陸時代のコンピュータより何千倍も強力だが、最新の MacBook Pro でも Web ページを60fpsで滑らかにスクロールするのは難しい
- Google が作った Inbox は、Google Chrome でメールを1通開くのに13秒かかる
- コンテンツではなく空の白い箱をアニメーションさせるやり方は、Web ページが出せる性能限界に合わせた妥協に近い
- 120Hz ディスプレイが主流になった時点でも、Web コミュニティの返信を1つ見るのに60Hzすら安定しないと見ている
- Windows 10 のアップデートには30分かかり、その時間があれば SSD をフォーマットして新しいビルドを取得しインストールする作業を何度もできる、と比較している
- 現代のテキストエディタは、42年前の Emacs より入力遅延が大きい
- キー入力ごとに小さな矩形領域だけを更新すればよい作業でさえ、16ms以内に処理できていないと指摘している
- 3D ゲームは同じ16ms以内に、画面全体のレンダリング、入力処理、ワールド計算、リソース管理を行っている
- より速いハードウェアは、より良いソフトウェアのためではなく、同じことをより遅く行うソフトウェアを動かすために使われる状況になっている
肥大化したアプリとプラットフォーム
- Web アプリは広告をブロックするだけで10倍速くなり得る。AMP は新しい技術というより、肥大化した部分を取り除けという常識的な解決策に近い
- Android システムはアプリが何もなくても6GBで、Windows 95 は30MB、Windows 10 は4GBである
- Windows 10 は Windows 95 より133倍大きいが、基本機能は大きく変わらないと見ている
- Android は Windows 10 よりも1.5倍大きい
- Google Keyboard は通常150MB、Google アプリは350MB、Google Play Services は300MBを占める
- Google Keyboard は画面に30個のキーを描くアプリなのに、Windows 95 全体より5倍複雑なのか、と問う形で批判している
- Google Play Services は使わなくても削除できない
- 基本アプリをインストールしたあと写真の保存容量が約1GBしか残らない状況は、フロッピーディスクに OS・アプリ・データをすべて保存していた時代と対比される
- Electron ベースの Todo アプリには、Xbox 360 コントローラードライバ、3D グラフィックスレンダリング、音楽再生、Web カメラ撮影機能まで含まれ得る
- Slack はチャットと簡単なテキストエディタに近いアプリであるにもかかわらず、読み込み速度とメモリ使用量のために重いアプリに分類される
- アプリが大きくなるほど、制御の喪失、複雑性のコスト、性能低下、信頼性の負債が増え、過度に重いアプリを普通のものとして受け入れてはならない
時間とともに腐るソフトウェア
- 3年前は16GBの Android スマートフォンでも十分だったが、Android 8.1 の時代にはアプリが特別な理由もなく2倍ずつ大きくなり、使いにくくなっている
- iPhone 4s は iOS 5 とともに発表されたが、iOS 9 の実行は重く、iOS 9 が根本的にはるかに優れているわけでもないと指摘している
- iOS 11 は32ビットアプリ対応を終了し、開発者がいない、または更新されないアプリは二度と見られなくなる可能性がある
- DOS プログラムは1980年代以降、複数のコンピュータで修正なしに動くが、JavaScript アプリは次の Chrome アップデートでも壊れ得るというツイートを引用している
- 今日問題なく動いていた Web ページも、10年以内にはどのブラウザでもまともに動かなくなるかもしれない
- 同じことをするために新しい電話と新しい MacBook を買うが、結局同じアプリをより遅く実行する状況が繰り返される
低くなった品質への期待値
- Web ページは問題が起きると、原因を調べるより再読み込みを押すよう求める
- Web アプリは互換性のあるブラウザでも「ランダムな」JavaScript エラーを大量に出すことがある
- Web ページと SQL データベースの設計は、レンダリングされた Web ページを見ている間はデータが変わらないだろうという期待の上に成り立っている、と批判している
- 共同作業機能は「ベストエフォート」程度にとどまることが多く、データを失い得る日常的なシナリオを抱えている
- 「どのバージョンを保持しますか？」のようなダイアログは、作業物のうちどれを破壊するか選べという意味に近い
- Linux は任意にプロセスを殺す設計を持っているにもかかわらず、サーバーで最も人気のある OS である
- Dell モニター、AirDrop、Bluetooth の事例は、デバイス内部のソフトウェアと複雑な仕様が、定期的なリセットや運に依存する体験を生み出していることを示している
- 安定して動くものを届けるには、作った対象を内側から外側まで理解する必要があるが、過度に膨れ上がったシステムではそれが難しい
プログラミングツールと開発慣行の混乱
- パッケージ管理、ビルドシステム、コンパイラ、言語設計、IDE といった基本要素でも、高速で効率的、かつ長く使える完成度を見るのは難しい
- ビルドシステムはすべての変更情報を持っているにもかかわらず、定期的に全部消してやり直すことを求める
- 信頼性があり、予測可能で、再現可能に作れない理由はないと見ている
- NPM は何年もの間「たまに動く」状態にとどまっていたと表現されている
rm -rf node_modules が Node.js/JavaScript 開発で避けられないように見えるというツイートを引用している
- コンパイラや前処理・後処理に数分、あるいは数時間かかっても受け入れられている現実は、「プログラマの時間は重要だ」という言葉と矛盾する
- Hadoop を1台の PC で実行するより遅い状況でも選ぶ事例は、プログラマが常に合理的な判断をするわけではないことを示している
- 機械学習と「人工知能」は、ソフトウェアを信頼できない推測の時代へ移したと批判している
- 「人工知能」や「機械学習」が使われたアプリ・サービスは、信頼性がなく予測不能で、結果の説明が難しいと読む、というツイートを引用している
- Linux の上に VM を載せ、VM の中に Docker を入れるやり方は、プログラム・言語・実行環境をきれいに片付ける方法を知らないサインと解釈されている
- Go の単一実行ファイルが主な利点として挙げられる現実は、めちゃくちゃでないだけで成功と見なされる状況を示している
- 依存関係は、簡単な問題を「パッケージ全体のソリューション」で解決しようとして、導入コストと別の依存関係を一緒に連れてくる
- プログラムを再起動なしに何年も使い続けるのは難しく、時には数日でも難しいと指摘している
- プロセスの再起動、データベースの再起動、20分ごとにアプリを再起動するウォッチドッグ、重複リソースの同梱と圧縮転送は、直す代わりに素早くやり過ごす方法である
- こうした慣行はエンジニアリングではなく怠惰なプログラミングであり、エンジニアリングとは作ったものの性能・構造・限界を深く理解することだ
積み上がった複雑性と市場の無関心
- 現在のソフトウェアは、かろうじて動くコードの上にまたかろうじて動くコードが積み上がった状態であり、成長と複雑化が続くほど変更の機会は減っていく
- 健全なエコシステムには時に後退してから前進する過程が必要だが、25年間新しい OS カーネルを見ておらず、今では書き直すには複雑になりすぎたと指摘している
- ブラウザもエッジケースや歴史的問題のために、レイアウトエンジンを一から書き直すのが難しい
- 今日の進歩は、モノリスの問題を解決しようとしてマイクロサービスを導入し、マイクロサービスの問題を解決しようとして Docker を導入し、Docker の問題を解決しようとして Kubernetes を導入するように、火に燃料を注いでいるように見える
- XML ベースの宣言的設定から YAML ベースのマイクロサービス設定へ移ってきたが、昔の XML には少なくともスキーマがあった、というツイートを引用している
- ユーザーはエンジニアが提供するものを受け入れるしかなく、Android アプリ350MB、途切れるスクロール、「動かなければ再起動」といった状況にもほとんど選択肢がない
- 競合製品もすべて遅く、大きく、品質が低ければ、競争圧力は生まれにくい
- iPhone/iOS と他のスマートフォン、Chrome と他のブラウザのように、一時的に緊張感を生む製品が登場することもあるが、長くは続かないと見ている
- エンジニアの使命は、現代のコンピュータで性能、信頼性、品質、可用性の面で何が可能かを示すことであるべきだ
それでも見える代替案
- Martin Thompson の LMAX Disruptor、SBE、Aeron は、印象的で単純かつ効率的な例として挙げられている
- Raph Levien の Xi editor は、正しい原則を念頭に置いて作られたものと評価されている
- Jonathan Blow は自分のゲームのために言語を作り、彼のノートパソコンでは50万行のコードを1秒で完全に新規コンパイルできる
- インクリメンタルビルドでも中間キャッシュでもなく、全体を新規コンパイルした結果である
- 高速なプログラムを書くのに天才や魔法は必要なく、流行のツールチェーンのような巨大なゴミの山の上に作らなければよい、と見ている
より良いソフトウェアへの要求
- ソフトウェアエンジニアリングは現状にとどまらず、より良くなるべきであり、同じものを繰り返してより遅く大きい形にする必要はない
- 今日の開発は進歩というより、ぼろぼろのツールの上でビジネス目標だけをかろうじて満たしている状態に近い
- 局所最適化に縛られた結果、肥大化し非効率な状態に慣れてしまったと指摘している
- エンジニアは、より良いツールでより良いアプリを何倍も少ないリソースで、高速かつ予測可能で信頼性の高いものとして作れるし、そうすべきである
- 信頼性があり予測可能な高品質の製品を届けるには、何をなぜしているのかを完全に理解する必要があり、「与えられたものがこうだから」という言い訳は受け入れられない
2件のコメント
この記事は以前に韓国語訳が公開されているので、そちらをご覧ください。
https://tonsky.me/blog/disenchantment/ko/
翻訳へのリンクに差し替えてあります。
Hacker Newsのコメント
より小さく、クリーンで、バグが少なく、安全で、高速で、長持ちするコードは当然可能です。情報化時代の初期にもできていたのなら、数十年の経験と強力なツールがある今、できない理由はありません。
そうしない理由は、そこに金がないからで、実際にはほとんど逆です。VC出資のスタートアップは、まず市場に出なければ生き残れず、成熟した組織でもコストや肥大化は問題ではなく、管理職の威信を高める機能のように働きます。結局、そのコストは顧客に転嫁されます。
「無慈悲な市場原理」がこうした無駄を正さない理由は、より良いコードベースがいつか王国の鍵を手にできるとしても、現実の競争環境は病理や流行にあまりにも脆弱だからだと思われます。
ただしVC出資企業よりもやりやすいのは、リファクタリングと技術的負債の処理に時間を割り当てることです。実際、今は45日間、新機能開発に急ブレーキをかけ、主要な技術的問題に取り組んでいます。来年買収されると期待しているなら、こうした投資はしにくくなり、技術的負債は他人事になります。
製品が開発され続ける限り、新しいバグや問題は生まれ続けます。「完璧なコード」は、新機能がもう追加されない閉じた文脈でしか可能ではありません。
VC出資モデルが業界をこのように追い込んだのだと思います。スタートアップは数百万ドルを受け取り、投資家に返せるほど早く稼がなければならないため、アプリからできるだけ早く金を搾り取る必要があります。ROI指標が付かない仕事は誰の関心も得られません。
基本的には、オープンなアクセス、パスワードなし、または短いパスワード、安全でないパスワード保存、すべて平文、入力サニタイズの無視、telnetのようなものがありました。
ソフトウェアがさらに肥大化した別の理由もここにあります。相互作用とリスクが見え始め、一度見えてしまうと見なかったことにはできません。対処すべき境界条件は減るどころか増えており、サポートすべきハードウェアも増えています。
高性能なコードを書くプロセスは改善できますが、同時にベースラインは私たちが到達する速度よりも速く上がっています。今ではまた少しずつパスワードなしの方向へ進んでいる点も興味深いです。
リファクタリングを苦痛にする高いユニットテストカバレッジは、機能リリースを妨げることが多く、テスト駆動開発の狂信者たちが認めたがるよりはるかに頻繁にそうだと思います。業界の多くの「ベストプラクティス」は、すでにプロダクトマーケットフィットを見つけ、金が勝手に刷られる会社にいる人たちが作った、非現実的な教義に近いものです。
まだかろうじて使えるHP MS200オールインワンがあります。2017年にガレージセールで安く買い、Linuxを入れると、Chromeが読み込まれた後ならSkypeのWeb版で全画面ビデオ通話をしたり、YouTubeを全画面で視聴したりすることもできました。
最近また受け取って子ども用のコンピュータにする前に、FC38と最新のChromeをインストールしたところ、YouTube動画がスライドショーになりました。設定をいくらいじっても駄目だったので、RAMを2GBから3GBに増やしたところ、6年前と同じ720p全画面再生の水準に戻りました。
同じことをするのにメモリが1.5倍、つまり1GB余計に必要になったわけです。16GBが最低ラインだという話も分かりますが、このひどいマシンでもChromeはほぼアイドル状態のWebブラウザなのに、メモリフットプリントを30GBほどと表示します。大半はmmapされたファイルでしょうが、それでも30GBです。
逆に大半のデバイスでは、バッテリー駆動時間の増加、低い発熱、より小さなRAM・ディスク要件が明らかな改善です。YouTubeが古いエンコードファイルをサーバーに重複して残すこともできますが、最新デバイスからアクセスするユーザーが大半である状況では容量の無駄になります。
ChromeのRAM使用量増加の大半は、サンドボックスアーキテクチャの進化に由来します。共有メモリとプロセス空間はサンドボックスを脱出する攻撃に使われ得るため、隔離がさらに追加され、Chromeがタブや拡張機能ごとに新しい独立プロセスを起動することも大きな原因です。
最近は広告ブロッカーの影響も大きいです。Webが悪化するにつれて、効果的な広告ブロッカーは作るのが難しくなり、より多くのリソースを必要とします。遅いソフトウェアが単に人を困らせるために遅くなったわけではなく、危険なハックを良い実装に変え、要件が変わった結果である場合が多いのです。FLVはもはや十分ではなく、h264もh265とAV1が普及すれば、5年後には長く持ちこたえるのは難しそうです。
現代のツールチェーンは「車輪の再発明をするな」に集中していますが、各依存関係がそれぞれ別のバージョンの車輪を選んでいたなら、依存関係を数個引き込むだけで同じ低レベル機能の実装が6つずつ入ってくることになります。
ただしインストールされていたのはFlatpakで、肥大化が感じられました。幸いChromeはまだRPMで直接ネイティブインストールでき、OSの共有ライブラリを実際に使います。
この記事は、核心的な苦痛であるバグに触れてすらいない。ほぼすべてのソフトウェアが、できる限りバグだらけであるかのように感じる。あまり一般的でない経路や異常系のフローでソフトウェアを使うことになるたびに不安になり、ほとんどの場合失敗する。
少し前にCarvanaに車を売ったときは、ChromeとFirefoxを行き来しながら、ようやく処理を終えた。Chromeでは画像アップロードのウィザードがJS例外を出し、その部分だけはFirefoxで奇跡的に動いたが、サイトの残りの部分はFirefoxでテストしていないのが明らかなほど問題だらけだった。
さらに悪いのは、非技術系のユーザーがバグに遭遇すると、自分が何か間違えたのだと思ってしまう点だ。肥大化して遅くても、安定して堅牢なソフトウェアなら、今では喜んで受け入れられる。
他方では、あらゆるものがどれほどバグだらけかが絶えず目につく。本当に以前よりバグが増えたのか、それとも内部事情を知る年齢になって、大企業式のソフトウェア開発に対する忍耐力が減っただけなのかは分からない。明白なUXバグが簡単に見つかるのに、「機能Xを今すぐリリースしろ」と言う架空のプロダクト担当者に腹が立つ。
コスト、機会費用、実用主義といった主張も理解できるし一部は同意するが、私たちは半分だけ作られた世界に住むことをただ受け入れてしまったのだ、という感覚を拭いにくいことがある。
今も良くなったようには思えない。小さな子どもがスマートフォンやノートPCを手にすると、ボタンを速すぎる速度で押したり、予想外の順序で押したりするだけで、現代のデバイスをかなりの確率で固まらせ、フリーズさせ、クラッシュさせる。物理的に壊しているわけでもないのに、これが現代技術の状態なのだ。
なぜ直っていないのかは理解できる。人々はときどき再起動が必要になるものだと期待するようになっており、こうした場合は子どものせいにしやすく、再起動すれば解決するからだ。それでも、OSのライフサイクル上、今ではもっと良くなっていてほしかった。
Cについて書いた記事では触れなかったが、私がCを使う大きな理由の一つは、ソフトウェアを肥大化させるのが難しいからだ。機能を追加することはできるが、単一の機能だけで実行ファイルに100KBを上乗せするのも簡単ではない。
今は雇われている状態ではないが、「作業」用には強力なマシンを使っている。それでもIDEの代わりにNeovimとtmuxを使い、一般的なLinuxディストリビューションではなく大きく手を入れたGentooを、systemdの代わりにOpenRCを使い、フルデスクトップ環境ではなくQtileというタイル型ウィンドウマネージャを使っている。
起動してログインした直後のプロセスが40個しかないほど、マシンを肥大化させないようにしている。今は本当にソフトウェアをエンジニアリングしている。Cの問題を効果的に緩和しつつ、ソフトウェアを小さく速く保とうとしており、いつかその上にビジネスを作れればと願っている。
肥大化していない軽快なソフトウェアに、まだ市場があるのかを見ることになりそうだ。
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
1980年代のWordPerfect、Lotus 123、MS-DOS 1.0、Microsoftに買収される前のSubLogic Flight Simulatorのようなプログラムはアセンブリで書かれていた。当時の業界ウォッチャーは、MS WordとMS Excelが「肥大化した」Cで書かれていたため、MicrosoftはWordPerfectやLotus 123よりも新機能を速く反復し、他のアーキテクチャへ速く移植できたのだと見ていた。競合他社がアセンブリに長く留まりすぎたからだ。
個人用ソフトウェアでも同じトレードオフを見ている。よりスリムなC/C++ではなく、より高水準で「肥大化した」C#/Pythonを使うと、特定の作業をはるかに速く終えられる。C++の方が得意で、小さな実行ファイルを好むが、C#の方がやりたい作業を速く終えられるなら、その利点は意味を失う。私も肥大化したソフトウェア問題の一部なのだ。
「世界で最も強く軽い橋を作る」というのは驚異的なことだが、「顧客が負担できるコストで、十分に軽く十分に強い橋を作る」というのがエンジニアリングだ。
半分を少し超えたところまで読んで止めたが、核心的な主張はソフトウェアは速くあるべきだ、ということのように見え、その哲学への正当化は「ただの真理」だという示唆以外には記憶に残っていない。効率向上分が、効率を追求する時間コストを決して相殺できない場合がある、という反論は認めていたが、その論証ときちんと向き合わずに流していた。
この記事のもう一つの大きな特徴は、データをチェリーピックし、領域を過度に単純化していることだった。「そもそもソフトウェアはその時間と空間を使って何をしているんだ？」という感情的な訴えを何度もするが、その問いに真剣に答えようとはせず、答えがないことを誤った答えの証拠のように使っている。機能的に同等でない複数のソフトウェアを、性能だけが違うかのように比較することもある。
非効率の社会的・環境的・ビジネス上のコストや、より効率的なソフトウェアについて語るべきことは多いが、現代のソフトウェアが、本来なら何も作れなかった人でも、自分に必要な「悪い」ものを作れるようにしている点も議論に値する。構造エンジニアが「十分に強い」ものを選ぶように、現代の開発者も「十分に速い」ものを目標にすることが多い。
議論の材料は豊富にあるが、この記事は感情的な怒りにとどまり、実際の理性や論証を扱えていなかった。一部の主張には真実があるが、記事自体は議論する気がないことを明確にしたのだと思う。
ネットワークも数kbpsの2Gではなく、数百Mbpsの5Gや光回線である可能性が高い。結局、行動は言葉より雄弁で、社会全体が「より速いソフトウェア」という公理に従っているなら、事実として受け入れてよい。
特に「開発者の時間のほうが価値がある」という主張と同じ場所から出てきた公理であり、違いは誰の時間を節約するかだけだ。
開発者が低スペック端末でもテストしなければ、この問題にはまったく気づけない。本当の問題は技術面よりも、コードが遅すぎるという不都合な真実に直面したとき、一部の開発者が防御的になり、まず議論から始める態度にある。プロダクトマネージャーと席に着いて、プロファイリングと最適化の時間を確保し、最初から作り直さずに性能問題をどう緩和するかを見るべきだ。
BASICやSQLも昔から、人々が「悪い」何かを作れるようにする目的を持っていたし、Fortranや今では消えた多くの言語・技術も同じだった。
PythonやJavaは、好意的に見ても保守的で、70年代のプログラミング言語の発展を考えると、実際には時代錯誤と呼ぶべきだ。JやPrologはRustやGoより概念的にははるかに先を行っているが、より早く作られた。C89からC23まで積み重なったCは現代言語なのか、C23だけが現代的なのか、C89とC23の間に本当に大きな違いがあるのかも曖昧だ。
作られた時点や想像上の進化系統樹でないなら、現代性を定義する別の方法があるのか気になる。
昔からある不満だ。私たちが当然と思っている多くの利便性にはコストがあり、そのコストは大きく積み重なる。4K画面は800x600よりピクセル数が17倍多く、32ビットカラーを使うため、現代のディスプレイ向けグラフィックの生のサイズは約68倍大きくなる。
以前は静止画像で十分だったが、今では高品質・高フレームレートのアニメーションが標準だ。Arial Unicodeは15MBのフォントで、Windows 95を動かしていた大半のコンピュータのメモリには収まらなかっただろう。
どこでもスペルチェックが当然になり、こうしたものが積み重なる。それでもコンピュータをはるかに快適にしてくれる。16色のビデオモードや、非常に面倒な回避策なしには英語以外の2言語を同時に使えなかった時代が恋しいとは思わない。
しかし、待ち時間を退屈に見せないためだけのアニメーションは欲しくない。Unicodeにもコストを払う価値はある。
それでも1981年にそうだったように、グリフを1桁ミリ秒以内に画面へ描画できるべきだ。ピクセルとグリフは増えたが、それは可能であり、単に優先事項ではないだけだ。
高性能BMWに10万ドルを払ったのに、エンジニアが0-60mphに30秒かかると言い、ユーザーは性能の専門家ではないのだからそのまま受け入れるべきだ、というのに似ている。
現在の組織でも似たような流れを見た。初期にチームが小さかった頃は、細部が重要だった。遅くてはいけないし、アニメーションは滑らかであるべきで、スクロール速度と読み込み時間が重要であり、ユーザーの効率を高めるために最も効率的なプロダクトを作ろうとしていた。
チームが大きくなるにつれて、価値は開発者効率を高める方向へ変わった。より多くの抽象化、レイヤー、フレームワークが入り、開発者の1日を節約する代わりに、ユーザー全体の数百万秒を費やすトレードオフが受け入れられるようになった。
違いは可視性にある。経営陣は開発側のコストは見えるが、少し速い実行時間、より良いキャッシュ、より滑らかなスクロールの利益は見えない。測定されていないからだ。組織が測定可能な数字だけを気にする段階に至ると、こうした流れは自然に見える。
もちろん、AIが私たちの書き損じたもの、またはAI自身が書き損じたもの、そして原文が予測するように非常に非効率なAIそのものまで、すべて修正できる段階に達するまでの話だ。
自動車は外部からの石油ショックが来て初めて最適化され、それすら非常に不均一だった。実際、非効率な製品は顧客がより頻繁に交換しなければならないため、より収益性が高い場合が多い。1年後に裂ける粗悪なiPhoneケーブルは、Appleが交換品の費用を何度も請求できるようにする。白物家電はより頻繁に壊れるが、より安く作られ、1台あたりの利益を高める。重要なのは販売後の使用効率ではなく、生産効率だ。
ソフトウェアにおいて資本主義は、新しい自動化を可能な限り早く大量に投入し、消費者にエネルギーと時間の浪費を背負わせる形で機能する。生産チェーンはますます標準化・最適化され、React開発者やKubernetes管理者を倉庫労働者のように置き換えられるようになり、それに伴う賃金圧力も生まれる。一部の自動化は、会計用語を難解にして職業を正当化するような自己正当化に近く、残りは利益に関するものだ。
すべてにはコストがある。計算コストや悪化したユーザー体験が十分に大きければ、効率を最適化する。MLモデルがその例だ。それ以外の場合は最適化しない。エンドユーザーが、機能を減らしてまでそれを望まないからだ。
自動車も昔は燃費が悪かったが、燃料費と環境への懸念によって顧客が別のものを望むようになり、変わった。多くのエンジニアは、自分が顧客のための製品を作る対価として給料をもらっているという事実を忘れている。
また原文の筆者は、古いWindowsやLinuxマシンが完全に起動するまで待ったことがないようだ。現代のバージョンは顧客が望んだため、はるかに速く起動する。携帯電話は24時間つけっぱなしなので、数か月に一度の起動に時間がかかることは顧客が気にしない。
私のBIOSはPOSTに20秒ほどかかり、これが正常だという。その後のOS起動は約10秒だ。
医師やエンジニアも新薬や新しい電源を開発する対価として給料をもらっていると言えるが、こうした分野は繊細で重要なため、政府による管理が何層にも存在する。ソフトウェアにはまだそのレベルの管理がない。
彼らには環境そのものを形作る力があり、「顧客の要求」の結果を大きく方向転換させることができる。
この記事は2018年の記事で、以前にも何度か議論があった。
https://news.ycombinator.com/item?id=18012334 (Sep 2018)
https://news.ycombinator.com/item?id=21929709 (Jan 2020)
https://news.ycombinator.com/item?id=31798580 (Jun 2022)
深く共感する。開発者として、私たちには選択肢があることを覚えておくのが重要だ。すべてについて選べるわけではないが、よりましな代替案を選ぶことはできる。
Nodeを必ず使う必要はない。.NETやJVMエコシステムでも、優れた後方互換性のあるソフトウェアを書けるし、10年後にも修正なしで動くと期待できる。
シングルページのWebページを必ず作る必要もない。クリックするたびにページ全体を再読み込みする昔ながらのHTMLもうまく動くし、現時点ではむしろレイテンシが低いかもしれない。
デスクトップアプリをChromiumで必ず作る必要もない。UIフレームワークを立ち上げるのに少し手間は増えるが、品質はそれに見合う。決定権が常にあるわけではないが、あるときは悪い選択から抜け出すべきだ。