Lego blocks are never a good analogy

Technical and tech-adjacent writers seemingly never tire of describing various technologies as being “like Lego blocks”. Here’s just the latest example I’ve come across, and a particularly egregious one:

In the new world of Web 3.0 closed systems will be replaced by open systems, centralized by decentralized/democratized and interoperability modularity will rule (think how Lego pieces regardless of where you buy them, and from which set, work with each other).

Here are some other things which have been compared to Lego:

The list goes on. Joel Spolsky complained about the overuse of the Lego analogy in 2006, citing an instance from as far back as 1991.

Some take issue with the optimism inherent in the analogy. These writers claim that, via the Lego-like nature of the advertised technology, building software-in-the-large will become as easy as snapping Lego blocks together. Spolsky, in opposition, quotes a 1987 essay by Frederick P. Brooks Jr.:

Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any–no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years.

Brandon Byars writes, in a post titled You Can’t Buy Integration:

While we have historically drawn up our project plans and costs around the boxes — the digital products we are introducing — the lines [the integration between components] are the hidden and often primary driver of organizational tech debt. They are the reason that things just take longer now than they used to.

If that’s the case, it illuminates why the Lego block is such a poor analogy for software and technology.

  1. Lego blocks have an extremely simple, single interface. There is only one point of connection between blocks, and that point is identical across all blocks, and that point is parameterised by exactly two numbers: the diameter and height of the stud.
  2. Lego blocks have a uniform purpose. Every single piece of a Lego construction has the same purpose: to provide aesthetic enjoyment as part of a whole Lego artwork.

Constructing a Lego artwork is a creative endeavor. Practical concerns - like structural integrity - can be either ignored in small-scale constructions (thanks, in this example, to the strength of the interfaces between each block), or can be worked around by modifying the creation in a way that maintains its aesthetic value.

Software is not like Lego artwork.

The interfaces that software components expose must necessarily have orders of magnitude more parameters than the single simple Lego interface. While some technologies can remove interface complexity, especially when compared to older or more complex technologies, even a “simple” Docker container or HTTP endpoint is unimaginably complex when compared to a Lego stud.

And as for purpose - the purpose of each software component is typically unique within the larger system. Software amalgamations do not have uniform purposes across all components, almost by definition. That means it is impossible to “work around” integration problems by simply changing the design to something else with equivalent aesthetic value. The “lines” in our software architecture diagrams represent mediating between the purposes of each component, not just their data formats or interface representations.

Brooks writes that software is better grown, rather than built:

Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy … The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

The promise of “Lego-driven development” is that each piece is interchangeable, easy to integrate, and uniform in purpose - like bricks in a wall whose length and height is known in advance. But that belies the reality that components themselves grow over the course of a project. Boundaries change, purposes are introduced and discarded as the project’s scope changes, and functional requirements dictate the system architecture more than the aesthetics of the architecture diagram.

Describing technology as Lego is wishful thinking at best, and malicious false advertising at worst.