functional-programming-strategicallylisted

# Programming Strategically ## Overview Working code is not enough. The primary output of a change is not the behaviour it adds but the structure it leaves behind, because that structure determines the cost of every change after it. Tactical programming optimises for finishing this task. Strategic programming optimises for the system a year from now, and pays for it with a small, continuous investment: roughly ten to twenty per cent extra effort on every change, spent on design, not on ceremony. ## When to use - Deciding whether to add a special case or restructure - Under deadline pressure, about to take a shortcut - Editing code somebody else designed - A codebase that everyone agrees is getting worse - Reviewing a change that works but reads badly Not for: throwaway spikes whose output is an answer, not code. ## Core rules 1. Default. **Ask what the change leaves behind.** Before writing, name the design the code will have afterwards. If the answer is "the same, plus one more special case", stop and look for a better shape. 2. Default. **Invest continuously, never in a lump.** Ten per cent on every change beats a rewrite later. There is no point at which a team gets time to "clean it up". 3. Default. **Design it twice.** For anything non-trivial, produce two genuinely different designs before choosing. See [design-it-twice.md](references/design-it-twice.md). 4. Default. **Leave the campsite cleaner.** Every change touching a module makes at lea