Tidy first? Software design by Kent Beck

Published Oct 18, 2023

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

This book offers valuable insights not only into software design but also into programmer behaviors. As expected, Kent Beck advocates for programmers, striving to establish a close connection with all of us.

Thankfully, armed with numerous insights, he successfully navigates the intersection of software design and programming. Some may argue there’s no distinction, while others will find agreement.

The book commences by delving into “tydings,” a form of refactoring focused on a specific area, with less emphasis on presenting concrete code. The key here is to grasp the underlying concept.

In the second section, Beck takes a more professional approach, discussing how to effectively manage these “tydings.” The chapters in this segment offer valuable tips on getting started and maintaining a tidy codebase. Many of us, especially programmers, often find ourselves inundated with changes and may lose sight of the original purpose behind tidying things up. This section aims to assist programmers in avoiding this predicament.

The final part of the book explores the economic aspect and the theoretical foundation of “tydings.” The approach taken and the analogies drawn begin by defining what design means in the context of software, then progress to the economic facet, elucidating its importance.

Content

In this section I am going over each part and chapter of the book capturing what the author first wrote and mixing what I find interesting about what I already know about the subject. Note that at the end of this blog post, there is a section dedicated to related content on this matter.

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

In this part of the book Kent focused on examples of tydings that he later uses as a base for the other pars of the book, what I am trying to do here is to put in a box the different tydings and their category:

  • tydings
    • My general learning strategy is to go from concrete to abstract
    • Tidyings are a subset of refactorings.
    • The “rule” about having a single return for a routine came from the days of FORTRAN
Tydy Category Description from the book
dead code clean up As always, delete a little code in each tidying diff
delete redundant comment clean up when the comment says exactly what the code does remove it
Normalize Symmetries understanding create a pass-through interface - design helpers to make the coding easier
Reading order understanding reorder de code in an order that a reader would like to encounter it
Cohesion order understanding first make the things together - if they are coupled put them together - decoupling can be an intellectual stretch
move declaration and initialisation together understanding be a mystery writer
explaining variables understanding use variable names to explain the intention
explaining constant understanding do not use literals in code
explicit parameters understanding whenever receiving a map, split it in the function body
chunk statements understanding put a blank line between two parts of a chunk of code
extract helper understanding execute this refactoring within an IDE
one pile understanding sometimes code was split in a way that hinders understanding, pile to code together to improve understandability
explaining comment understanding write down what is not obvious from the code

Part II. Managing

  • next book will share why teams perform software design together
  • Tidying is geek self-care
  • Programming environments inexplicably lack automated support for refactoring even now decades after it became feasible
  • Tidyings are gateway refactorings
  • when you start tidying?
  • stopt tidying?

  • changing code structure

  • separate tidying
    • pull request for now
    • tidyings go in their own PRs, do not mix with other changes
    • we start with a mass of changes
    • big prs are too much for reviewers
    • tiny prs invite feedback
    • working in small steps are the key
  • chaining
    • tyding is like a chess game
  • batch sizes
    • do not mix behaviour with structural change
    • dilemma: too few? too many?
    • collision
      • more tydings longer to integrating
      • merge conflicts rise the cost
    • In many organisations, the fixed cost of getting a single change through review and deployment is substantial.
    • 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

Made with 💖 by @MatheusMarabesi