Technical Decisions Series - Multitracking And Set Based Design
Multitracking
One of the major enemies of decision making, is not considering all available options in the decision process. Thinking outside the box has become a mantra in all business settings, as an overreaction to this natural limitation. The most popular name of this cognitive bias is structural fixedness, or narrow framing. In large organizations, it's very common to use the same solutions to new problems, just because they worked in the past. This is a common design anti - pattern. The narrow framing is one of the 4 sources of bad decisions (you can read about the other 3 here) as the authors of Decisive: How to Make Better Choices in Life and Work discuss extensively in their book. What they suggest as a possible solution to this problem is multritracking. Multritracking is the habit of exploring more than one alternative option as a possible solution to a problem at the same time. And then finding solutions that combine features from different alternatives, at the same time. Instead of focusing on, why two solutions cannot work together, the focus shifts on how they could possible be combined in to a new concept. This is a great tool for challenging preconceived assumptions, that lead to poor decisions. But lets narrow this concept to technical decisions.
Set Based Design
One key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment.
Set based design as opposed to point based, generate solution that explore different trade-offs .Its is one of the paradoxes of Toyota Production System and Lean, because someone would assume that creating multiples versions of a prototype or design would overall create more stuff, that should be thrown away eventually and thus more waste. This is not the case. One of the insights here is that working in parallel each of the features is exposed faster to the final client and gets feedback faster. This is actually another core principle of lean, that states "deliver as fast as possible" and is the flip side of "decide as late as possible" which already examined.
To understand better why this works, lets say we need to implement 3 features on a product iterativly. If we use sequential engineering we start with feature A and iterate on this in 2 week sprints. At the end of which we display the solution to the client and get feedback. After we finally finish with A, we repeat with B and C. In concurrent Engineering we start all features in parallel, in 2 week sprint the customer can provide feedback for all A,B,C features, and then iterate on that. If There is a opportunity cost, the second solution worth the waste that design parallelism creates. Also, in this way working the different features in parallel, before we combine them, we are keeping our options open as time progress. Also we are not finalizing integration decisions between them.
One of the ways set based design can be incorporated in software architecture is through a classical Agile Technique : Architectural Spikes. I will expand in the next post about : Architectural spikes - Technical Decisions under extreme uncertainty
Bonus : Set base design & business model design
After Eric Ries, Lean startup book the application of Lean concepts in Business development became prevalent. Set Based Design can and should be used in business design phase also. Using the business model canvas tool to generate multiple alternative business models and iterate on them allows a faster validation of critical assumptions about the model .