Kent Beck published a new book a few weeks ago. It is called Tidy First? and it is tiny. You can read it in two evenings. I did, and then I read it again, slower, because under the small size there is a big idea. Maybe the most useful idea about refactoring I have seen in years.
The big idea is this. Code cleanup is not a moral duty. It is an investment decision. And like every investment decision, sometimes the answer is yes, sometimes the answer is later, and sometimes the answer is no.
The question mark matters
Notice the book has a question mark in its name. Tidy First? Not Tidy First! Kent Beck, the man who gave us Extreme Programming and test driven development, is not commanding us to clean code. He is asking a question and teaching us how to answer it case by case.
This is refreshing. Our industry talks about clean code like religion. You must refactor. You must keep the boy scout rule. Leaving messy code is sin. I have said versions of this myself over the years. But religion does not pay salaries. Businesses pay salaries, and businesses think in cost, risk and return. Beck’s book finally speaks that language about code cleanup.
What a tidying is
A tidying is a refactoring so small it is almost embarrassing. Renaming a variable so it says what it means. Putting two related lines next to each other. Extracting a small helper. Replacing a magic number with a constant. Adding a guard clause so the reader does not hold five conditions in their head. Deleting dead code.
Each one takes minutes. Each one is so small that the risk of breaking something is close to zero. And that low risk is exactly the point. Big refactorings are big bets. They take weeks, they conflict with everybody’s branches, and sometimes they fail halfway and leave the code worse. I have a scar or two from those. Tidyings are the opposite kind of bet. Tiny stake, quick payoff, almost no way to lose.
The question in the book’s title is about timing. You are about to change some messy code. Do you tidy first, so the change becomes easy? Tidy after, so the next person finds it better? Tidy later, written in a list? Or never, because this code will die or is never touched again? Beck walks through real reasoning for each. “Never” being a legitimate answer is what makes the book honest.
The economics chapter is the real gift
The second half of the book is where it gets deep. Beck connects software design to two ideas from finance.
First, the time value of money. A dollar today is worth more than a dollar next year. Translated to software, shipping something valuable now beats shipping something perfect later. This argues against big cleanup projects that delay features. The cost of tidying is paid today, the benefit comes later, so the benefit must be clearly worth it.
Second, optionality. This one changed how I explain my work to managers. Well structured code is valuable not only because it is pleasant. It is valuable because it keeps options open. When the business says “can we change direction?”, clean structure answers “yes, cheaply” and tangled structure answers “yes, six months and three resignations.” Nobody knows what the market wants next year. Code that can change cheaply is like holding options on the future. In an uncertain market, options have real money value.
So messy code is not ugly, it is expensive. And tidy code is not pretty, it is optionality. Once I started using these words with non technical people, the conversations got much easier. “This week of cleanup keeps our options open for the pricing changes the business is discussing” lands much better than “the code hurts my eyes.”
How it changed my week, literally
Since reading it I changed one small habit. Before touching a confusing piece of code, I spend fifteen or twenty minutes tidying it first, in a separate small pull request. Then the real change goes in a second pull request, and it is suddenly small and easy to review.
My teammates noticed before I explained anything. Reviews of tidying PRs take two minutes, because nothing behaves differently. Reviews of the real change take less time too, because the code around it now makes sense. Less review time, fewer bugs slipping through, less frustration. Team health is also an economic asset, it just does not show up in any dashboard.
The other change is what I stopped doing. I stopped feeling guilty about code I chose not to clean. If a module is ugly but stable and nobody touches it, tidying it is an investment with no return. Beck gave me permission to walk past it, and that permission is worth the price of the book alone.
Should you read it
Yes, and I rarely say that so directly. It costs less than a team lunch and takes a weekend. If you are a developer, it gives you better timing instincts and better words for negotiating cleanup work. If you lead a team, it gives you a sane middle ground between “no time for refactoring” and “let us rewrite everything.”
Beck wrote much of the book in public before it came out, refining the ideas piece by piece. The book is the first of a planned series, and this one covers the part each of us controls alone, our own next change.
Software design is an exercise in human relationships, Beck says, and money is part of how organizations relate. A small book, a question mark, and suddenly cleanup has a business case. That is a good trade for two evenings of reading, even cold December evenings like the ones we have here.
Pax et bonum.