DDD本にあったリファクタリングの一節が気に入った

『エリック・エヴァンスのドメイン駆動設計』*1を読んでいて、リファクタリングについてよい記述があったので引用します。
「第13章より深い洞察へ向かうリファクタリング」の 332 ページからです。

変更を完全に正当化できるまで待つのは、待ちすぎというものである。プロジェクトはすでに重いコストを負っていて、先延ばしにすると変更するのがより困難になる。対象となるコードには今より手が入り、さらに多くの他のコードに組み込まれることになるからだ。

継続的なリファクタリングは「ベストプラクティス」と考えられるようになってきたが、ほとんどのプロジェクトチームは依然として慎重すぎる。コードを変更するリスクと、変更にかかる開発者の時間のコストを見込んでいるためだ。
しかし、それほど簡単に見抜けないのが、設計をぎこちないままにしておくリスクと、その設計を何とかするためのコストである。
リファクタリングを行いたい開発者は、その決定が正統なものであると証明するよう求められることが多い。こうした要求は理にかなっているように見えるが、もともと難しいものを不可能なほど難しくして、リファクタリングを抑制する（または見えない所で行わせる）傾向がある。
ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを正確に割り出せるような、予測可能なプロセスではない。

リファクタリングに対して拒否反応を示す人はたくさんいます。

「いかなる理由があろうとも、仕様変更とは関係のないソースコードを修正することは許されない」
というような内容が自社のどこかで指針的に書かれているのを見たことがあります。
（言わんとしていることはわかりますが…）

現在のソフトウェア開発では継続的なリファクタリングを支援するための手法やツールは十分揃っています。それらを有効に使い、リファクタリングを行なっていくことでソフトウェアを育てていくことは可能ですし、非常に有益だと思います。

そういう話をする際に、是非引用したい一節です。