また、古典的な意味では「2番目のシステムの効果」は、他の人のコードの病理学的嫌悪や絶え間ない書き換えとはわずかに異なりますが、これらの両方のケースには共通点があるため、これらの両方の症状を一緒に考慮することは理にかなっています。
2番目のシステムの古典的な効果
側面をよく見ると、子供を育てるときに、2番目のシステムの効果が見事に現れていることがわかります。 祖父母は、自分の子供の教育と同じように、孫の教育に関係しないことがよくあります。 そして、両親自身が非常に頻繁に自分の問題を解決しようと試み、子供たちに興味のあることへの愛を植え付け、子供たちが満たされていない目標を確実に達成しようとします。
多くの開発者とアーキテクトもソフトウェアシステムの作成に魂を注いでいるので、新しいバージョンの頭脳を開始するときに、すべての間違いと欠点を修正し、完璧なシステムを作成しようとするのは驚くことではありません。 さらに、最初のシステムの成功に触発されて（障害が発生した場合、すべてがシンプルで、システムの2番目のバージョンに到達しない）、開発者は既存の個人的な知識に基づいて一般的な結論を導き出すのに十分な知識と経験があると考え始めます。 これにより、ソリューションの時期尚早な一般化が行われることが多く、これは時期尚早な最適化（*）に劣らないと考えられています。
2番目のシステムを作成する際の別の問題は、システムの廃止された機能が完成し、根本的に新しいアプローチとソリューションが開発されていない場合の値の誤った再評価です。 これは、誰も必要としない機能の驚くべき実装につながります。これは、純粋に美的な観点からは有用ですが、システムの成功にはほとんど役立ちません。
これらの問題はすべて、フレデリックブルックスの「神話上のマン月」で説明されており、この問題の説明に加えて、その解決策に関する推奨事項が示されています。 そして、Andy HuntとDave Thomasによる別の素晴らしい本「Pragmatic Programmer」のかなり前に出版されましたが、Brooksは、プラグマティストの本で絶えず聞かれる同じアドバイスを提供しています：極端ではなく、プラグマティズムと自己規律です。
シンドローム「しかし、すべてをnafigに書き換えないでください」
あなたと私は、隣のチームが行った以前のシステムの開発が失敗した理由を知っていることに同意します。 今、私が開発をリードする場合（私はその建築家/リード/開発者であり、必要なオプションを強調します）、私はすべてを異なって行います、そして私たちは間違いなく6ヶ月間の期限を破らず、4倍少ないグリッチがあります。
しかし、問題は、ほとんどの人が他の人の失敗をsome慢に見ていることであり、近視眼的には自分のほうがうまくいくと信じています。 プログラマーの87.5％は、この仕事をもっとうまくやったと信じており、実際にはもっとうまくやったと思うのは2.5％（**）だけです。 残りは単に「独自の方法で」それを行ったはずですが、時間、品質、機能の面では同じ成功を収めました。
プログラマーに加えて、マネージャーや顧客もそのようなゴミに苦しんでいます。 誰も現在のバージョンを理解していないという理由だけで、システムを書き換えるために「提供」された状況に何度も遭遇しましたか？ さらに、インディアンの群れが歩いていた同じシステムのコードから独立して要件を釣り上げることが提案されました。 したがって、どんな種類のがらくたが起こっているのかを理解することはすでに非常に難しく、その結果であるべきことは、10歳の子供に対する相対性理論と同じくらい明確です。
その結果、新しいシステムの品質は、開発チェーン全体で最も弱いリンクによって決定され、要件がなければ、もはや高くなることはできません。 したがって、彼らは同じ卵を得るが、側面図は、しばらくの間新しいシステムがより「拡張可能」になるが、それは新しいシステムにそれを転送する過程で既存のロジックを機密解除したそのペアの戦闘機にとってまだ理解可能であるためである。
必要に応じて、2番目のシステムのシンドロームを克服できる場合、または少なくとも臨床例のリスクを大幅に減らすことができる場合、書き換えの問題に対処するのはやや困難です。 書き換えの傾向がプログラマや建築家の魂に隠されている場合、同様の方法で対処する必要があります。 実際、簡単ではない場合もありますが、橋を燃やして最初からやり直す必要がありますが、ほとんどの場合、そのような試みは同じプラグマティズムと注意で扱われるべきです。
これがマネージャーまたは顧客の要件である場合、この場合、ほとんどの場合、単に代替手段はありません。それを書き換える必要があります。 千枚通しを石鹸と交換せず、可能な限り以前のシステムの主な間違いを考慮に入れないようにするだけの価値があります。
--------------------------------------
（*）ある意味では、時期尚早の一般化は、アーキテクチャソリューションの時期尚早な最適化と見なすことができます。 唯一の違いは、時期尚早な最適化に関しては、アプリケーションのパフォーマンスを不必要に改善することを目的とした不必要な労働リソースの浪費を指すことです。 また、時期尚早な一般化に関しては、同様の時間と労力の浪費に関係しますが、ソリューションの不必要な一般化に関係します。
（**）統計の78.5％が天井から取得されることが科学的に証明されています:)