Is LEGO your reference for IT?

LEGO. Who has not grown up with these plastic bricks of wonder? I sure have. My brother and I were lucky to have the entire attic floor to ourselves, allowing us to scatter these bricks over a large surface and build whatever we wanted. We even had a pact: we would always keep playing with LEGOs.

Though we want to keep the pact recently, my brother and I have recently revived our love of LEGO: new boxes and builds now adorn our houses. And where my brother can hide behind his kids when heading out on a LEGO-store trip, I don’t have that luxury and have to own up to this regained hobby.

And I am not alone in this. LEGO has gone after the adult market with a vengeance and enjoyed great success.

From experience, I can tell you a fair share of IT professionals fall into that customer group. And that is no surprise, as some of the analogies and references of LEGO in our IT industry are easy to grasp. We easily talk about the building blocks of our new application, how they fit together and how we are ensuring we build something modular. Heck, re-use components for new/other applications are as close as you get to building your LEGO building, breaking it down, and building something new.

It doesn’t stop there. I have seen multiple cases in which a whole landscape of applications of an organization was modeled in LEGO. Yes, a big table, a lot of colored bricks, and a lot of strings to represent data dependencies and the like.

It is, therefore, not weird when LEGO is used to communicate IT processes or concepts with people who are not in IT but dependent on our work. 

However, there is a drawback when using the LEGO analogy.

Let me illustrate. Getting home and opening up one of my brand new boxes of LEGO (no, not Starwars if you were guessing) two things struck me.

Firstly, LEGO builds have evolved considerably becoming more complex, varied, and exciting. 

Secondly, where our IT analogy can fall apart, a builder follows the instructions until they finish with an awesome product. And this is, unfortunately, how many people view IT. 

The problem with this is the following:

• There is no booklet – There are no instructions to follow. No one has laid out the path ahead to the final end result. There is no numbered picture book.
• Only some bricks exist – Yes, 80% of our application code is open source. You still have to build some bricks from scratch, and some of those older bricks might not follow the standardized measurements that make LEGO backward-compatible for 50-odd years. This can be quite a challenge.
• There is no picture on the box – In perfect circumstances, there is a good business description of where we want to end up; what the application needs to do and what non-functionals it needs to adhere to. But more often than not, this picture is scattered across the organization and it changes over time.

The good thing is: we have a solution for this. Agile development. Build something small, review, change and add to it. Making software development a creative endeavor.

And this is also easy to understand. How? 

Next time you buy a box of LEGO, open it up, throw out the booklet, and start building the depicted item on the box. Now you are getting closer to a LEGO analogy that really applies to developers, whilst hoping that nobody changes the box as you are building.