Tidy First? by Kent Beck — Hits And Misses

I recently finished reading Tidy First? by Kent Beck, a short, thoughtful book that champions the habit of cleaning code as a deliberate act. It’s classic Beck: calm, wise, and full of understated brilliance. But for all its strengths, it also left me wanting more, especially when it comes to the real dragons of software design.

The Good Stuff

1. Conceptual Clarity: Beck elevates everyday code cleanups into conscious decisions. You don’t just refactor, you tidy with purpose.
2. Psychological Insight: His discussion on thinking footprints, how we clean as we understand is spot on. Tidying helps reduce the cognitive load and builds confidence for the change ahead.
3. Tiny, Cheap, Reversible: The mantra of making safe, micro-improvements is empowering. It makes change less scary and more habitual.
4. Empathy-Driven Writing: Beck doesn’t talk down to the reader. He embraces uncertainty and trade-offs, a rare quality in programming books.

But Here’s Where It Falls Short

1. It Sidesteps the Big Design Decisions

While the book does a fantastic job zooming in on micro-decisions, it doesn’t quite zoom out. It rarely addresses the strategic decisions that shape a system’s architecture, layering, boundaries, protocols, dependencies. These are the ones where a wrong turn can haunt a team for years.

• How do we decide where a feature belongs?
• When do we extract a service vs keep things together?
• How do we split a module when everything depends on everything else?

Tidying won’t save you here. You don’t rename a variable your way out of a broken layering decision or a prematurely extracted service.

2. Tidying Can Distract from Structural Problems

In some cases, tidying can be the wrong tool. It polishes the visible surface while deeper design faults remain untouched. You can keep tidying inside a poorly placed class, but the real problem is that the class shouldn’t exist.

You can refactor a method to be cleaner — but the interface it implements is fundamentally leaky or incoherent.

You can align formatting and rename everything — and still have tight coupling, unnecessary indirection, or architectural bloat.

The danger? Teams feel like they’re improving things, while core issues remain unresolved.

3. It Avoids Architectural & Team Dynamics

Design decisions don’t live in isolation. They live in teams — in documents, in half-said conversations, in pull request comments. Beck keeps the scope intentionally personal and small-scale. But that also means:

• No discussion of cross-team alignment
• No exploration of how to evolve a messy monolith
• No help with conflicts between tidying efforts and product deadlines

In real-world codebases, tidying has organizational cost. And when the root problem is architectural, like overengineered eventing, tangled service boundaries, or shared database coupling, you need more than rename-and-extract patterns. You need courage, strategy, and leadership.

What I Wish It Had Tackled

1. How to recognize when you’re dealing with a structural flaw, not just messy code.
2. How to prioritize tidying efforts when technical debt spans multiple dimensions.
3. How tidying interacts with conceptual compression, domain modeling, or interface design.

Final Thoughts

Tidy First? is a great entry point to building design intuition. It helps developers slow down, think clearly, and make improvements with minimal risk. But it’s not the whole story.

If you’re in a well-factored codebase with tight feedback loops, it’s exactly the kind of discipline that helps you avoid entropy. But if you’re stuck in a system with fundamental architectural issues, tidyings can feel like fluff around the edges of chaos.

Tidy first? Absolutely.

Tidy only? Not quite.