私たちはソフトウェアを壊している

• 私たちは、機能を追加したり特定の部分を最適化したりするときに、もはや複雑さを考慮しないことでソフトウェアを壊している
• 私たちは、複雑なビルドシステムによってソフトウェアを壊している
• 私たちは、ばかげた依存関係の連鎖によってあらゆるものを肥大化させ、脆弱にすることでソフトウェアを壊している
• 私たちは、新しいプログラマーに「Don’t reinvent the wheel!」と言うことでソフトウェアを壊している。しかし、車輪の再発明は物事がどう動くのかを学ぶ方法であり、新しい別の車輪を作るための第一歩でもある
• 私たちは、もはやAPIの下位互換性を考慮しないことでソフトウェアを壊している
• 私たちは、すでに動いているものを書き直すよう駆り立てることでソフトウェアを壊している
• 私たちは、新しい言語、パラダイム、フレームワークが出るたびに飛びつくことでソフトウェアを壊している
• 私たちは、既存の複雑なライブラリを扱う難しさを、直接実装することと比べて常に過小評価することでソフトウェアを壊している
• 私たちは、XYZの事実上の標準は、自分たちの特定の用途向けに直接実装できるものより常に優れていると考えることでソフトウェアを壊している
• 私たちは、コードコメントは役に立たないと主張することでソフトウェアを壊している
• 私たちは、ソフトウェアを純粋な工学的学問にすぎないと誤解することでソフトウェアを壊している
• 私たちは、もはや縮小不可能なシステムを作ることでソフトウェアを壊している。どんなシステムでも、単純なことは単純に達成できるべきだ
• 私たちは、できるだけ速くコードを生み出そうとし、できるだけよく設計されたコードを作ろうと努力しないことでソフトウェアを壊している
• 私たちはソフトウェアを壊しており、最後に残るものは、もはやハッキングの楽しさを与えてくれないだろう

[dohyun682]

車輪の再発明 <-> すでに書いているものの再発明

この2つは、互いに完全に相反する概念ではないのでしょうか？

[roxie]

コメントブームが来る

[tujuc]

刺さりますね（笑）。後輩の方々が入ってくるたびに……どう教えればいいかなと思っていたのですが。良い方法になりそうです。

[ilikeall]

もうやめて（泣）

[bus710]

....ただ静かにしておきます...

[laeyoung]

韓非子が語った「国が滅びる10の兆し」と重なるように見える点が多いですね。

[GN⁺]

Hacker Newsの意見

• Jonathan Blowの講演を思い出す。ソフトウェアは管理しなければ、他のあらゆるものと同じように劣化する

  • ソフトウェア技術は表面的には進歩しているように見えるが、実際には衰退している
  • ハードウェアの改善と機械学習が進歩の幻想を与えているが、ソフトウェアの根本的な堅牢性と信頼性は悪化している
  • 現代のソフトウェア開発は不必要に複雑化し、単純な作業ですら難しくしている
  • このような複雑性はプログラマーの生産性を低下させ、世代間の知識継承を妨げている
  • 社会はバグが多く信頼できないソフトウェアを正常なものとして受け入れるようになっている
  • OSから開発ツールに至るまで、あらゆるレベルでソフトウェアシステムを単純化しなければ、文明は歴史的崩壊に似た技術的後退の危険に直面する

• Dieter Ramsの「良いデザインの10原則」を思い出す

  • 良いデザインは革新的である
  • 良いデザインは製品を有用にする
  • 良いデザインは美しい
  • 良いデザインは製品を理解しやすくする
  • 良いデザインは目立たない
  • 良いデザインは誠実である
  • 良いデザインは長持ちする
  • 良いデザインは最後の細部まで徹底している
  • 良いデザインは環境に優しい
  • 良いデザインは可能な限り少ないデザインである

