The final decision-related Thinkie, joining Force Decision & Defer Decision.
Pattern: You have to decide between 2 alternatives, the decision is unclear, & the stakes are high.
Transformation: Why not both?
I first learned this Thinkie when talking to Ward Cunningham. The web was just getting started & the team he was working with wasn’t sure whether to have a web interface or a rich client interface (back when these were not the same). He suggested the team implement both interfaces at the same time until the choice became clear. After a month, the web interface was clearly superior & away they went.
Set-based design is another implementation of parallel decisions. This is the practice of keeping options open as long as reasonable. Designing a car & not sure gas or electric? Support both for a while.
The argument against parallel decisions is efficiency. You’re “wasting” half your effort. Well, no, you aren’t:
The parallel efforts only last until the decision becomes clear. This is generally a tiny portion of the life of the project.
What you learn implementing one of the set of decisions informs the other elements.
It’s not waste, it’s insurance. Remember, we posited a decision with large negative consequences for an incorrect choice. The duplicated effort is you insurance premium.
It seems to me that what matters most is to consider the possibility of doing both (or more to the point, not ruling the other out just yet). I worry that people will interpret this as a recommendation to do both, when sometimes doing nothing (and waiting for more information or insight to arrive) might work better.
Would the Transformation work "better" framed as "Why rule one out just yet?" Not as pithy, but maybe more faithful to the underlying idea.
"Why don't you just get it right the first time?"
Yeah.
Even though coding sheets and cards and all of that were fading away when *I* was young there's still this notion that we carve code into some sort of stone substrate with a damned chisel. GO TO CODE! GET TO CODE! Unlike most written descriptions of design or specification or whatever else CODE DON'T LIE!!! (It may be wrong -- and likely is to at least some extent -- but it's *not* lying)