Notes on Tidy First?

Tidy First? by Kent Beck captures the spirit of Ousterhout’s A Philosophy of Software Design while also recognizing the inherent tensions of developing software within a team and business. You can also read it in about two hours. Recommended!

A Philosophy of Software Design by John Ousterhout is one of my favorite books on software design. When I heard that Kent Beck had a new book out, Tidy First?, that was deliberately engaging with similar content but a markedly different pedagogy, I knew I had to read it. (It also helped when I realized it’s around one hundred pages and you can read it in a couple hours.)

[Tidy First?* starts with an explanation of Guard Clauses, arguing that instead of:

if (condition):
  if (not other condition):
      ...some code...

You are better off writing:

if (not condition) return
if (other condition):
    ...some code...

Building from there, Beck builds out an approach to software where you think deliberately about separating and sequencing changes that “tidy” (modify structure) as opposed to changes that modify application logic.

Here’s my best attempt to summarize the book into bullet points:

• There isn’t a single way to do things, there are things that make sense in context, and you know your context
• There are many distinct ways to tidy code, which make code easier to work with: guard clauses, removing dead code, normalizing symmetries, and so on
• Tidying and logic changes are different types of work, and should be done in distinct pull requests
• This speeds up pull request review,and on high-cohesion teams tidying commits shouldn’t require code review at all
• Tidying should be done in small amounts, not large amounts
• Tidying is usually best to do before changing application logic, to the extent that it reduces the cost of making the logical change
• It’s also OK to tidy after your change, later when you have time, or even never (for code that doesn’t change much)
• Coupling is really bad for maintainable code

I really enjoyed this book, and reading it I flipped between three predominant thoughts:

1. I’ve never seen a team that works this way–do any teams work this way?
2. Most of the ways I’ve seen teams work fall into the “never tidy” camp, which is sort of an implicit belief that software can’t get much better except by replacing it entirely. Which is a bit depressing, if you really think about it
3. Wouldn’t it be inspiring to live in a world where your team believes that software can actually improve without replacing it entirely?

Any book that can force you to reconsider a somewhat strongly held belief, particularly after spending a fair amount of time in industry, is doing something right, and Tidy First? is certainly in that category.

Curious to see how many teams end up adopting this approach, and what makes teams likely or unlikely to adopt it. Is this an approach that mostly works for small teams in code that is already modular? In small monoliths? In large monorepos? We’ll see what the industry takes from it over the next few years.