いわゆるサバイバー・バイアスです。あるVPが、以前の会社でうまくいったからという理由でエラスティックサーチを使うように命じました。結果的に、私たちにも合っていました。VPの言うことを聞いて技術的な決定を下し、エラスティックサーチを使いましょう。

実は私も似たようなことを言いに来ました。

ああ、ベイビー、これが私のシニア開発者だ。避ける人、減らす人、リサイクルする人。彼らはできるだけ開発を避けたがります。これが良い時もあれば、改善を積極的に試みるのが最善の方法である時もあります。良いシニアは、その時を見極めることができるのです。

OPが伝えようとしているメッセージを見落としているかもしれないよ。強調された特性は、すべてより良い安定性につながるからなんだ。

同意する。文脈が重要だよね。シニア開発者としては、複雑さやリスク、利点と欠点を理解する必要がある。ビジネスサイドも理解しないと。スタートアップか、すでにキャッシュカウの大企業かで、製品のコア機能を変更する際の影響は全然違うから…文脈、文脈、文脈だよ。

同じこと考えてたけど、再度その部分を読み返して気づいたことがある：>「はい、はい、もちろんこれは単純化されています。アイデアを明確に伝えるために、極端な例を挙げているのです。」全てのことに言えるけど、黄金の中庸が適用されるって、この記事が主張してると思う：>「'スピード'バージョンのシステムでうまくいったことといかなかったことが、'スケール'バージョンのデザインに影響を与えています。」

みんなが「これが昇進したらゼロから書き直す」と約束したことが何度かありましたが、結局実現しませんでした。古い名言：「一時的なハックほど永続的なものはない。」

だからこそ、十分に経験のあるエンジニアリングリーダーシップが必要なんだよね（ICリーダーシップと管理の両方）。もしエンジニアが非技術的なステークホルダーの言うことを何でも従うなら、責任の空白ができて、いつかは大惨事が起きる。最もCYAが下手な人が責められることになるよ。一方で、ほとんどのビジネス問題は、十分に視野を広げて「なぜ」をたくさん聞けば、ひどい一方通行の扉を通らずに合理的に解決できる。もちろん、どこでもエンジニアリングがそれを許可されるわけじゃないけど、許可されないところでは、経験豊富な人たちを維持できなくなる。彼らは自分の判断が評価される場所に行くだけだから。時には技術的負債がビジネスにとって正しいこともあるけど、十分に経験のあるエンジニアは、常に逃げ道を作ることができる。でも、システムの純粋さをビジネスの問題よりも優先することはできない。システムはビジネスによって支払われているから、それを見失ったら、影響力の基盤を失ったことになる。

だから、チームの誰も聞いたことがない言語で書かなきゃダメなんだよね。

何度かみんなが約束したのを思い出すよ。「これが昇進したら、ゼロから書き直す」って。でも、結局そんなことはなかった。なんでそんなことするの？ もし需要を満たしてて、必要な機能もあって、実際には再構築する必要がない「プロトタイプ」があるなら、なんでそんなに時間と労力をかけるの？ それは意味がないよ。プロトタイプや「概念実証」であることは、実際の問題を列挙できないなら本質的には関係ない。私は、技術的負債に悩まされてるチームと一緒に働いてるけど、彼らはそれが大きなリスクで、作業を遅らせるって文句を言ってる。でも、私たちのインシデントログを見ると、あまりインシデントはなく、プロダクションでリスキーなコードを実行してるせいで起きたものもない。リスクレジスターにも「このコードは古くてゴミで、過去のEOL依存がある」なんて項目はないし、どのチームも技術的負債がどのように、またはどれだけ彼らを遅らせているかを具体的に説明できたことはない。だから、誰もが「影響がない問題を直すのに時間を使ってほしくない」と驚くべきではない。逆に、あるチームはアプリを立ち上げる前に数ヶ月かけてリファクタリングしてた。彼らはそれを作った後、「もっと良くできる」と決めて、立ち上げ前にほとんどを再作成するのに多くの時間を費やした。彼らが自分たちの作品が気に入らないから、すべての価値が遅れたんだ。そして、当然リーダーシップチームはそれに怒って、今では信頼がほとんど残ってない。チームとステークホルダーの間で仕事の納品について良い会話が必要だけど、それがないと誰も幸せになれない。もしそれが起こらないなら、ステークホルダーが常に勝つことになる。

この問題は確実にAIコーディングエージェントが登場する前からあったけど、彼らによって悪化しているかもしれない。記事は「一つは捨てるつもりで計画しろ」という古いアドバイスで締めくくられてる。もちろん、私も『神話の人月』を読んだけど、どうやって意思決定者を納得させる？