クイーンズランド州の沿岸にある熱帯雨林でしばらく時間を過ごした。木をつたわりながらだんだんと下に下りていく。最後には自分の根を土に下ろしてしまう。やって何年もかけて、幻想的で美しい形へと成長していくのだ。ストラングラーに絞め殺されてしまう。このメタファーは、重要なシステムの書き換えの方法を表すのに使えるんじゃないかと私は思った。私のキャリアの大半は、クリティカルなシステムの書き換えであった。書き換えなんて、新しいシステムに古いシステムと同じ動作をさせればいいだけの簡単なものだと思うかもしれない。書き換えは思ってるよりもずっと難しいし、リスクがいっぱいなのである。移行日が不気味に迫る。既存の機能もそのまま使えるようにしておかなければならない。バグもそのまま新しいシステムに残さなきゃならない(!)なんてこともある。最後には古いシステムを窒息死させるという方法もある。この方法は難しそうに聞こえるが、私はこう思うようになってきた。私はいくつかの基本戦略がうまくいくのではないかと思っている。イベントインターセプション。これは段階的に機能を移行する際に使える。財産確保を可能にしてくれる。Stevensonがあるプロジェクトで非常に大きな成功をあげた。私はこのプロジェクトの様々な側面についてもっと記述してもらいたいと思っている。彼らはまだ古いアプリケーションを窒息死させるところまでは出来ていない。彼らは価値ある機能をビジネスにもたらした。そのことで彼らは、チームへの信頼性をも獲得した。プロジェクトが休止している今も、彼らは巨額の投資対効果をもたらしている。これは、多くの書き換えプロジェクトが成し遂げたものよりも大きい。優れているといえるのは、リスクが減少した点にこそある。頻繁なリリースによって、進捗をより注意深く観測することができる。多くのひとはストラングラーをまだ認めていない。コストがかかると思っているからだ(私もまだ確信していない)。書き換えで頻発する大量の「不必要な機能」を作らなくても済むだろう。重要な考えがもうひとつある。将来的に窒息死しやすいように設計するということだ。今日作っているシステムは、明日のレガシーシステムである。そのことから目をそむけてはならない。君は、今日の仕事から安らかにフェイドアウトすることが出来るのである。gmail.combliki-ja。