これは、Manny Lehmanの言う「親密さ維持の法則：Law of Conservation of Familiarity」である。ソフトウェア製品が保守されるときには、斬新的なリリースがなされる。新たなリリースの各々には、ある量の成長（すなわち、以前のリリースで良く知られた振る舞いからのずれ）を含んでいる。平均をはるかに超える新たな成長を示すリリースは、「性能が悪く、信頼性が低く、障害率が高く、またコストと期限が超過する」傾向がある。そればかりか、成長の量が平均より多ければ多いほど、リスクが高くなる。この現象が起こる理由は、ユーザーにリリースしたソフトウェアのユーザーにとっての安定効果にあると思われる。ソフトウェアの変更が不安定の原因となるので（原理１８４，及び１９０）、リリース間の多数の変更は、新たなリリースによるプラス面で埋め合わせができないほどの不安定性をもたらす。それに加えて、開発者が製品について感じている心理的な親しみの量も、リリースとリリースの間で減少する。すなわち、ソフトウェアが修正される期間が長ければ長いほど、開発者はそれをよそよそしく「感じる」ようになる。製品がリリースされる度に再学習プロセスが行われ、開発者は再び親しみを感じるようになる。もし、リリース間にあまりにも多くの変更がなされると、あまりにも多くの変更がコードを「親しみのないもの」にし、品質を低下させる。
結論は、製品のリリース間で為される変更の量を、比較的安定させることが望ましい。
（２０１の鉄則：原理２００＜進化の原理＝親密さを維持せよ＞）
何度も言いますが、ソフトウェア製品（組み込みシステムを含む）においては、圧倒的に多いのが保守開発（派生モデル開発）で、新規開発は５〜１０年に１度行われる程度でしょう。その派生モデル開発をいかにしてうまく成し遂げるかは、ソフトウェアの開発組織において最大の関心事のはずです。この原理２００は、その際に生じる問題を“ベースに対する親密さ”という観点から注意を促しているのです。
実際、ここでいう親密さを失ったために、５年経っても開発が終了せず、ついに製品として日の目を見ないで終わったケースもあります。また、前のプロジェクトが遅れたため、当初の予定よりも短くなった期間の中で、逆に、遅れを取り戻そうとして、要求を盛り込み過ぎたり、開発が遅れがちになった状況で小刻みに仕様が追加されたことで親密さを失ったケースもあります。
新規開発と派生モデル開発とでは、開発作業に大きな違いがあります。もっとも、派生モデル開発の中の追加の新機能の部分の開発方法は、いわゆる「新規開発」とよく似ていて、そこで実現が求められている機能（仕様）を、データ構造やプログラム構造の設計も含めて一括して実現する方法で対応しますが、変更の部分の作業方法は違ってきます。残念ながら、現実の多くの現場では、このことを意識していないため、納期を外すことなってしまうのです。しかも、開発プロジェクトの大半が派生モデル開発ですから、事態は深刻なわけです。
それに対して変更部分は、変更仕様の一つひとつに対して、それを実現するための変更カ所を見つけ出していき、変更内容の矛盾などに注意しながら変更仕様全体の対応方法を確認した後に、ソースの変更に取りかかります。
このとき、ある変更に対する影響範囲について考える事ができるのは、“ベース”の機能や実現方法が安定しているからであって、今回の派生モデル開発に於てそのベースの機能や実現方法の多くが変更されることになっている場合、まだ、変更結果が確認されていない状態の上に変更しなければならないような事態に陥ってしまう危険があります。つまり、この変更の仕方でうまくいくかどうかを判断しにくい状態になってしまうわけです。この問題は、テストに於ても生じてしまい、その動きが正しいものかどうかの判断に手間取ることになります。まるで、不安定な地盤の上に家を建てようとしているようなものです。
従って、あまりに変更カ所が多く、ベースに対する親密性を損なうような状態では、新規開発に切り替えるこもとも選択肢の一つですが、派生モデル開発であっても、２回以上の「フェーズ」に分けて取り組む方法もあります。変更量が多いのであれば、もともと開発に投入する時間やコストがかかることは想定されているでしょうから、開発を複数回に分けた方が賢明です。
一方、新規開発で進めるにしても、完全な新規開発にはならないでしょう。既存のソースの中から「利用可能な」モジュールを選んで、再利用することを考えるでしょうが、この場合、また違った配慮が必要になります。確かに、“それ”は動いていたモジュールであったかも知れませんが、動作環境が変わることから起きる僅かな仕様の相違や、前提条件や動作条件、終了条件などについて十分に検討しなければなりません。実際問題として、ハードの世界でこの種の問題が多く発生しているようです。
開発作業の多くがこのような派生モデル開発である以上、これに上手く対応できないと、まれに（５〜１０年に１度）起きる新規開発に対応できなくなります。すでに述べたように、派生開発と新規開発とでは、必要とするスキルが異なります。その上、新規開発の機会は、滅多に無いのです。突然、「最近、ソースも見にくくなったし、時代も変わってきたので、次回は、新規開発で・・・」という声が上がるのです。派生モデル開発を中心にやって来た人たちにとっては、簡単には新規開発はできません。要求仕様の書き方は、追加機能のところで少し慣れているとしても、「全体」を扱ったことがないというのは、大きな障害なのです。ましてや、「時代も変わっているので、新しい言語で・・」となると、これはもうほとんど勝ち目のない戦いに挑むようなものです。
派生モデル開発を何度体験しようと、それだけで新規開発ができるわけではないのです。数少ない、新規開発の機会に対応するには、派生モデル開発で「親密さ」を失わないようにしながら、納期通りに仕上げる方法を手に入れ、その上で、時代の要求を先取りするように勉強し、研究していくしかないのです。