10 Key Takeaways From A Software Design Book That Took 18 Years To Write
A curated takeaways From Tidy First? by Kent That Took Him 18 Years To Write
A French mathematician and philosopher once said:
If I had more time, I would have written a short letter
The book Tidy First? by Kent Beck is an example of it. It took him 18 years to write a 100-page book. Even though the book is short, it is packed with thoughtful and practical tips on improving software design on a small scale.
Kent Beck is a thought leader in the software industry. He was one of the signatories of the Agile Manifesto, which established the foundation for agile software development practices. Kent is also known for developing Extreme Programming (XP), co-creating JUnit and rediscovering Test-Driven Development.
The story behind the book
The book was released in 2023 but the journey began when Kent Beck met programming legends Larry Constantine and Ed Yourdon in 2005 — at the 30th anniversary of the classic book Structured Design. Some of the examples in the old book were outdated but the design principles were spot on. So, Kent vowed to write an updated version of the book.
The content of the book was taking its shape in 2012, as seen in Kent’s tweet which is relevant to the main idea of the book.
Key Terminologies in the book
🧹 Tidying
Small refactoring actions in daily dev practice that improve codebase structure for easier future features.
🏗️ Structural changes
Changes to code organization (tidying/refactoring) like guard clauses or variable renaming.
⚙️ Behavioural changes
Changes affecting software functionality like new features, bug fixes, or feature removal.
10 key takeaways from Tidy First?
After spending 20+ hours reading the book twice and taking notes, I've distilled its core messages into 10 key takeaways:
1. Take tiny steps in tidying
Kent suggests taking smaller steps during tidying. It’s because such small-scale design improvements are less risky and don’t introduce any critical bugs. Most importantly, it’s easier to revert the tiny change if anything goes wrong.
I’ve often noticed that when I allocate a week for refactoring, it introduces obscure bugs 90% of the time. Therefore, it’s crucial to refactor in smaller steps with a goal to continually merge into the default branch.
Large-scale refactorings are inevitable sometimes — mostly due to the accumulation of tech debt over decades or migration to the latest version (for example, from jQuery to TypeScript). But, they should be carefully planned and done in phases.
2. Tidying compounds over time
Tidying compounds like financial investments. Investing $50 weekly with a 10% return yields $4,460 profit in 5 years. Similarly, small code improvements accumulate significant benefits. The two most visible benefits are making it easier to add new features and tidy further.
For example, when you extract a generic code into helper, it can be reused in future when adding a new feature, thus reducing the dev time. Similarly, removing dead code makes it easier to improve the cohesion or reading order of the code.
3. Separate tidying from behavioural change
Kent suggests that tidying should go into their own PRs with as little tidying per PR as possible. The reason is that mixing structural and behavioural changes makes the PR huge and makes the reviewer’s job difficult. It also makes reverting a git commit difficult when you mix these two changes.
I think it’s not a good practice to mix any two or more types of changes, not only tidying and behavioural changes. It reduces clarity and increases difficulty in tracking down bugs.
A golden rule I follow is that when I can’t write a simple, single-sentence commit message, it’s a sign that I’m mixing different types of changes.
4. Keep software design simple and approachable
The first part of the book provides tiny refactoring tips that are too simple to ignore. I think the reason Kent Beck did it is so that developers can easily integrate those tips into their daily workflow. Whenever things are simple and approachable in small steps, we often tend to work on them otherwise completely procrastinate.
Don’t make software design a big deal that you may not do it
I often find the codebase messy when I’ve worked with a team that assumes that refactoring should only be done in a separate sprint. Of course, refactoring needs its own sprint when tidying hasn’t been done for several months or years.
5. Tidying cost rises as batch grows
Kent points out that the cost of tidying rises as the size of the tidying batch grows.
The rise in cost includes:
Collisions - Tidying can collide with other teammates’ work and create merge conflicts. Fixing merge conflicts increases the cost of tidying.
Interactions - More tidying in a batch increases the chances of introducing behaviour changes.
Speculation - When we try to do too much tidying at once, we risk making unnecessary changes. These extra changes create additional overhead and risks without proportional benefits.
As tidying costs rise with an increase in batch size, Kent promotes tidying in smaller batches to reduce the cost of tidying. Tidying in smaller batches also helps developers to balance refactoring with delivering new features.
6. Tidying PR don’t require a review
The cost of tidying sometimes feels like a double-edged sword. When you increase the tidying per batch, the tidying cost rises. But when you shrink the batch size to reduce the cost of tidying, the review cost rises. The review cost rises because it takes more time to get a smaller PR reviewed and deployed to production than a large PR.
Therefore, Kent suggests to eliminate tidying-related code reviews to reduce the cost of reviews. But the teams should have a strong culture and trust in each other for it to work.
I believe that if every team member practices tidying daily, then they become better at tidying. As a result, there is a lesser chance of tidying accidentally introducing bugs, thus making code review redundant.
But, it requires a lot of practice, at least for a few months, before tidying changes can be safely deployed into production without code reviews.
7. Tidying should not take more than an hour
The timing of tidying is important otherwise it’s easy to fall into the trap of tidying for hours without any visible benefits. As tidyings are tiny structural changes that support the next behaviour change, Kent suggests tidying from a few minutes to an hour before making a behavioural change.
Kent says that it can take more than an hour to tidy, if:
You’ve lost track of the minimal structural changes needed to make behavioural change
The codebase is messy and you can profitably tidy for hours
If it’s the second case, then it won’t happen for long as tidying improves software design over time.
8. Tidyings create optionality
Tidyings make it cheaper to extend the behaviour of the software in future as Kent suggests. I never thought that way but reading the book made me realise how structural change adds value to software.
The reason we don’t prioritise refactoring of any kind is that we (or businesses) don’t see any value in it. It’s easy to see how adding a new CTA increased the conversion rate by 20%. But, businesses don’t see how extracting a repeating logic into a helper can save you 20 minutes next time.
Kent says that you don’t need to add behaviour to the software to make it more valuable. As soon as you make it easier to what the software can do next, you’ve already made the money.
9. Tidy first if it pays off immediately
The question mark in the title of the book Tidy First? sparks a curiosity gap on when should you tidy first. If you have been waiting for the answer, here’s your juice.
According to Kent, tidy first if:
Cost (tidying) + Cost (behaviour change after tidying) < Cost (behaviour change without tidying) - If it takes you less time to tidy first and add the feature than add the feature only, then tidy first.
It improves the readability of the code immediately
You know exactly how and what to tidy
Besides tidying first, you can also tidy later, after or never based on different circumstances. But in general, Kent suggests biasing towards tidying first.
10. The cost of software is approximately equal to the cost of coupling
Coupling refers to how much different parts of code depend on or need to know about each other. When a system is highly coupled, a simple change requires changing many modules. For example, a change in the global variable name requires a change in everywhere it’s used.
Ed and Larry showed in Structured Design that coupling directly impacts software costs. In Tidy First?, Kent Beck proved mathematically that the cost of software is equivalent to the cost of coupling (which he also calls Constantine’s Equivalence).
Therefore, Kent suggests that we must reduce coupling to reduce the cost of software.
Final thought
While these takeaways capture the core messages, the book offers deeper insights through practical examples and thoughtful explanations. Therefore, I highly recommend the book to software engineers looking to improve code quality and team productivity.