Program design is like creating the lego instruction book

Modern research institutions tend to produce a lot of (ideally, but usually not fully) atomic contributions.^1 These contributions resemble lego bricks in that you can intuit that while they are not useful on their own, they will be useful as part of a broader system. But like most lego bricks it’s not immediately clear what amazing thing the brick can eventually be part of (and in fact it can be part of many things!) Even a giant bucket of lego bricks often doesn’t immediately suggest what to build. This ‘bucket-of-bricks’ is the state of many disciplines. That description is extreme. The situation is more like we have the picture on the front of the box and the bricks that came in the box mixed with a bunch of extraneous ones. Thought leaders and big ideas people are talk about the different box-pictures. So everybody has a vague idea that their brick is a part of the spaceship, but if you’ve ever put together a lego set, it’s rarely clear where each part fits in until you see all the intermediate steps in the instruction book.

The goal of §Program Design is to create these intermediate steps. For example, the painfully unsexy step 34 that has a bunch of tan and grey pieces in a rough octagon with some slopes on it that doesn’t look like anything at all. It is hard to know that step 34 is going to lead to the awesome spaceship on the box; it certainly doesn’t look like a spaceship.

Getting step 34 to happen is hard. You need to create a sense of the interior of whatever the picture on the box depicts, which pieces are available, which pieces you would ideally have, and which substitutions are ok (it doesn’t really matter if you use a neon green brick instead of a grey one as an interior part.) If you really need a piece that doesn’t exist, you need to encourage that to happen. And then you need to get all the pieces together - just because you put together an actionable plan does not mean people will take that action!

Ideally, as many steps as possible are relatively self-contained ‘modules’: the cockpit part of the spaceship, a secondary landing craft, an escape pod. In real life, this corresponds to intermediate goals that are useful on their own or at least exciting milestones or demos. There are pages to be written about the tension between the real benefits of useful intermediate steps and the danger that undue focus on useful intermediate steps can pose to eventual outcomes.^2 In hindsight it’s easy to both look at technological development and forget how many incremental useful steps there were - top of mind is that synthetic plastic was used as a nifty liquid by printers before it was accidentally cooked - and to forget how much work has gone into technologies before they get to anything useful - transistors needed eight years of work before the first completely unusable point-contact demonstration.

Obviously, this analogy can only be pushed so far: research-heavy programs will inevitably have gaps between steps that would make any lego-assembler tear their hair out: the picture on the front of the box might be fuzzy or wrong; In real life, pieces don’t just snap together; Heuretics come out of people’s brains (TECHNOLOGY IS PEOPLE), so you need to deal with incentives, politics, and egos; etc.

You could reasonably object to this analogy with a counter-analogy that atomic pieces of work are less like legos and more like biological components. Separate components in a biological process have much more ‘agency’ - if you create the right environment and shake or apply a jolt of electricity, they will self-assemble. The biological analogy would be much more apt than a lego analogy if paradigm shifting work cannot be planned or the innovation ecosystem is ‘directionally’ correct and just needs more funding and work along existing channels.

I suspect the reality is a mix of both analogies - unlike in lego construction you can’t lay out every single step so ‘biological’ self-assembly between steps will be essential. Keep in mind that these analogies are meant as thinking tools, not evidence or predictive descriptions of the world. Analogies should be used as thinking tools but not as evidence. Hopefully, though, the Lego analogy is provocative. Playing with it is a more tangible way to describe the need for program design overall and suggests extensions, like the the the possible role of simulations <Good Simulations could be the ‘why now’ of roadmapping tools>, and legible intermediate steps.


^1: At the same time, modularization is important! See:The Architecture of Complexity and arthurNatureTechnologyWhat2009 Modularization enables pieces to be used in many different technologies etc.
^2 : See - Most roadmaps suck, Decoupling from market discipline is like cave diving, Systems must take performance hits to get out of local optima

Web URL for this note

Comment on this note