Thread by @GeePawHill

If we're going to be serious about the design of software, we're going to have to think & talk about things that are hard to think & talk about. In particular, we'll have to reach past nearly all simple prescriptions, one-ring-to-rule's, and crisp Euclidean/Platonic distinction.

When I first woke to the Design Patterns movement, the thing that struck me most sharply was the way pattern languages resist the idea of context-free correctness, instead focusing, for any given pattern, on the forces it attempts to balance. This, frankly, blew my mind.

"Good design", in this outlook, transmutes to something like "all the forces in play are in a stable equilibrium". And the design patterns movement was saying "these are some well-known forces and the various equilibria one can find".

At its simplest, an example might take two forces and simply identify a known-stable relationship between them. You could visualize this like a slider with detente's. You can adjust it to any point in the range, but the little indentations mark "standard" positions.

(Oops, someone quickly asked offline what a "detente" is. On mechanical devices with variable settings, they're dimples in the sliding surface where the adjustment is "stickier". A miter saw can be adjusted from 0 to 90 degrees, but there are dimples usually at 30, 45, & 60.)

Real life is harder than a single dimension of force, though. We can still think of balancing forces, but there are enough forces in play that we can't do it with a single slider. The "detentes" turn into things more similar to "multi-slider presets", or even "recipes".

Anyway, the point of all this isn't just to say you should go study design patterns, THO YOU SHOULD DEFINITELY GO STUDY DESIGN PATTERNS.

(Start with Alexander's magnificent _A Pattern Language_, then go read the GoF's _Design Patterns_. After that, ask us OG's for more.)

No, the point is this: if we're going to talk about designing software, we have to, at the very least, think & talk about the forces in play. There's no context-free correctness, so we can only assess in context, and a -- the? -- central aspect of that context is those forces.

What forces are in play in design and development of software?

Did you see that sleight-of-hand I just pulled? We started by talking about design, but now I've thrown in development. I did that, not to trick you, but to alter your notion of "the forces in play in this context".

So much conversation about software design is really just conversation about the textual or runtime arrangement of the code. And that's *great* stuff. Having those conversations is one of the great joys of being a geek, in my view.

But it's not enough.

For change-harvesters, the forces at play in software design can be roughly grouped into three broad areas: The Made, The Making, & The Makers. To conceive of "software design" as "textual/runtime code layout" is to conceive only of the forces at play in the category "The Made".

We're not advocating any kind of ignoring of The Made in our conversations about software design. Far from it. If The Made doesn't actually do what it was meant to do, then, trivially, it's design-in-context is not correct. So The Made is obviously really really important.

But a finished thing, The Made, is irrelevant if we can't actually get to it. The history of engineering is actually *full* of designs that would have worked if there were a way to make them. It's also full of designs that eventually *did* work because we got better at making.

A classic example of this from our own trade's history: Babbage's Analytical Engine was a perfectly sound design, but making it was far beyond the 19th century's ability to make large numbers of precisely machined gears.

And even if we have both The Made and The Making under control, we still won't get anywhere without considering The Makers. All real-world Mades have to have Makers doing the Making. That means that great designs must account for the abilities and lacks of those Makers.

A key reason the French weren't able to complete the Panama Canal in the 1880's: worker mortality was so high they couldn't train noobs fast enough to be useful before they died. Nothing wrong with the Made (a little wrong with the Making), but big-time wrong with Makers.

So do you see, now, what I mean when I say that a serious conversation about software design means having to think & talk about things that are way bigger, deeper, fuzzier, and more complicated than just the textual/runtime layout of the code?

When we think about SOLID, or follow the recent conversations about cohesion/coupling, or consider dependency trees, or McCabe complexity, or OO/FP or Java/Python/Clojure, what we're really doing is talking about force-balancing, and we need to consider *all* the forces.

We need to talk about the Made, and we need to talk about the Making, and we need to talk abut the Makers, because each of these broad categories is composed of multiple forces, and a "good software design" is one that finds stable equilibria between the forces in play.

Today's pitch: Want to talk & think & question & argue & discuss even *more* around the change-harvester's view of the trade? Consider GeePaw's camerata, a private community of people working on just these questions.

geepawhill.org/camerata