"Tidy First" by Kent Beck - Asking the Right Questions About Software Change
Reading time: ~ 3 minutes
The Question Behind the Book
Tidy First? By Kent Beck is a book of questions. It even starts with a question – literally, it’s in the title of the book!
The core question: What if software change didn’t have to be hard?
Let’s break that down. Of course, change is always challenging. The bigger the change, the bigger the challenge, right?
Tidy First? asks us to think small instead of large. What if the key to big software changes was a series of small, easy changes?
We’ve probably all made “tidyings” without realizing it: renaming methods, organizing files for readability, or moving methods between classes. Beck takes these everyday habits and turns them into a deliberate practice.
What Are Tidyings?
Beck’s book is full of practical examples: writing simple wrappers for complex code, turning multiply-branching conditionals into guard clauses, deleting unused code, and moving variable declarations and initializations together.
My favorites are the simple ones: renaming variables, changing file reading order, or moving related functions together. These are changes that no one should bat an eye at in a pull request, but they dramatically improve code understanding.
As Beck says:
Since change is the dominant cost of software development and understanding code is the dominant cost of change, communicating the structure and intent of working code is one of the most valuable skills you can exercise. Comments are a form of communication, but tidying lets you explore the limits of communicating through the other elements of programming.”
The Bigger Question: When to Tidy?
Software’s value exists in a world where time is money. How do we improve software while continuing to add value and protect our bottom line?
Sometimes tidying is a no-brainer, like moving a single function or renaming a variable. But what if we want to do a series of tidyings? How do tidyings fit into a full software development process, from implementation to PR review to production deployment?
Beck doesn’t offer easy answers here, but he does give us tools that encourage us to think about what the answers might look like. He identifies competing costs between individual tidyings vs. batch tidyings. The more tidyings per batch, the bigger the risk of conflicts, errors, or scope creep. The fewer tidyings per batch, the greater the cost of review and deployment. Each team will find a balance that works for them.
Beck is optimistic on the question of how much time should be spent on tidying: tidying should be a minutes-to-one-hour activity. Areas that need tidying tend to cluster in areas that need behavior changes. When tidying serves upcoming feature work, it naturally finds an endpoint.
The Core Argument: Software’s Future Value
But why does all of this matter? Why improve software that’s already delivering value?
Here, Beck takes the genius leap of applying the financial model of options pricing to the value of software. He argues that software’s value is not only derived from the revenue it generates today but also from the optionality contained within it to adapt to changing market conditions. Software that is easier to change has more value.
Beck’s formula is basically this: Tidy first if the cost of tidying is offset by decreased behavior change costs. Otherwise, don't.
At Planet Argon, we see this constantly with legacy codebases. Rather than accept escalating change costs, strategic upgrades bring costs back down and preserve the software's ability to deliver value.
Applying These Ideas to Daily Work
So how do you answer the question “Tidy first?” for your own team? Taking into account your team’s environment and processes, the answer should be, “When it will sufficiently offset the cost of future behavior changes.”
Some practical, low-cost ways to start:
- Encourage micro-tidying (minutes to hours) before feature work.
- Analyze bigger changes through the lens: “Will the cost of this be offset by the decrease in cost of future work?”
- Trust developer instincts: tidying often comes naturally and just needs encouragement.
Final Thoughts
This book changed how I think about software value. As a developer, I used to be reflexively pro-refactoring. If my experience working on a codebase was difficult, it was often so easy to see ways that things could be better. Beck helped me understand the other side: *change is only worth it if its cost is offset by reduced future costs. *
This is why he calls it "tidying," not "refactoring." It’s much easier to engage in tidying when it’s a minutes-to-hours activity.
Who Should Read This Book?
Beck’s experience and the helpful thinking he has done would be beneficial to:
- Developers working with legacy systems
- Teams debating when to refactor
- Engineering managers balancing deadlines with quality
“Tidy First? doesn’t give all the answers, but it helps you ask the right questions before making changes that shape your software’s future.