Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

The Real Lessons of Lego (for Software)

  • submit to reddit
How many out there have head this: “We want software like Legos, that way we can snap together the pieces we need to build whatever it is we want.” Yes? Heard that? Lets leave aside the fact that software is a damn sight more complex than small plastic bricks, lets leave aside too the fact that Lego makes a fine kids toy but on the whole we don’t use it to build anything we use at work (like a car, bridge or house), and lets pretend these people have a point….

We start with the standard Lego brick:

Of course there are multiple colours:

And a few variations:

Which now allows us to snap together a useful wall:

Walls are good but to build anything more interesting we need some more pieces, maybe some flat pieces:

Or some thinner pieces, or some bigger pieces:

It might also help to have some angled pieces, you know for roofs and things, and remember the slant can go either way, up or down:
I think we’re heading for a house so we will need some doors and windows:

Personally I like wheels, I like things to move, and so do my kids. So we need some wheels - different size of course, and some means of attaching them to the other Lego blocks:

If we are building a car we need to be able to see out….

Umm… my imagination is running away, we need to steer, and how about a helicopter, and a ramp to load things onto the car/boat/plane/.…
Still, something missing…. people!

Lego is not homogenous, when you say “Lego brick software” people are probably thinking of the first 2x8 block I showed. But to make anything really interesting you need lots of other bits. Some of those bits have very specific uses. I’ve not even started on Lego Space/StarWars, Harry Potter Lego or what ever this years theme is. Things get really super interesting when you get to Technical Lego. But there are some things that every Lego enthusiast knows:
  • You regularly feel the need for some special part which doesn’t exist
  • You never have enough of some parts
  • You always make compromises in your design to work with the parts you have
The components themselves are less important than the interface.  The interface stays consistent even as the blocks change.  And over the years the interface has changed, sure the 2x4 brick is the same but some interfaces (e.g. wheels with metal pieces) have been removed (or deprecated?) while others have been added.  There is an element of commonality but the interface has been allowed to evolve.

So the next time someone says: “We need software like Lego bricks” remind them of these points.
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

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


Mohammed Hansen replied on Thu, 2013/06/06 - 4:56pm

hi dude, be careful, i had a cease and desist order from lego denmark's lawyer, when i first named the 02 Software Architecture Architecture for the "Lego Software Architecture" ;)

ps, check it out for yourself, it contains a lot of the same ideas, basically "standardization above everything" -

Allan Kelly replied on Sun, 2013/06/09 - 7:43am

Wow, sounds like Lego have something of the Disney about them!

Ben Christy replied on Sat, 2013/06/15 - 4:21pm

 it isnt the gui that will make it "lego simple"...

on lego it is the bumps and holes that make the interoperability not the smooth sides. smooth sides and flat base flat top make the pretty look, but smooth interoperability of bumps and holes are how data transfers between parts, when it works the user don't see a thing of the mechanics (holes and dots).

the problem is that programmers are using a gui to make them work together.  using a third party gui to connect a database to a spreadsheet is like connecting a red brick to a window piece by using a Lincoln log in-between them...

it is unnecessary, and clunky.  legos already have a built in interoperability that allows for a smooth interface... and if program "A" wants to interact with program "B"  throw away the clunky gui and build them so they recognize each other on start-up... maybe even allow which ever one is started first to recognize that the other exists and have the first (which ever one, NOT a required first start-up) start the other, or at least ask if they want the other one to start up.

a partial example to this is the wonderful program "IMGBURN".  it takes any of a number of image files and burns them to disk with little user input.  you just have to say what file to burn...

but one type of disk image, called cue/bin, so named for the two extensions used, requires you to get information from the cue file to decide what to do with the data in the bin file.  in theory you could place many bin files onto a single disk with the cue file listing them all and the specific order named.  the bin files are just binary data.  but IMGBURN doesn't "burp" (break) if you double click the bin file, it just looks for the cue file with the same name and proceeds (after chiding you for using wrong file) 

<p>the chide screen isn't needed but shows how smoothly the program can be written

Kell Sønnichsen replied on Mon, 2013/06/17 - 2:02am in response to: Allan Kelly

Not really.

As Lego also makes software I can understand that they don't want a "Lego Software Architecture" that doesn't have anything to do with Lego. But they probably didn't need to use a lawyer to get that message through, though :-)

Their main problem is probably that often "lego" is more or less used as a metaphor for "things that can easily be put together". Just like "xerox" is (was?) another word for copying things on paper.

Jasen Jacobsen replied on Mon, 2013/06/17 - 8:08am

LEGO Group prefers to be referred to as "LEGO" not "Lego". And they prefer the term LEGO bricks or LEGO blocks, not just "Legos".

"If the LEGO trademark is used at all, it should always be used as an adjective, not as a noun. For example, say "MODELS BUILT OF LEGO BRICKS". Never say "MODELS BUILT OF LEGOs".

To the content of the article:

LEGO bricks make very nice static models. But they don't move much and pass information - that steering wheel is a nice ornament, but it doesn't do anything but spin around. They can be built to create complex things, but those things usually have lots of planning, instructions, and iterations.

What LEGO bricks do bring to the table is a very clear interface. The same interface is on a wide variety of blocks and can be used very flexibly. BUT, the interface also breaks down - if you stack too many bricks the structure becomes brittle.

So they make a nice analogy; but stretched too far, the analogy breaks down like a tower of 2x4 bricks.

Comment viewing options

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