Tidy first? Software design by Kent Beck

Last updated Jan 9, 2025 Published Oct 18, 2023

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Kent Beck’s “Tidy First?” examines software design through the lens of programmer behavior and decision-making. Beck advocates for programmers by addressing the practical challenges of maintaining codebases while delivering features.

The book bridges software design and programming practice. While some practitioners view these as separate disciplines, Beck presents them as interconnected activities that shape daily development work.

The book begins with “tidyings,” which are focused refactoring operations targeting specific areas of code. Rather than presenting extensive code examples, Beck emphasizes understanding the conceptual framework behind each tidying operation.

The second section addresses the management of tidyings in professional contexts. Beck provides concrete guidance on initiating and sustaining tidying practices within existing development workflows. Programmers often accumulate technical debt while implementing features, losing track of structural improvements. This section offers strategies to maintain focus on code structure without disrupting feature delivery.

The final section explores the economic and theoretical foundations of software design decisions. Beck defines software design in economic terms, explaining how structure changes affect development costs and future flexibility. This progression from definition to economic analysis provides a framework for evaluating when and how to tidy code.

Content

This section examines each part and chapter of the book, capturing Beck’s core concepts and connecting them to related research and practice. A dedicated section at the end provides references to complementary material.

Introduction

  • It goes back to my mission statement: help geeks feel safe in the world
  • When I read other descriptions of software design I missed the critical elements of “how much?” and “when?”
  • Software design has always offered me an intellectual puzzle.
  • I want to make a little coin with this but I intend to offer far more value than I charge.

Part I. Tidyings

Beck presents tidying examples that serve as the foundation for later sections. The tidyings are categorized below based on their primary purpose:

Beck’s learning strategy moves from concrete examples to abstract concepts. Tidyings form a subset of refactorings.

  • The “rule” about having a single return for a routine came from the days of FORTRAN
Tidy Category Description from the book
dead code clean up Delete small amounts of code in each tidying diff
delete redundant comment clean up Remove comments that merely restate what the code does
Normalize Symmetries understanding Create pass-through interfaces to simplify implementation
Reading order understanding Reorder code in the sequence a reader would prefer to encounter it
Cohesion order understanding Group coupled elements together (decoupling can be complex and may come later)
move declaration and initialisation together understanding Minimize the gap between variable declaration and initialization
explaining variables understanding Use variable names to convey intent
explaining constant understanding Replace magic numbers with named constants
explicit parameters understanding Split map parameters into individual function parameters
chunk statements understanding Insert blank lines between logical sections of code
extract helper understanding Use IDE refactoring tools to extract helper methods
one pile understanding Consolidate split code that hinders comprehension
explaining comment understanding Document non-obvious behavior

Part II. Managing

Beck announces a future book on team-based software design. He frames tidying as “geek self-care,” noting that programming environments still lack comprehensive automated refactoring support despite decades of technological advancement. Beck identifies tidyings as “gateway refactorings” that provide entry points for developers to improve code structure.

Key questions addressed:

  • When should tidying begin?
  • When should tidying stop?
  • How does code structure change over time?

Separate tidying

Beck recommends isolating tidyings in their own pull requests rather than mixing structural changes with behavioral changes. Large PRs overwhelm reviewers, while small PRs encourage feedback. Working in small increments enables faster iteration and clearer communication of intent.

Chaining

Beck compares tidying to chess, where each move sets up future possibilities. Batch sizes

Never mix behavioral changes with structural changes. The challenge lies in determining optimal batch size:

  • More tidyings lengthen integration time
  • Merge conflicts increase costs

