コードはリリースした瞬間に腐り始める

コードや機能はリリースした瞬間に技術的負債になる。なぜなら作るよりも消すほうが大変だから。

そのコードや機能が既存の他の機能に依存があれば、消しても大丈夫なようにリファクタリングする必要がある。これは、レイヤードアーキテクチャなど依存を綺麗に分離できていると、ある程度負担は軽減可能。また、既存機能にバグが出てないかをチェックする回帰テストの仕組みが必須。

少数のユーザーがその機能を使っていれば、そのコードと機能を削除することにより、クレームおよび離脱につながるかもしれない。

コードや機能を削除した後に開発バージョンをリリースする際、前のバージョンを使っているクライアントがバグらないように気を配る必要がある。

こうやって、消すのが大変だから、基本的にあまり使われてなくても、機能を削除することはない。バージョン番号をつけて、消したい機能を非推奨としつつも、古いバージョンを使っているユーザーに対してもサポートを提供することを続ける。

しかし、どちらのシステムがよりよいだろうか？

• 10個の機能があり、そのうち３個がよく使われ、7個はあまり使われないシステム。
• 3個のよく使われる機能のみがあるシステム。

システムの健康度を保つためには、本当に使われる機能やコードのみをリリースできる仕組みと、使われないコードや機能を削除できる仕組みを作る必要がある。