WET - Write Everything Twice これは「三の法則」として聞いたことがあるな。

大学の頃から、すべてを2回書くことを推奨してるよ。

二回以上って、かなり低いハードルだよね。Programming Perlの引用とは矛盾しないと思う。

これには完全に同意するよ。ソフトウェアの美しさは、正しい抽象化が計り知れない影響を持つことにある。オペレーティングシステムやRDBMS、クラウドオーケストレーションみたいな大きな革新について話してるんだ。でも、世界の大多数のコードはそうじゃなくて、単純なビジネスロジックで、人間が人間の目的のために実行するアイデアやプロセスを表していて、抽象化に抵抗するんだよね。それでも人々は試みるけど、大手テック企業ではプラットフォームの創造が技術的な帝国主義やキャリア駆動の開発の一形態として広がってる。私のテックレビューのルールは、プラットフォームを持つには、三つの実証済みのユースケースが必要で、それらを結びつけることが共有システムの自律性制約によるネットマイナスにならないことを示さなきゃいけないってこと。

時間が許せば、二回書くのは理にかなってるし、機会があればそうすべきだよ。最初は少し探求的な感じ（もしかしたら捨てプロトタイプかも）で、二回目には問題をよりよく理解して、より良い仕事ができる。三回目は新しい抽象化を使う時で、ここが注意が必要なところ。フレッド・ブルックス（「神話のマン・マンス」）はこれを「第二システム効果」と呼んでいて、一度（本物で、ただのプロトタイプじゃなく）やったことに自信を持つことで、過剰設計で不必要に複雑な「バージョン2」を作りたくなることがあるんだ。抽象化や余計な機能を追加して「もっと良くしよう」と誘惑されるからね。

それでも、平均的なプログラマーよりも抽象化が進むことになるね。

同意するよ。1991年（『Programming Perl』が出版された年）から、どれだけ多くの抽象化の層が作られたか、ほんとに驚くよね。

そうだよね！コードの品質が負の価値や失われた命に関係ないわけじゃないよね？！さらに、> Tanがそんなにエネルギーをかけて作っていたアーティファクトについては、私は大体無視してた。でも、ポーランドのソフトウェアエンジニアのGregoreinがそれを分解して、結果は予想通りで面白くて教育的だったよ。Tanの「ニュースレター・ブログ・なんか」は、複数のテストハーネス（！）、Hello WorldのRailsアプリ（？！）、隠れたテキストエディタ、そして同じロゴの8つの異なるバリエーションが含まれてたんだ。その中の1つはゼロバイトだったけど。これらのソフトウェアに含まれている... /もの/ が攻撃の対象になりやすくする面積を増やしたと思う？

「価値生成」っていう言葉にはちょっと警戒してる。私にとって、この文脈では化石燃料で経済成長を促進するのと似てる。最終的にそれがネット利益につながるか（価値がそれに関わるコストや後で混乱を整理するコストより大きいか）は言うのが難しいと思うけど、短期的な価値だけで判断できるとは思わないな。

時間の無駄だね。200,000行のコードを読んで、短期間でこんなにコードを生成して本番環境に出すのが悪いアイデアだって証明するつもりはないよ。証明するのはそのコードを書いた人の責任だし。もしただのツイートのやり取りで、LOCを自慢してもっとLOC/秒を目指してる人を判断したいなら、もちろん判断するよ。バカみたいだし。