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

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. :)