$Tidy First? A Personal Exercise in Empirical Software Design

What stayed with me

The book reframes refactoring as a stream of very small, safe moves, the “tidyings”, rather than a big risky cleanup project. Things like guard clauses, extracting a helper, deleting dead code, normalizing symmetries. Each one is small enough to do in a few minutes and easy to reverse, which is what makes them low-risk.

The discipline that stuck with me most is separating structural change from behavioral change. Code that changes structure should not change behavior, and vice versa, and they should live in different commits. That separation makes review trivial and makes it obvious which change to suspect when something breaks.

The part I keep coming back to is the question mark in the title. The answer is not always yes. Whether to tidy before a change, after it, or not at all is an economic decision about coupling, cohesion, and the time value of the work. Tidying is an investment, and like any investment it can be premature.

The tidyings

The first part of the book is a catalogue of small, safe moves. Each is cheap on its own; the value is in having them as named tools you can reach for.

• Guard clauses turn nested conditionals into early returns.
• Delete dead code and let version control hold the history.
• Normalize symmetries so similar code follows one pattern.
• Wrap an awkward API in the interface you wish it had, leaving the old implementation in place.
• Put code in reading order, the sequence a reader wants to meet it in.
• Group coupled functions and files together for cohesion.
• Move a declaration down next to where it is first used.
• Pull subexpressions and magic numbers into named variables and constants.
• Pass explicit parameters instead of a single options bag.
• Break a long block into chunks, with blank lines between distinct steps.
• Extract a helper for a block that does one nameable thing.
• Gather scattered code into one pile before re-splitting it cleanly.
• Add comments that explain the non-obvious, and delete the ones that only echo the code.

Working with tidyings

The second part is about workflow. Ship tidyings in their own pull requests, away from behavior changes. Chain them in sequence when you are working toward a larger structural goal, but keep each batch small so review stays fast and no behavior sneaks in. Don’t tidy for more than about an hour before returning to the change you actually came to make. And if structure and behavior do get tangled in the same diff, pick one of three exits: ship it as-is, split it into separate PRs, or start over.

When to tidy: first, after, later, never

Whether to tidy is a question of timing and economics, not virtue. Tidy first when it immediately makes the coming change easier to understand or cheaper to make. Tidy after when doing it later would cost more and finishing now gives you closure. Save it for later when the payoff is real but not urgent. And never tidy code that will not change again, or where the cleanup would teach you nothing.

Notes I wanted to keep

• Reading cost exceeds writing cost, so optimize for the reader; code is read far more than it is written.
• Separate structural changes from behavioral changes, in version control as well as in your head.
• Small, frequent tidying beats large batches. It keeps reviews trivial and behavior changes honest.
• Software creates two kinds of value: the behavior you ship today, and the optionality good structure buys for tomorrow.
• Present value beats future value, which argues for tidying after a feature. Uncertainty favors options, which argues for structure first. Holding both at once is most of what the book is about.
• Coupling is what makes change expensive; cohesion is what makes it cheap.