Many organizations face substantial fixed costs for code review and deployment.

  • On teams with trust and a strong culture, tidyings don’t require review
  • rhythm
    • Part of the art of managing tidying is managing the rhythm of it
    • we are talking about minutes up to an hour. More than an hour of tidying at a time before making a behavior change likely means you’ve lost track of the minimum set of structure changes needed to enable your desired behavior change.
  • getting untangled
    • Discard your work in progress and start over, tidying first. This is more work but it leaves a coherent chain of commits.
    • Don’t fall into the sunk cost fallacy [[#Related subject]]
  • first, after, later, never
    • never
      • reasonably applies
    • later
      • some might think it is a fantasy
      • I invite you to examine this assumption that there isn’t enough time to do your work
      • have a list of things to be worked in dead hours
      • Tidying is a great way to become aware of the detailed consequences of your design. Tidying illuminates the design as it could be.
    • after
      • If waiting to tidy at a later date substantially increases the cost of tidying, consider doing it now.
    • first
      • it depends
      • how hard is it to change?
      • how immediate is the benefit?
      • how sure are you about tyding?

Part III. Theory

  • intro
    • “software design is an exercise in human relationships”
      • Understanding theory lets you disagree constructively with your fellow geeks.
    • most complicated human relationship of all: Money
  • beneficially relating elements
    • Elements
      • elements have boundaries
      • elements contains sub-elements
      • philosophical book about software design
    • Relating
      • real world, eats, shades and fertilizes
      • software, invokes, publishes, listens
    • Beneficially
      • assembly language, too many relationships often implicit between elements
    • the design is the elements, their relationship and benefits derived from those
    • designers beneficially relates elements
    • talking about structure of the system
      • element hierarchy
      • relationship between elements
      • the benefits
      • structure != behaviour
  • structure and behaviour
    • software
      • what it does today
      • what will do in the future
      • behaviour
        • inputs/outputs
        • invariantes
        • creates value
      • things are always changing
      • more volitile the environment more options become valuable
        • value in a software
          • a key employee quits
          • distance from the customer
          • cost of change sky rockets
          • we can keep the kitchen clean while we cook
        • the structure of the system doesn’t matter to its behaviour
        • One big function, a whole bunch of itty bitties, same paycheck comes out
  • time value and optionality
    • What makes sense for us to do as programmers may go contrary to the nature of money. When geeky imperatives clash with money imperatives, money wins. Eventually.
    • Software design has to reconcile the imperatives of “earn sooner/spend later” and “create options not things”.
  • a dollar today > a dollar tomorrow
    • How do we value a software system? Say you have a software system and I want to buy it. How much should I reasonably pay you?
    • In the scope of this book, the time value of money encourages tidy after over tidy first. If we can implement a behavior changes that makes us money now and tidy after, we make money sooner and spend money later.
  • options
    • source of value: optionality
    • What does this mean for software design? Software design is preparation for change, change of behaviour.
  • options vs cash flow
  • reversible structure changes
  • coupling
    • Edward Yourdon and Larry Constantine
      • all had one property in common–changing one element required changing other elements
    • For an experiment, see which pairs of files tend to show up together in commits. Those files are coupled.)
    • Coupling drives the cost of software
    • Meilir Page-Jones used the word “connascence” to describe coupling in his book “What Every Programmer Should Know About Object-Oriented Design”
  • Constantine’s Equivalence
    • they postulated that the goal of software design is to minimize the cost of software
    • The sooner we get feedback from real usage, the less time/money/opportunity we spend on behavior that doesn’t matter.
    • To reduce the cost of software, we must reduce coupling.
  • coupling versus decoupling
  • cohesion
    • Make no sudden moves. You’re working with incomplete and changing information about what’s coupled with what. Don’t dramatically re-arrange everything. Move one element at a time. Make the code tidier for the next person. If everyone follows the Scout Rule (“leave it better than you found it’’), the code will become more livable over time.

Goodreads review

Tidy First?: A Personal Exercise in Empirical Software DesignTidy First?: A Personal Exercise in Empirical Software Design by Kent Beck
My rating: 4 of 5 stars

This books has a lot to say not only on software design, but also on programmer behaviors. As expected Kent Beck advocates for programmers and in this piece he tries as much as possible to close this relationship with all of us.

Luckily enough with lots of insights he won the battle between software design and programming. Some would say that there is no different some will agree with that.

The book starts with the tydings which are a decent of refactoring but with a focused area and not that much of showing concrete code, the key is to understand the concept.

In the second part Beck goes towards a more professional point of view talking about managing the tydings, the chapters in this section provides tips on how to go to start, and keep tyding the code base. Many of us (programmers) usually get lots of changes and forget about the focus of why we are tyding things, this part is to help programmers to avoid this situation.

The last part of the book is the economical part and the theory behind tydings. The approach followed and the analogies goes from defining what design in the context of software is and moving on to the economical part and why it is important.

View all my reviews

You also might like

Made with đź’– by @MatheusMarabesi