# Tidy first? A personal exercise in empirical software design > The first book in a software design series Kent Beck is planning. Influenced by Larry Constantine and Edward Yourdon's Structured Design. The first book in a series is planning. Influenced by and 's . It discusses improving the programming experience by sometimes tidying first and sometimes afterward, making large changes through small, safe steps, and software design as an exercise in human relationships. ## Foreword ## Preface What this book covers: > ''Tidy First?'' describes: > > - When to tidy messy code before changing what it computes > - How to tidy messy code safely and efficiently > - How to stop tidying messy code > - Why tidying works The two sides of software design: > is a powerful tool to ease pain in the world - if it is used well. Used badly, it becomes just another instrument of oppression, and a drag on the effectiveness of software development. [Empirical software design](https://wiki.g15e.com/pages/Empirical%20software%20design.txt) ## Introduction Many people mistake prolonged design changes without feature improvements for refactoring. They also forget the condition that system behavior must not change. This gives rise to the misconception that refactoring takes a long time without adding features and often breaks the system. Over the past 20 years, I've often heard stories beginning "To refactor, I need to persuade management…" Most refactoring can simply be done. The preface to the refactoring book begins with a failed attempt to stop adding features and improve only the design. It presents "refactoring" as an alternative: techniques for gradually improving design while adding features. Some refactorings do take months or years (the subject of Chapter 12, "Big Refactorings," in the first edition), but even here the advice is to avoid struggling to convince management and instead do a little every day while adding features. "Refactor only as much as the actual work requires. You can always resume tomorrow." Anyway, these misunderstandings may have heightened the sense that a new word—tidying—was needed. ## Part I. Tidyings Part I presents 15 "tidyings," which feel like very small refactorings. If the 1997 book is a micro version of design patterns, tidyings can be seen as a micro version of refactoring. - [Guard clauses](https://wiki.g15e.com/en/pages/Guard%20clauses.txt) - [Dead code](https://wiki.g15e.com/pages/Dead%20code.txt) - [Normalize symmetries](https://wiki.g15e.com/pages/Normalize%20symmetries.txt) - [New interface, old implementation](https://wiki.g15e.com/pages/New%20interface,%20old%20implementation.txt) - [Reading order](https://wiki.g15e.com/pages/Reading%20order.txt) - [Cohesion order](https://wiki.g15e.com/pages/Cohesion%20order.txt) - [Move declaration and initialization together](https://wiki.g15e.com/pages/Move%20declaration%20and%20initialization%20together.txt) - [Explaining variables](https://wiki.g15e.com/pages/Explaining%20variables.txt) - [Explaining constants](https://wiki.g15e.com/pages/Explaining%20constants.txt) - [Explicit parameters](https://wiki.g15e.com/pages/Explicit%20parameters.txt) - [Chunk statements](https://wiki.g15e.com/pages/Chunk%20statements.txt) - [Extract helper](https://wiki.g15e.com/pages/Extract%20helper.txt) - [One pile](https://wiki.g15e.com/pages/One%20pile.txt) - [Explaining comments](https://wiki.g15e.com/pages/Explaining%20comments.txt) - [Delete redundant comments](https://wiki.g15e.com/pages/Delete%20redundant%20comments.txt) ## Part II. Managing - [Separate tidying](https://wiki.g15e.com/pages/Separate%20tidying.txt) - Chaining - Batch Sizes - Rhythm - Getting Untangled - [First, After, Later, Never](https://wiki.g15e.com/pages/First,%20After,%20Later,%20Never.txt) ## Part III. Theory Optionality, cash flow, NPV, and so on. These ideas connect to "embrace change" in , "options thinking" in [Lean Software Development](https://wiki.g15e.com/en/pages/Lean%20software%20development%20(book.txt)), and the in . - "What have we implemented so far?" matters, but so does "What possibilities are open for what we can implement next?" Even without implementation, a possibility has independent value in itself. The greater the uncertainty, the greater the value of options. - Keep as many design decisions reversible as possible, or turn irreversible designs into reversible ones. This connects to ideas such as "delay irreversible decisions as long as possible" in [Lean Software Development](https://wiki.g15e.com/en/pages/Lean%20software%20development%20(book.txt)). ### Chapter 22. Beneficially Relating Elements Reintroduces [Beneficially relating elements](https://wiki.g15e.com/en/pages/Beneficially%20relating%20elements.txt), which he presented in 2009: - What is the result of design? Elements related beneficially to one another (the design is beneficially relating elements). - What does designing mean? Relating elements beneficially to one another (designers are beneficially relating elements). ### Chapter 23. Structure and Behavior ### Chapter 24. Economics: Time Value and Optionality ### Chapter 25. A Dollar Today > A Dollar Tomorrow ### Chapter 26. Options ### Chapter 27. Options Versus Cash Flows ### Chapter 28. Reversible Structure Changes ### Chapter 29. Coupling ### Chapter 30. Constantine's Equivalence [Constantine's equivalence](https://wiki.g15e.com/pages/Constantine's%20equivalence.txt) ### Chapter 31. Coupling Versus Decoupling ### Chapter 32. Cohesion ### Chapter 33. Conclusion So when should we tidy? - Does it reduce costs, defer them, or make them less likely? - Does it increase benefits, bring them forward, or make them more likely? - Does coupling decrease and cohesion increase? - Most importantly, does it bring you calm, joy, and satisfaction? Generally, tidy first. In moderation. ## Appendix. Annotated Reading List and References ## A short review I enjoyed reading it. From a purely technical perspective, the tidyings in Part I are so small and trivial (for example, "add a blank line") that the book might seem insubstantial. In fact, their smallness and simplicity are precisely what make them valuable. While Part I could be dismissed as material suitable only for "beginners," I suspect the theories in Part III resonate only after considerable experience. In the preface, the author writes that he barely understood 's book when he first read it, only appreciating its true value many years later, and that in "Tidy First?" he wants to present his own reinterpretation of L.C.'s ideas. Perhaps that explains why Part III of this book also seems to require experience. Both in Korea and elsewhere, people seem to favor reading and sharing easily summarized content: only the pattern catalog in pattern books, only the code smell list in refactoring books, and so on. If this book is read that way, only its list of 15 small, trivial tidyings from Part I may circulate. If that happens, it could be regarded as merely "a book of 15 coding tips for absolute beginners." Anyway, this is said to be the first result of a series conceived and planned over a long time. I thoroughly enjoyed it and look forward to the next book. : Copy over [this thread](https://x.com/_a6g_/status/1720610384783015951)