Tidy first? Software design by Kent Beck
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.
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 in the end of this blog post there is a section dedicated to related content on this matter.
- It goes back to my personal 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:
- 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
- tyding is like a chess game
- batch sizes
- do not mix behaviour with structural change
- dilemma: too few? too many?
- 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
- 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
- reasonably applies
- some might think it is 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 work 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.
- If waiting to tidy at a later date substantially increases the cost of tidying, consider doing it now.
- it depends
- how hard is it to change?
- how immediate is the benefit?
- how sure are you about tyding?
Part III. Theory
“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
- “software design is an exercise in human relationships”
beneficially relating elements
- elements have boundaries
- elements contains sub elements
- philosophycal book about software design
- real world, eats, shades and fertilizes
- software, invokes, publishes, listens
- 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
- what it does today
- what will do in the future
- 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
- value in a software
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.
- 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
- In general, we should treat reversible decisions differently than irreversible decisions.
- relates to Migrating to microservices databases by Edson Yanaga - Migration and technical challenges
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”
- Edward Yourdon and Larry Constantine
- 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
- 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.
- Refactoring: Improving the Design of Existing Code
- Sunk Cost Fallacy
- Migrating to microservices databases by Edson Yanaga - Migration and technical challenges
Software Architecture Hour with Neal Ford: Software Design (Tidy First) with Kent Beck
- In the book, Beck citation about software structure is the same as the one made by Mark Richards and Neal Ford: Edward Yourdon ,Larry L. Constantine
- Refactoring Patterns, Practices for Daily Work
Tidy 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