DRY原則の話をします。
ここでいう横展開とは、「ある箇所で発見・実施された改善手法を他の箇所にも当てはめること」を指す。特にシステム開発の現場で、障害対応や殆ど仕様変更のような指示で実装に変更が加わった際、指摘された箇所以外に同じような変更をする必要があるとき、それを（漏れなく）実施することについて話す。
そのような横展開にはカスの横展開とカスではない横展開がある。
カスではない横展開の例として、他部門が開発する別製品について、特定の障害が見つかった時、その対応策を共有することが挙げられる。アップデートしてねとかそういう奴だ。
カスの横展開は同一製品内での変更をその全ての機能に適用させることだ。
設計書であれ、実装であれ、ある記載の変更が別の記載を（必ず！）変更させるのであれば、それがカスだ。実務上どうしても発生してしまう（し、発生した時点で対応しなければならない）のは承知の上で主張するが、カスの横展開が発生した時点で、製品がカスであることを認識しておくべきだし、カスの横展開がないようにしておくべきだ。
これはシステム開発にはDRY原則という物が適用できるから成立する主張だ。例えば、家を建てるとき、１階のトイレに変更が加わったら、２階のトイレにも影響が及ぶとみて間違いないだろうし、それを回避することは難しいだろう。
DRY原則とは、システム内でのある知識は1カ所に書かれているべきというものだ。勿論、物理的制約などの理由で、そのように出来ない場合は多い。
例えば、スーパーで消費税の計算をしたいのであれば、*1.08と書くのではなく、毎回（或いは定期的に）消費税法を参照しておくべきであるが、実際にはそうしてはいない。そうしていれば、税率が変更されても一々値札を変える必要はないが、値札は印刷されている必要があるため、直接税込み価格が記載された紙として現れている。少なくとも、印刷する手前の計算式が現れる箇所で、1カ所だけ修正を施せばそのスーパーでは修正が完了するようになっているのが望ましい（そうすれば値札の張替えはなくせなくとも計算式は一度直せば済む。）
カスの横展開とはこの計算式を色んな所に記載しているために発生しているカスの作業だ。
カスの横展開の問題点は単純に作業量が増えて面倒である以上のことがある。
ある変更Xが類似の箇所Aを変更するが、箇所Bは変更を及ぼさないことがある
現在消費税は10%だが、8%から10%に上がらなかった物もある。
このとき、消費税が決まるロジックを1カ所に纏めれば、複雑怪奇にはなるとしても、読んで理解することが出来る。（これを消費税法という）
が、商品ごとに8%,10%､8%と振っていけばどうか、もはや振った値が誤りかどうかさえ分からなくなるし、次の改正時に（下がっていることを願いたいものだが）変更する際、どう変更してよいかもわからなくなる。
もし、横展開と称して、このような変更作業をすることになった時、作業者は最早変更指針などない状態で実施しなければならなくなる。もし変更指針など考えず、実施できるものであるのであれば、共通化が必要であるし、そうでなくとも、横展開の必要性が感じられるほどに共通があるのであればそれはひとところに纏めておくのがよいのである。いずれにせよ、横展開と称して設計書の森に探検に行く必要が出てきたのであれば、視野を大きくして問題を認識した方がいいだろう。無論、そんなことしている時点で解決など出来ないのであるが。
ところで、DRY原則というとやりすぎは善くない！と主張する輩が多く出る。どうせ編集距離を短くした修正をDRY原則と呼んでいるだけだからそう思えるだけで、系内の知識をひとところにすることにやりすぎなどないのだ。ただ、正しい知識形態があるだけである。やりすぎのDRYはなく、誤った知識体系だけがある。
ところで、重力加速度は9.8毎秒毎秒というのは余りにも行き過ぎたDRYだ。
