Introduction
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 ...