The first book in a software design series Kent Beck is planning. Influenced by Larry Constantine and Edward Yourdon’s Structured Design.

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:

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

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 Smalltalk Best Practice Patterns is a micro version of design patterns, tidyings can be seen as a micro version of refactoring.

Part II. Managing

Separate tidying
Chaining
Batch Sizes
Rhythm
Getting Untangled
First, After, Later, Never

Part III. Theory

Optionality, cash flow, NPV, and so on. These ideas connect to “embrace change” in Extreme programming explained, “options thinking” in Lean Software Development, and the Incremental funding method in Software by numbers.

“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.

Chapter 22. Beneficially Relating Elements

Reintroduces Beneficially relating elements, 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

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 Larry Constantine’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.

ToDo: Copy over this thread