• 2000年代に会社で働いていた経験を共有

  • 数十台のコンピューターで作業を行い、サーバールームを構築し、3TBのデータを保存するためのSANを構築した
  • 自社開発のVB6ジョブスケジューラでObject Rexxスクリプトを実行し、コンピューター間の作業を調整した
  • 内部ロードバランサー、Webサーバー、メールサーバー、FTPサーバーを使ってファイルを送受信し、自社ソフトウェアを使用した
  • 今ではyamlファイルとクラウドサービスを通じて、1週間以内に全体の設定を再現できる
  • サーバーアーキテクチャが「抽象化」された
  • 下位互換性への批判。Windowsの問題点の1つとして指摘される
  • Appleは下位互換性を壊し、5種類のプロセッサ移行を行い、ARMチップで32ビットコード互換性を削除した

• 相反する意見が多い

  • 下位互換性を維持しながら複雑性を避けるべきだ
  • 巨大な依存関係ツリーを避け、自分で車輪を再発明すべきだ
  • すべての要求を満たす唯一の方法は、誰もコードを書かないことだ
  • 1日に1回くらいはそうなってほしいと思うが、誇れることではない

• 最初の職場での経験を共有

  • Cでソフトウェアを書いており、商用ソフトウェアを現実的に書ける唯一の言語だった
  • ビルドできる人は1人しかおらず、商用ビルドツールを使っていて、そのツールを使えるのもその人だけだった
  • ビルドには数時間かかった
  • 私たちはうまくやっていると思っていた

• ソフトウェアを破壊している理由についての意見

  • XYZのデファクトスタンダードは、自分たち向けに最適化されたものより優れていると常に考えることで、私たちはソフトウェアを壊している
  • 汎用的なアプローチは、多くの問題に対する浅い解決策へ簡単に切り替えられる
  • 技術者たちはこうしたアプローチを好む。特に転職が多いため、いくつか持っている
  • しかし、カスタムソリューションは汎用的なものよりはるかに高い性能を発揮する

• あらゆる主張にはトレードオフがある

  • あらゆる場合で、何かを犠牲にして別のものを得る
  • 時には車輪を再発明しないことが妥当だ
  • 時には学習のために車輪を再発明する必要がある
  • 全体として、私たちは壊している以上のものを創り出している
  • 否定的な立場を取る必要は感じない

• antirezは尊敬しているが、この投稿は議論に耐えない耳触りの良い短い断言で満ちていると思う

  • 例: 初心者は車輪を再発明すべきではない
  • 彼らは与えられた文脈で利用可能なツールを使うべきだ
  • 実験したいなら、自分自身のコンパイラを書くべきだ
  • しかし、それを本番環境で使うべきではない
  • 逆方向のAPI互換性は、ほとんどの場合ビジネス上の判断だ
  • すべての文を「私たちはソフトウェアを壊している」で始めるのは役に立たない
  • 実際よりもはるかに陰鬱に聞こえる

• 複雑性/依存関係グラフについての意見

  • 無作為なアプリケーションの複雑性/依存関係グラフは完全に狂っている
  • ファームウェアやOSは含まれていないが、十分近い
  • 推移的依存関係の問題を解決しなければならない
  • OS（Win32 API、Linux syscalls）を、Cで書かれるあらゆるものにとって唯一のハード依存関係と見なす
  • Java/Pythonに移行すると、このレイヤーを制御できない
  • あらゆるライブラリに依存するのではなく、特定の状況に合った数百行のコードを書くことが必要だ
  • 保守の負担は増えるが、依存関係にも保守が必要だ
  • 誤ったAPIを持っているかもしれず、互換性を無作為に壊したり、放棄されたり、マルウェアになったりする可能性がある
  • 有用なプロジェクトにおける個人的な最大行数は、Java/JS/Pythonで5-10KLOCだ
  • 数時間でレビューでき、数年後でも簡単に修正できる

• ソフトウェアを壊す要素

  • Leetcode面接、履歴書駆動開発、頻繁な転職、成長投資詐欺、メトリクス遊び、昇進追求、スプリント茶番、組織図のあらゆるレベルでの虚勢、業界の無関心