Rule 28 of 38 · Chapter V — Complexity Has a Cost
Optimize for change
Why this rule exists
You will change this code far more often than you first write it, so the cost that matters is the cost of the next change, not today's keystrokes. Code optimized for a clever first draft often becomes expensive to modify, while code that reads plainly and isolates decisions stays cheap to revise. Design for the edits you cannot yet predict.
In practice
Keep decisions in one place so a change touches one file, not ten. Name things for what they mean, not how they work, so renaming the mechanism doesn't ripple. Favor clear seams over premature performance tricks, and leave the code slightly easier to change than you found it. When two designs perform the same, pick the one that's simpler to unwind.
When it doesn't apply
Throwaway scripts, spikes, and genuine hot paths don't need this. When you are proving a concept or squeezing a measured bottleneck, optimize for the thing that actually matters and accept the rigidity.