機能は追加よりも変更したり削除するほうが難しい
@kameike: この話をシステム開発の経験がない（東京の）人にするときに、「渋谷駅の銀座線のホームをちょっとずらす工事」と、「高輪ゲートウェイ駅を作る工事」銀座線の方が工期も予算もだいぶかかったという話を好んでしています。 @naoya_ito: 予約にまつわる業務ロジックを扱っていると、システムの複雑性に関与してくる大部分は、新規予約やキャンセルではなく、予約の変更に起因している キャンセルして取り直し、で済めば業務ロジックを冪等にできるんだけど、日々料金や在庫が変動する世界ではそういう設計にはできず
うちは複数商品を購入したときに利用したポイントを、一部商品を返品したときにどのようにポイントを返すか、またそれらも踏まえてポイントの有効期限切れをどのように計算するかは本当に難しい
変更や削除は難しい
既存システムの運用が変わるため考えることが非常に多い
本当に消してもいいものなのか
消したとして、既存動作に影響しないか
既存動作に影響しないことはどうやってテストする？
例えばGmail, Facebookでログインできる状態からFacebookログイン機能を削除するとしたらかなり慎重に事を進めねばならない→Facebookで登録しているユーザーはどうする？
これらの確認点を網羅した上で後方互換性を保つように緻密に設計する必要がある そこのアダプタを書けば良いので
そうではない場合はさらに難易度が上がる
機能追加は既存影響を確認しなくても良い
作るだけに比べると影響範囲が自明で、変更と削除に比べれば追加の方が楽という話
どこが変わりうるか？はその時点では分からないことの方が多い
書いたコードは全て負債となる
捨てやすさを基準にすると
小さく作ろう