Optimize for deletion

Code should be optimized for change. Code that is easy to delete is easy to replace, rewrite, or rework. Rather than trying to predict future changes today, the principle favors deletable and rewriteable code that can be discarded without collateral damage.

Several well-known practices increase deletability. Separation of concerns, low coupling, and the single responsibility principle all result in code that can be removed without dragging unrelated parts along. High modularity helps by ensuring individual parts can be deleted in isolation.

The framing was popularized by Dan North’s essay on the art of destroying software and Kelly Sutton’s writings on deletability. Both argue that the ability to throw code away is a better signal of good design than the ability to extend it indefinitely.

Optimize for deletion sits alongside refactoring as a defense against software rot. When code is cheap to remove, accumulation and decay matter less because the system can be renewed piece by piece.