Rule 6 of 38 · Chapter I — Start With the Problem
Delete before you add
Why this rule exists
Every line of code is a liability: something to read, test, and keep working. Teams reach for adding because it feels like progress, while the cheapest improvement is often removing code that no longer earns its place. Deleting first shrinks the surface area a new feature has to fit into and frequently reveals that the addition was unnecessary.
In practice
Before adding a feature or a branch, ask whether removing something gets you there instead: a dead code path, an unused option, a redundant abstraction. Prune first, then build on the smaller base. Keep an eye on flags and configuration that outlived their purpose, and delete them once the decision is settled.
When it doesn't apply
Do not delete what you do not understand; code that looks dead may serve a subtle or occasional purpose. When history or auditability matters, archive rather than erase, and confirm nothing depends on it before removing.