Why I Came to Write "Tidy First?"

Software design is a sharp tool. Some folks don’t know they can wield it. Some folks who wield it grab it by the blade, not the handle. That’s one big reason why I’m writing about software design. It goes back to my personal mission statement: help geeks feel safe in the world.

That mission cuts two ways. Sometimes geeks design software in unsafe ways, ways that accidentally break the behavior of the system, or ways that strain the human relationships supporting the software. It’s sensible to feel unsafe when you’re acting unsafe. It’s far better to feel unsafe when you’re acting unsafe than it is to feel blithely, cluelessly safe.

Helping folks learn to design safely contributes to my mission. Hence you will see frequent references to working in small, safe steps throughout these pages. I’m not interested in short-term acceleration. Software design creates value, when it creates value, that realizes over time.

Tidy first is a bit of an exception. When you tidy first, you know you will realize the value of tidying immediately. This is a setup. I want you to get used to manipulating the structure of your code just as much as you manipulate its behavior. As we get further into design we’ll talk about actions with longer and longer term payoff, actions that affect more people.

When I read other descriptions of software design I missed the critical elements of “how much?” & “when?”. Other software designers seemed to act like design took place out of time, either before you had any of that pesky code to slow you down or in an indefinite timeout from the ongoing pressure to change the behavior of the code. I wanted to explore “how much?” & “when?” & see if I could offer useful principles for answering those questions.

Software design has always offered me an intellectual puzzle. I enjoy the moment of saying, “What is the design which, if I had it, would shrink this big change into a bite-sized morsel?” For my taste, there is a whiff of sadism in programming, a heroic self-immolation on the pyre of complexity. The world is hard enough that we can’t afford ignoring opportunities to make things easier for ourselves & others.

Another aspect of the puzzle of software design is figuring out what forces drive it & what principles to use to respond to those forces. Much design advice just flat out contradicts the available evidence. Why is it that skilled designers produce results that can’t possibly proceed from the principles they espouse? What’s really going on?

A book offers nowhere to hide. If I don’t understand some topic fully, you’ll know & there’s nothing I can do about that. An example is cohesion, a concept I could crisply define 15 years ago but couldn’t satisfactorily explain until last year. I want to push myself to understand.

Avalanches are the best. There’s a particular moment I hope you’ll get to as you practice tidying first. You tidy this bit that makes this feature easier. That bit that makes that feature easier. Then the tidyings start to compound. Because you made this easier then that becomes easier. Suddenly, without ever straining, a giant simplification becomes the matter of a stroke or two of your pen. And because you brought your colleagues along every step of the way you have a totally-informed audience for your genius, an audience that becomes more appreciative as they too begin to harvest the benefits of you little-little-then-big structure change.

I’ll finish my list of motivations with finances. As I’ve written elsewhere, I don’t write to make money, I make money with writing so I can afford to write. As with all technical books, I don’t expect a jackpot payoff from these books. If I can afford a better car, that’s plenty to encourage me to write instead of painting, playing guitar, or playing poker. So yes, I want to make a little coin with this but I intend to offer far more value than I charge.