スクラップアンドビルドはmake clean && makeではないということ

Ruby から Java へのシフトで大統領選を乗り切った Twitter

この記事を読んで、思ったこと。
スクラップアンドビルドとは、老朽化した施設を廃棄し、より能率的な施設を積極的に開発していくこと。
まぁ文字通りなんですが。別にIT用語というわけではないです。

自分はメーカ系のエンジニアなのですが、新製品を開発しないことには儲けられないのです。
というわけで、既存カテゴリのの製品については鰻のタレのようにソースコードが使いまわしてFWを作っていきます。

鰻のタレの良いところは
・実績がある
・不具合が発覚した時に他の製品にも適用できる
などなどがあると思います。

逆に悪いところは
・設計が今となっては古かったりして拡張性がしょぼい
・今、流行のテストがない
・継ぎ足し継ぎ足しの繰り返しでカオスになっちゃっている
・ドキュメントとの整合性がない
最初の問題以外は運用にもよると思いますが、こんな感じは割りとあるあるなのではないかと。

スクラップアンドビルドする基準は

スクラップアンドビルドするコスト ＋ 得られるメリット ＞ 鰻のタレのメリット － デメリット

だと思うのですが、スクラップアンドビルドをするには勇気が必要だと思うのです。
原因としては
・鰻のタレのデメリットのコストが数字で出にくい＜＞スクラップアンドビルドするコストは数字で出やす
（しかも、大抵大きな金額になりがち）

いずれにせよ、必要性があると思われるならば真面目に検討して備えることが重要なんじゃないかなーと思います。（自分に対する戒め的な何か）