Tidy First?: A Personal Exercise in Empirical Software Design

Tidy First?: A Personal Exercise in Empirical Software Design

The biggest cost of code is the cost of reading and understanding it, not the cost of writing it

Published on Friday, September 6, 2024

In theory, there is no difference between theory and practice, while in practice there is.

Tidy First?: A Personal Exercise in Empirical Software Design is a short slim book by industry veteran Kent Beck (Agile Manifesto, Test-Driven Development, Extreme Programming) from 2023. The book is the first in the series, and the second will focus on working in teams.

The biggest cost of code is the cost of reading and understanding it, not the cost of writing it

Tidy First? is organized around three parts:

Part I. Tidyings

I thought I was getting paid for what I had done (as per the previous chapter). I wasn't. I was mostly getting paid for what I could do next.

Section Tidyings contains various advice on "miniature refactorings." If you are a long-time developer, most of these things should be an instinct by now.

I have been doing these "mini refactorings" for years. But, interestingly enough, I have not put as much thought into them as I should have. We primarily think about big things like system design, algorithms, technology, etc. It's good to sometimes slow down and think about "small things," like how our code is organized.

Part II. Managing

The fundamental difference between changes to the behavior of a system and changes to its structure

The managing section focuses on when and what (even if) we should do the tidying. Should we tidy when we change the system's behavior or independently?

I often put too many things into a single commit. Luckily, I have made many improvements and become less insufferable for devs doing code reviews.

I think I will reorganize some of my projects to be more domain-centric, not just by technology. As a .NET developer who usually practices domain-centric development and modular monolith, these will be just changes in c# virtual folders. But, even this tiny change, I believe it will be beneficial in the long run.

You are not just instructing a computer, you are explaining your intentions for the computer to other people.

Part III. Theory

Software design is a sharp tool. Some folks don't know they wield it. Some folks who wield it grab it by the blade, not the handle.

The last section focuses on why we should tidy. This was the most interesting part for me. The first two sections taught you how to become a better developer and colleague. But, in this section, you have an opportunity to question your assumptions about value, money, and business from a unique view of the developer.

As developers, we often give ourselves the right not to care about business and the "big picture" and focus on "what you are being told to build." The problem is that refactoring is a "big picture" task and must always come from developers and not management.

Implementing ideas from this 3rd section will be the most challenging. Putting an additional "economic" layer on programming decisions is always complicated for developers. But having a "business view," as well as a developer's, is a fantastic skill to have!

Who is this book for?

The book is for developers with some experience. Developers with different experiences will probably find other things interesting. Less experienced developers will find "miniature refactorings" interesting, and more experienced developers will probably find the most interesting in the last section about the economics of software refactorings.

Author Kent Beck

One of my first modern programming books was Kent Beck's Extreme Programming. A few years later, while I was obsessed with testing, I discovered Test-Driven Development. This is the time I started paying more attention to author names. Kent Beck was one of my first "programming heroes."

Check out Kent Beck's introduction to Tidy First? book - A Daily Practice of Empirical Software Design - Kent Beck - DDD Europe 2023.

It would not be possible to mention everything I find interesting about Kent Beck and his work in these few lines. So, I will finish with a link to the conversation Is TDD Dead? between Kent Beck, Martin Fowler, and DHH (David Heinemeier Hansson). It feels like a crossover episode of Star Trek when Picard meets Kirk (yeah, I know it is the movie).