The Lego Principle

When my daughters were around kindergarten age, the living room would often become a train wreck of Duplo Blocks. Instead of stepping on them during the night, I would often end the evening by building a giraffe nearly as tall as myself, and the ungrateful kids would then topple it over first thing in the morning. Nothing as healthy as starting the day with a bit of destruction.

I don't know if the giraffe inspired me, but later when people asked me how I was capable of writing large and complicated applications in such a short time, I came up with The Lego Principle.

The idea is that when building a large complex application, you should not regard it as such. Instead, you should distance yourself from the end goal and start looking at it like a ton of uniform building blocks. Imagine you have a truckload of Lego-like two by four blocks and want to build a straight tower. What would be important?

Well, for a small tower, not much would be important, and you could pretty much get away with anything (Hello World). As the tower grows in height, it becomes more and more important that the Lego blocks are uniform, fit perfectly together, and are not bent and twisted. Furthermore, the lower ones will be much more important than the higher ones.

Exactly the same analogy can be used for large applications. Instead of getting a heart attack over how complicated everything will be, start by breaking it down into Lego blocks. The closer to the bottom the blocks are (meaning they will be base classes on which a lot of other classes will depend), the more attention you will have to put into making them uniform and making them fit perfectly together. In programming lingo, that often means keeping them simple and avoiding god objects.

Note to image: A large application is actually a bit more like a pyramid than a tower. Not as "pyramidy" as the image, but ChatGPT completely refused to make a non-pyramid-ish pyramid. Also, note that in a large application, method calls only flow downwards, and data only flows upwards. This, to some extent, has to do with the paradigms from functional programming. I am not a super big fan of functional programming as some of the benefits of OOP simply are too powerful, but they have some good ideas, especially in regard to immutable data.

The good thing is that if you break everything down into Lego blocks, you can start coding right away. In my first C# application (a couple of years ago), the very first code I wrote was a wrapper for Dictionary, renaming it (in the RockStar universe) to RSDictionary. It was a good place to get my feet wet with C#, and until I make a dedicated post about wrappers, you will have to trust me on it being worth the effort.

If you are more C#-savvy, you can, of course, also start on more "exciting" blocks. In the case of a video editor, some of these could be:

• A class accessing and reading a video file
• A class holding the raw video file
• A class extracting a single frame
• A class rendering a single frame to a Control

Let me say, though, that if you present the Lego principle to a project manager and tell him that you don't need to plan much to get started, he will have a very bad day. To say the least. Planning is obviously incredibly important, especially for a company, and there is nothing in the Lego principle stopping you from planning ahead. However, if you are a single programmer on a mission, and hours spent are not super important, the Lego principle is a good way to get started right away.

Takeaway

When building a large application, you should have a very clear picture of how the classes are organised in relation to each other, and how they interact. Methods calls should ever only be sent to classes in the hierarchy below, and data should ever only be sent to classes in the hierarchy above. The Lego Principle is a great way to visualise that.

/Lars