リリース前のエラー率が高いコンポーネントは、リリース後のエラー率もまた高い。これは開発者にとってはがっかりさせられるニュースだが、実験的なデータ（及び、あるコンポーネントにエラーがたくさん見つかるほど、さらにもっとたくさん見つかる、ということに言及した原理１１４）によって、完全に支持されている。最良の提言は、バグをたくさん出した経緯のあるコンポーネントを捨ててしまって、他のものと置き換え、そして最初から新たに作り直すことである。すでに悪いコンポーネントを作るのに（悪い）金を無駄にしたのだから、これを直すためにまだ使っていない（良い）金を悪いものを直すために投じてはならない。そうではなく、最初から良いものを作るために投じるべきである。
（２０１の鉄則：原理１９０＜進化の原理＝リリース前のエラーはリリース後のエラーを生む＞）
この問題を経験している人は、けっして少なくないのではないかと思われます。でも原理１９０での警告通りに、作り直せたことは少ないのではないでしょうか。多くの場合、その判断のタイミングを失っており、作り直すための時間が確保できずに、継ぎはぎだらけのまま世に送りだしているのではないでしょうか。気持ちとしては、これで何とか動いて欲しい、というところでしょうが、残念ながら、半年後に、エラーの報告に悩まされることになります。自分が蒔いた種だけに、どこにも持っていくことが出来ず、その時の作業を中断しながら対応するしかないのです。
もちろん、その時点で書き直すようなチャンスはありません。継ぎはぎの上からさらに継ぎを当てながら、つじつまを合わせるしかないのです。そしてこれは彼の戦意を喪失させるのに十分な出来事でもあるのです。半年前に、的確な判断を下せなかったために、今また新しいプロジェクトの時間が横取りされてしまうのです。そして、半年前と同じように、エラーを多発させながら、そのまま世に送り出すのでしょうか。
この問題に対処するには、プログラムのエラーデータをしっかり集めることが必要です。多くの組織では、評価グループでの評価においてはバグデータは記録されますが、設計（開発）部内での結合テストの段階で発見されたバグは記録されていないのではないでしょうか。ましてや担当者レベルでの単体テストに至っては、バグが記録されることは皆無に近いのではと思われます。確かに、担当者レベルの単体テストの段階で発生するバグの中には、原理１９０の範囲外のバグもあるでしょうが、現実問題として、設計者自身がコードを書いている状況を考えると、殆どのバグは原理１９０の傾向を探るのに参考になるものと思われます。
単体テストのバグが記録されない理由としては、数が多いということと、自分の恥を曝すような気持ちになることが考えられますが、もし数が多くて書いておれないというのであれば、そのような技術レベルの状態で仕事に携わること自体が問題となる可能性があります。もちろんその時点で原理１９０に抵触します。やはり、そんなにバグを出さないように学習し技術レベルを引き上げる必要があります。
一方、初期の幼稚なバグを知られるのが恥ずかしいと言うのであれば、それは考え違いも甚だしいということになります。仕事は、自分の趣味でやっているのではありません。その仕事に対して対価を払ってくれるお客さんがいることを忘れてはなりません。
もう一つの問題は、特定のコンポーネントでバグが多発していることは分かっていても、プロジェクトのどの時点で分かるかと言うことによっては、書き直しの判断が入る余地が無いということも考えられます。やはり、ある程度早い段階でそのような傾向が表面化する仕掛けが必要です。ただ、作業が計画されず遅れがちな場合は、いろんなプロセスが省かれてしまいます。バグデータの収集や傾向の判断も例外ではありません。そのため、バグの繰り越しが起きている組織では、ほとんどこのような判断が入る余地は無くなってしまいます。
また、書き直しに当たっての時間の見積りが出来るかどうかも重要な問題です。そこまでの作業において、成果物のサイズ見積りも為されていない状態では、また、適切な設計書など、この後で量的な判断に使える資料がなければ、書き直しの判断は難しくなります。実際、書き直しに入ったケースでも、それにかかる作業の見積りが為されないまま、まるでこの判断が「正義の選択」とでも言うかのような姿勢で取りかかっているのを見ることがあります。多くの場合、最初に書いた人と違う人が書き直しの作業に当たるということも、そのような姿勢になってしまう原因かもしれません。
何れにしても、エラーが多発しているコンポーネントを早く発見し、適切な判断をしなければなりません。このまま作業を進めることの混乱と損失、そしてここで書き直すことの工数のバランスです。
いろんな事情で、今からでは書き替えに間に合わないとしても、それが必要と判断されるなら、次のプロジェクトの為に書き直しの作業を計画すべきです。そして、できれば評価グループの作業に並行して書き直しに取りかかるべきです。もちろん、評価中のソースを変更するわけには行きませんので、構成管理上の注意が必要ですが、そうすれば、このプロジェクトに間に合わなくても、次のプロジェクトでは確実に直すことが出来ます。場合によっては、半年後にバグが発生したときに、入れ替えの準備が整っていれば、そのような判断を下すこともできます。逆にそうでなければ、以後のプロジェクトで書き直す機会は無いかも知れません。
結局、この種の問題が起きるのは、ＳＥ（プログラマ）の能力の不足、あるいは担当部分とのミスマッチが根本のところに存在しているのです。現実問題として、そこに居る人達で案件を処理しなければならないという組織の事情が背後にあります。いつでも優れた人が集められるわけではないのです。
したがって、プロジェクトの最初に、この種のリスクの存在に気付かなくてはなりません。プロジェクトのマネージャーやチームのリーダーが、担当者の能力を把握していないために、リスクの発見が遅れてしまうのです。その担当者のこれまでの作業の「成績」が残されていれば、今回初めて参加する人であっても、リーダーは、最初にそれをチェックすることができます。もちろん、以前から自分の下にいて作業をしているのであれば、きちんとそのようなデータを把握していれば済む問題です。組織としてそれを怠ったこと、そして、最初にリスクの抽出を怠ったことが、原理１９０で指摘するような事態を招いてしまうのです。