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. 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 is realized 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’ve read other descriptions of software design, I’ve found them to be missing the critical elements of “how much?” and “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 time-out from the ongoing pressure to change the behavior of the code. I wanted to explore those questions, and see if I could provide useful principles for answering them.
Software design has always offered me an intellectual puzzle. I enjoy the moment of wondering, “What is the design which, if I had it, would shrink this big change into a bite-sized morsel?” For me, there is a whiff of sadism in programming, a heroic self-immolation on the pyre of complexity. The world is challenging enough that we can’t afford to ignore opportunities to make things easier for ourselves and others.
Another aspect of the puzzle of software design is figuring out what forces drive it, and 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, and 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, that becomes easier. Suddenly, without you 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 it, too, begins to harvest the benefits of your 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 it means 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.