Codeの美しさと価値

技術的負債は金融の負債と似ています。金融の負債と同じように、技術的負債にも利息を支払わなければなりません。この支払いは、将来の開発で必ず発生する余計な努力というかたちで支払うことになるでしょう。

InfoQ: 技術的負債を解剖する
http://www.infoq.com/jp/news/2009/10/dissecting-technical-debt

これは全くそのとおりだと思います。Codeの複雑さというのは指数的に増えるので。
「汚い」構造は、将来のアップデート時に余分な利子(アップデートコスト)を必要とします。その利子を支払えないためさらに安易な方法がとられやすく、さらに将来支払う利子が増えてしまうという意味で、負債と全く同じ構造をしているといえます。

負債を負う理由があるとしたら、将来的に価値がある何かを買うときだけです。極端にパフォーマンスを高くすることができるとき、先行してサービスを公開するメリットが非常に大きいとき、くらいだと思います。前者の場合だと指数的なハードの性能向上で将来問題が緩和される可能性、後者の場合では将来行うべきリファクタリングのデグレリスクがあるため、これらの要素を十分吸収できると判断できるときのみでしょう。目先の中途半端な利益のために負債を負うのは明らかな間違いです。もちろん、アップデートが予定されていない場合もテストフェーズでの修正がありますし、運用時に何らかの障害が発生するリスクもあるため、このコストを潜在的に負うことになります。

しかしながら、行動に移すことは非常に難しいかもしれません。借りる側もその意味をよく理解しているはずの金融的な負債でさえよく利用されるからです。この構造が明示的に理解されていないソフトウェアではなおさらです。チームで開発する場合はさらに難しいかもしれません。メンバ全員がこのことを十分理解する必要がありますし、「政治」が入ってきます。

優秀なプログラマが優秀なメンバとしか仕事をしたがらない理由もこれが背景にあるのではないかと思います。チームの人数増加に伴って極端にプロジェクトの成功率が下がると考えられるため、チームは信頼できる少数の人たちで構成されるのが望ましいかもしれません。