Not too soon. Not too late. Instead, just right.
I’m calling the style of software design I’m advocating “empirical”. How did I pick that word?
One great secret debate in software design is when? (The other is lumpers versus splitters, which I will go into another time.) When people say “XP ignores design”, I hear it as, “XP doesn’t design when I design (and therefore it is bad/doomed/evil/whatever).”
Because we don’t acknowledge “when?” as a legitimate design dimension, it’s hard to have a conversation about it. In this style I’m talking about the up-fronters can’t see that design is happening at all or if it is happening it’s happening at exorbitant cost. The maybe-laters see it as a waste of time, interfering with the delivery of the all-important next feature.
Tradeoffs—Sooner
Seek first to understand, right? So what are the world views of what I would consider “sooners” & “laters”? How do they perceive the world?
The sooners seem to see the costs of design rising once you have a system in place and running. Better to make design decisions now when they are cheap than later when they are expensive.
I don’t think that’s all that’s going on, though. A fear I hear expressed frequently is that design “won’t be allowed” later. The designer had better design now because otherwise they’ll never have the chance.
(There’s a curious parallel between this worldview & the worldview of the product person who believes they have no choice but to ask for all the features now because if they don’t ask now they’ll never get more features. 🤔)
I’m not saying these are the beliefs of someone who believes in designing (what I would call) too soon. I’m saying they are consistent with the behavior & conversations I observe.
Later
Since we see different behavior from the “design later” folks, they must hold different beliefs. What might those look like?
All I’ve been able to come up with is that Laters see delay as the primary driver of cost. The longer we wait to design, the less design costs.
Just Right
I think both schools have a point. Delay is expensive (sometimes more so than others, a topic I cover in detail in 3X: Explore/Expand/Extract). Not designing at all is also expensive. (I’m not so worried about the cost of in situ design—another topic for another time.)
Both schools also miss a point. The Sooners miss the cost of mistakes. Design too far in advance of need has a greater chance of ending up unused or, worse, counterproductive. Unwinding design is expensive.
My tradeoff space looks like this:
The magnitude & shape of these curves relative to each other will dictate where we should be on the sooner-later spectrum. “As soon as possible” & “as late as possible” are not the optimal answer given this tradeoff.
“Empirical”?
So, what word to apply to this “not too soon/not too late” style. NTSNTL is awkward. I tried the word “responsive” but that was hijacked by the visual design folks.
A branding word or phrase must satisfy a difficult combination of constraints:
Catchy—the word should immediately snag attention.
Memorable—the word should be memorable later.
Accurate—it’s tempting short-term to lie with branding, but maintaining a misleading brand requires too much effort.
Distinctive—the word should highlight differences with the alternatives.
Positive—(this one is a bit manipulative) the word should put alternatives in a negative light. (“Structured programming” took off in part because it was better, but also because no one wanted to be “unstructured”.)
I like the word “empirical” in light of these constraints. The alternatives are speculative—design done so soon as to increase the cost of mistakes & delay—and reactive—design done after the cost of coupling has already been paid repeatedly.
There you have it. Tidy First? is a daily practice of empirical design. We look at the behavior change we want to make. We look at the design as it is. We decide, empirically, what the design should be to reduce the cost of the behavior change. Then we decide, empirically, whether the structure change is worth it.
In traditional pre-agile software development, the cost of change does indeed rise substantially, maybe even exponentially, over time. The cost of testing goes up. The risks of regressing functionality when making changes goes up.
But the big change in perspective, which you led, was to realize that things did not have to be this way: Instead of making decisions based on fixed cost-benefit curves and calculations, we could instead dramatically reduce those future costs with changes in the process of building the software.
Likewise, the "I have to ask for everything up-front or I won't get it." is an inevitable result of the way we fund and make decisions on improvement initiatives -- "projects." As an industry, we usually structure it that way. But we don't have to. With build and delivery approaches that enable iterative delivery with substantial change over time, without excessively increasing costs, one can sensibly do iterative requirements specification too.
It's not just a different view of fixed cost-benefit curves. It's a fundamental changing of the curves themselves.
Your draws triggered me (because of ocd) but it worthed! Thank you.