Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

It's just like putting LEGO bricks together... Or not?

  • submit to reddit

I once heard a speaker saying that Lego bricks are one of the most abused metaphor in computer science. I like this quote very much, but I also like the Lego metaphor as it is very effective in explaining patterns like Dependency Injection even to higher management, which is not accustomed to code every day. Thus, I wrote this little essay to analyze where the Lego bricks low level System Metaphor can be used for software components, such as classes, objects and packages, and where it falls short and becomes dangerous. After all, if software development could be reduced to playing with Lego, we would bring our kids to work.

I will use the Lego spelling instead of LEGO for better readability.

Where the metaphor is right

Here are the cases where Lego bricks get it right and have a good similarity to software components.

Let's start with the case of representing objects: you don't glue Lego bricks together, as you don't do it with objects and classes. In fact, Dependency Injection favors the object graph construction as the definition of behavior; objects can be combined together to provide functionality dependent on how they are linked, instead of who they are or who they subclass.

Dependency Injection is not only about being able to reuse bricks in other constructions: not gluing them together gives you the ability of modifying your buildings and cars (if you have some Lego Technic material) by swapping them with other pieces, maybe with the same shape and a different color (Strategy pattern), or even a different shape (composition).

Some bricks are common and can easily be found, others are more complex and are precious. As anyone inheriting a bin full of Lego pieces from some cousin can tell you, some bricks and pieces are very common and you would spend them for every construction. Depending on your repository of Lego pieces, the technical or the medieval ones can become a really scarce resource and you will have to triage your constructions.

In software some libraries, like PHP frameworks or Active Record ORMs are very common. Indeed, some others like Doctrine 2 or PHPUnit are instead almost unique instances. The number of pieces (or quality pieces) in this category is really low.

The scarcity metaphor however breaks down really fast: you can use Doctrine 2 in every project if you want, and you don't have to save it for your coolest buildings, or to steal it from another construction. Software is replicable at will, while Lego bricks availability is limited for every children (who's not Bill Gates's son). However, you will have little alternatives for a rare piece, other than the most famous one.

Software and Lego bricks construction can be really ugly at the eye if built uncorrectly, and hard to modify. The most internal bricks of a construction require a large disassembly before they can be changed. However, Lego bricks stability is not usually a problem, but I never built a 100K lines of code Lego building: it would have probably required all my garage space.

Where the metaphor is wrong

In many cases, the Lego metaphor is not appropriate, or worse, misleading.

For example, every Lego brick can be plugged in with every other one in the whole world: it has a generic interface that you cannot modify. In software it is instead considered a good practice to define restricted interfaces to simplify the possibilities supported by the system (what you can put together) and avoid misusing (like the construction of an unstable Lego tower).

Due to this restricted interfaces, it's not possible to link together software components universally, like you would do with Lego bricks from your cousin. You'll need Adapters, Facade, legacy code practices...

In software, you can create your own bricks! At least if you do not consider the bricks as the primitive structures of the programming language.

Software however has an average complexity far higher than the Lego constructions. With Lego buildings, it's possible to know in advance how many bricks are needed, and follow a precise method to complete the construction (the instructions attached when you buy a new box of pieces). In software, this is almost always a failure, but again no one have ever tried to build a functional Lego construction of the size of some meters.

In fact, the majority of Lego constructions do not have to work! They have to be somewhat stable, but they do not have to do anything (they're thought for children, by the way). This however is not always true: Lego has been getting harder with the years. Initially the classic Lego bricks had a peak in complexity on openable car doors. Then came Lego Technic and wheels and gears were introduced, with the possibility of building for instance a differential gear. Now we have computer-controlled Lego constructions with microprocessors, although I grew up before they become diffused.

It's getting harder for kids to play with Lego, but maybe this would better train them to become software developers. :)

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Reid Atherton replied on Thu, 2010/11/11 - 12:47pm

My favorite counterexample for all computer science metaphors is metaprogramming, especially when it happens at run-time, in a somewhat unpredictable fashion, depending on input data. For the LEGO metaphor, this is like a construction that purposely selects different blocks and then uses those blocks to build parts of itself as appropriate for its environment.

Andrew McVeigh replied on Thu, 2010/11/11 - 1:02pm

I think lego bricks are quite a bit like components (beans if you like) and when you plug them together, this is a very much like using dependency injection to establish connections.  A number of the other constraints which you list as being different are actually not the case for Lego mindstorms etc.  In those, the interfaces (plugs between bricks) can be different for different interfaces, and they do pass data between them.

Another analogy, that tends to come a lot closer to describing the sophisticated structure of a system is electronics.   i.e. each object is like a chip (a class is like a design of a chip), and you connect the objects together into a larger component (like wiring chips together in a circuit board).  The wiring in this case can be much more complex, reflecting how software connections can be complex.

If you want to show it graphically, it looks a bit like this:

And fascinatingly, this captures the "fractal" nature of software.  i.e. you can then treat that wired up component as a new "chip" in another circuit board, and so on, to make a bigger system.


Another very interesting topic is how you evolve these lego-like (or electronics like) structures.  For instance, if you view a software system as a set of lego bricks where layer upon layer are glued together, then a common requirement in software is something like "I like that wall, but I want to replace the middle left brick".  i.e. people reaching way down into abstractions to change something very deep, which can be very costly.  This in essence is the problem of reuse in software - changes made for specific reuse contexts.  I dealt with this as the subject of my research on extensible systems by introducing operators that allow people to customise deeply into these plugged in structures without destroying the original structure...


Andrew McVeigh replied on Thu, 2010/11/11 - 1:09pm in response to: Reid Atherton

My favorite counterexample for all computer science metaphors is metaprogramming, especially when it happens at run-time

Sophisticated component systems can express how the structure of a system changes at runtime.  In a sense, this is very much like having a brick in a lego system which can change the bricks under it dynamically. The amazing thing is, they can describe these runtime changes as a static view.

The first system to do this, to my knowledge, is one called Darwin, invented at Imperial College in the '90s.  They used to draw diagrams showing the connections between components, start up the system, and then watch the components move around in response to program events.

Darwin was a fundamental influence on Microsoft's COM system.

Giorgio Sironi replied on Thu, 2010/11/11 - 1:32pm in response to: Andrew McVeigh

I am fond of the electronic metaphor, which has in Design for testability a key tenet. However, it is not so easy to explain to business people. :)

Giorgio Sironi replied on Thu, 2010/11/11 - 1:34pm in response to: Reid Atherton

That would be really cool. :) Metaphors are just a model for some aspects of programming, they all contain imprecisions and errors.

Andrew McVeigh replied on Thu, 2010/11/11 - 1:36pm in response to: Giorgio Sironi

however, it is not so easy to explain to business people

Yeah, I know ;-)

Simon Tite replied on Sun, 2010/11/14 - 2:49pm

... no one have ever tried to build a functional Lego construction of the size of some meters.  

Not true, my friend!

James May of the BBC built a whole Lego house, and lived in it for a day. (Although it did contain some wooden bits for strength and stability, so maybe he cheated!)

Building the Lego house (YouTube)
Sleeping in the Lego House (YouTube)

Giorgio Sironi replied on Mon, 2010/11/15 - 7:39am in response to: Simon Tite

That's cool. However I was thinking about something like Lego Technic on a larger scale, with mechanical moving parts. :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.