Primary source
book_cube series on Tidy First?
Five posts: introduction, tidyings, change management, and theory (coupling/cohesion, economics).
Tidy First?: A Personal Exercise in Empirical Software Design
Authors: Kent Beck
Publisher: O'Reilly Media, 2023
Length: ~170 pages
Kent Beck's book on small structural changes: tidyings, separate tidying, and design economics through coupling, cohesion and optionality.
What the book is about and why “tidying”
Kent Beck separates structural edits from behavior edits: first make the code easier for the next change, then change functionality. He uses tidying as a precise subset of refactoring.
The core idea is pragmatic design: not abstract theory, but a practical way to reduce risk and stress when shipping constant changes.
The original edition is available on O'Reilly Learning. Russian translation (Piter): book page.
System behavior
What the product does for users today. Effects are visible immediately, but changes become expensive if structure is weak.
System structure
How cheap and safe tomorrow’s changes will be. Benefits are delayed, but they define long-term team velocity.
Part I: Tidyings
The first part is a toolkit of low-cost moves that significantly improve clarity and reduce friction for subsequent feature work.
Readability
- Guard clauses and early returns
- Explaining variables and constants
- Reading order and visual statement chunking
Structure
- New interface, old implementation
- Move declaration + initialization together
- Extract helper and cohesion order
Hygiene
- Delete dead code
- Normalize symmetries across the codebase
- Delete redundant comments
Part II: Managing
The second part is about process: when to tidy, how not to mix it with feature work, and how to size changes for team flow.
- Keep tidying separate from behavior changes (ideally in a dedicated MR).
- Plan cleanup chains, but stop before over-engineering.
- Choose batch size by balancing review cost and merge-conflict risk.
- Maintain a rhythm: frequent small cleanup beats occasional big cleanup.
- If a change gets tangled, rollback and rebuild in the right order.
Part III: Theory
Structure vs Behavior
Behavior creates value now, while structure defines the cost and speed of future changes.
Time Value + Optionality
Earlier cash flow is better, but design buys options for future behavior changes.
Coupling and Cohesion
High coupling makes large changes expensive, while strong cohesion reduces the touched surface area.
Reversible vs Irreversible
Structure changes are often reversible; behavior-side effects in production often are not.
One memorable idea is close to “Constantine’s equivalence”:cost(software) ~ coupling. Higher coupling usually means more expensive large-scale change.
Practical adoption pattern
Before feature work
Do 1-2 tidyings that remove obvious pain exactly where the next change is planned.
During feature work
Keep focus on behavior and avoid expanding refactoring without an explicit economic reason.
After release
Close the remaining structural debt with a small tidy MR while the context is still fresh.
Related chapters
- What is software architecture and why is it in System Design? - provides the system-level context where the tidy approach works as a tool for controlling the architecture cost of change.
- Clean Architecture (short summary) - shows how structural principles and module boundaries reduce coupling and make code evolution safer.
- A Philosophy of Software Design (short summary) - extends the complexity-control perspective through deep modules and information hiding that complement tidy-first thinking.
- Building Evolutionary Architectures (short summary) - adds the architecture-evolution layer and fitness functions where small safe changes become an operational strategy.
- Continuous Architecture in Practice (short summary) - connects tidy-first to continuous delivery decisions and incremental architecture in production.