Impressions on the Book “Tidy First? A Personal Exercise in Empirical Software Design” by Kent Beck

Source: Dev.to

Introduction

First and foremost, it is good to see a well‑known figure and book writer in our field writing a new book about something not everybody strives for every day – code quality. It arrives many years after other seminal works such as Refactoring by Fowler (1st edition, 1999) and Clean Code by Robert Martin (2008). So, even though the book does not open a completely new area, it still shows practitioners the motivation to look at code quality in the small with a magnifying glass, as we (at CQSE) do.

I divided this article into two parts based on the two most interesting dimensions I found in the book.

• Part I – key points that relate directly to what we (at CQSE) praise daily: small moves that make developers’ lives easier.
• Part II – the temporal and economic spin Kent provides. The “First?” part of the title Tidy First? gives a hint of what it entails – What is the right time to tidy up the code? Tidy first? Before you make behavior‑change modifications? Right after? Later? Or never?

Part I – The Foundation: Small Moves that Make Developers’ Lives Easier

What is “tidying”?

If you are wondering whether “tidying” differs from “refactoring”, let’s clarify it. The book defines tidying as a small, tiny refactoring. While refactoring is defined as changes to structure that don’t modify behavior, tidyings are:

“the cute, fuzzy, little refactorings that nobody could possibly hate on.”

Kent also observes:

“‘Refactoring’ took fatal damage when folks started using it to refer to long pauses in feature development. They even eliminated the ‘don’t change behavior’ clause, so refactoring could easily break the system.”

Indeed, I have heard people refer to refactoring in many different ways, matching Kent’s observation. So, whether it sticks or not, here we are with another terminology – Tidying.

Tidyings presented in the book

Kent doesn’t go deep in exploring them; some entries take only half a page, which is fine, since they’re not new.

• Guard Clauses
• Dead Code
• Move Declaration and Initialization Together
• Explaining Variables
• Explaining Constants
• Explicit Parameters
• Chunk Statements
• Extract Helper
• One Pile
• Explaining Comments
• Delete Redundant Comments

Even though they are not new, there are good reasons why Kent devoted a section to them:

1. It makes the book self‑contained.
2. It concretely illustrates what the author means by tidyings being “cute, fuzzy, little refactorings,” rather than merely citing Fowler’s or Martin’s work.

The Duo: Coupling‑and‑Cohesion

Coupling‑and‑Cohesion is Key

Kent refers to Ed Yourdon and Larry Constantine’s work multiple times. Yourdon & Constantine laid the foundation for this notion of coupling and cohesion in software design back in the 1970s.

Cohesion and Coupling are really how your brain deals with complicated systems.

Cohesion Order (and Whether to Decouple)

• It is about avoiding changes in widely dispersed spots in the code.
• Reorder the code elements you need to change so they become adjacent (not only in the same source file but across different files and folders).

Why not just eliminate the coupling that leads to those dispersed changes?

If you know how to do it, and you can do it, go for it!

But note the cost relationship:

cost(decoupling) + cost(change)  // Constantine’s Equivalence
// cost(software) ≈ cost(change)

cost(change) follows a power‑law distribution: a few very high‑cost changes dominate the total cost. In other words:

“The most expensive behavior changes, together, cost far more than all the least expensive behavior changes put together.”

Formally:

cost(change) ≈ cost(big changes)

What makes those big changes so expensive? Typically, they are not isolated in a single cohesive element; they propagate across many highly coupled spots. This brings us back to the core insight:

High coupling → high change cost.

cost(software) ≈ cost(change) ≈ cost(big changes) ≈ coupling

Or simply:

cost(software) ≈ coupling

However, decoupling has its own cost, too (and, of course, there will always be some degree of coupling in any software). What are the trade‑offs? It all comes down to the second dimension of the book that addresses what the right timing for tidying (or decoupling) is, or whether it should be done at all.

In short, it depends on whether it’s worth paying the cost of coupling now if there’s a chance of making a profit out of it soon, or whether it’s worth paying the cost of decoupling now while reaping the benefits of doing it later (even if those benefits arrive later).

Let’s expand on all that in Part II.