What Software Frameworks can learn from Lego

Lego is a common metaphor used for modularity, and it’s used frequently when discussing software frameworks. Modularity and the closely related concept of composibility are very powerful concepts in the context of technology, and Lego is used frequenty as an analogy for building blocks that fit together easily and allow the end user to build useful structures. This makes sense; lots of people build with Legos growing up, and it encapsulates the idea of simple, compoible components in an easy-to-understand way. Generally the analogy ends there, but I think there’s much more to what makes Lego fun, useful, and accessible to such a wide range of audiences that we can learn from when designing any type of framework. The discussion here will mostly focus on what software frameworks can learn, though I think many of the ideas are transferrable to other domains as well.

I spent a lot of time building lego when I was growing up, and I can identify at least three distinct modes of building: instruction-based, inspiration-based, and target-based. Each of these, I believe, serves a specific purpose, and together they constitute an ecosystem that allows a low barrier-to-entry and a fun experience for builders of almost any skill level. Instruction-based building refers to building a Lego set purchased from the company. In this mode of building, not much creative energy is required from the builder, however this mode of building can allow someone of almost any skill level to produce a very cool artifact. It also teaches the builder novel ways that the pieces can go together to produce interesting new shapes and mechanisms in their creations. I started playing with Lego at a very young age and was quite comfortable building my own creations, but still found a lot of enjoyment in getting a new Lego set for Christmas and going through the instructions. I almost always learned something about designing my own creations by seeing what the professionals had come up with. In addition, by putting the set together I necessarily learned how it went together, which made it very simple to remix and add my own touches to the final product. For these same reasons, good tutorials are a vital part of any software ecosystem. Someone new has to be able to come in and not just make something cool, but vitally understand how the cool thing came together and why, so they can make changes and build their own things on top of the final product. Having templates for particular types of projects and things of that nature can save a lot of time, particularly for experts in a particular domain. However, only when the end user understands how they’re put together and why are they fully empowered to build on top of them.

Inspiration-based building refers to how a single Lego piece can be so interesting on its own that it gives the user ideas for what could be built with it. Often this would come after receiving a Lego set and noticing some of the new pieces that came with it, or simply from aimlessly searching through my Lego collection and finding something that piqued my interest. I might find a chef’s hat and think “perhaps I should build a restaurant”, or I could find a matching set of wheels and think “perhaps I should make a car/truck/dune buggy/whatever”. Instruction-based learning can only go so far—I would never find it fun to build a set twice, and I certainly didn’t have enough sets to satisfy my desire to build. For me, instruction-based building only comprised a small fraction of my total time building Lego. A much larger portion was spent scanning through my Lego collection, finding a piece or combination of pieces that was somehow interesting, and being inspired to build from there. This, too, I think should be an aspiration when designing software frameworks: for the pieces to be simple and interesting enough that the user can imagine an entire creation just based on one feature or component. In my eyes this property of a framework is a way to “bootstrap creativity”—someone can come in without a specific target and be inspired based solely on the possibilities they can see from the components of the framework.

Target-based building is another distinct mode of operation I’ve identified, where rather than being inspired by a specific Lego piece I’d have an idea of something specific I’d want to build. Maybe I wanted to recreate the Empire State Building or a spaceship from some movie I’d watched recently. The possibilities of Lego are endless, and it’s a flexible enough platform that a user can simply come in with an idea alone and render some version of it. This mode is buildling is the most open-ended, and requires the greatest level of creativity to get started. It also takes the most skill to envision something and render it from scratch with the pieces available. That’s why having the other modes of building are important for users to onboard and accumulate skill in building Lego. Ideas most often are not generated in isolation, and for me ideas of specific targets to build would most often come when I was engaged in one of the previous two modes of building: I might find a piece that made me want to create a spaceship, then envision other types of spaceships in the fleet and want to build those. In software frameworks, this is always the ultimate end goal: to unleash the creativity of the end user to build whatever their mind can imagine. This requires the framework to be flexible and extensible based on the needs of the user. This is much easier said then done, of course, since the scope of possibilites of what can be built with a software framework are far greater than what can be built with Lego.

Taken together, these three modes of building represent three distinct components of the user experience that are very necessary to any software framework that wants people to use it: instruction-based and inspiration-based building onboard users and get them familiar with the basic mechanics of the platform, while also providing learning opportunities and cultivating creativity for more advanced users. Instruction-based learning is mostly dependent on prepared tutorials, whereas inspiration-based learning requires the system to be designed in an intuitive way so that users can visualize interesting creations based on the components alone. Target-based learning requires the platform to be flexible enough that it can be used to turn creativity alone into meaningful creations. Within the Lego platform, all three of these modes are supported very well, which I contend is a large part of the reason why it’s so popular and enduring.

Another important feature of the Lego platform is that the components themselves are intuitive, and they connect through a very small number of basic interfaces. A child can pick up two legos and figure out how they go together quite easily, and once they understand that they can pick up almost any two pieces and put them together. In addition, though there are many, many different pieces of lego in any given collection, they are mostly created in predictable ways: the relationship between a 4x2 brick and a 2x2 brick is very easy to see; the former is basically just two of the latter glued together. The effect this has when building is that the user can almost immediately know what piece they’re looking for, as well as other ways to get the job done. If I’m buildling a house and need a 4x2 brick for one of the walls, I know that finding two 4x1 bricks will probably do the job, or two 2x2 ones could as well (although I may give up some structural integrity with this choice depending on the context). This property of Legos—how incredibly intuitive they are to use—is something that requires excellent design choices, and can be lost with some poor ones. Growing up I always sort of felt like sets introducing a new piece to solve their problem was them “cheating”; I’d rather have seen them find novel ways to combine the existing ones, and if they introduced a new piece with every set eventually Lego would become far less intuitive to the user, as the scope of possibilites to solve any given problem would be both wider and more narrow; rather than finding either a 2x4 brick or some combination of bricks that could do the same job, I’d be working with hundreds of specialized components that were built to do very specific jobs. This is an important consideration when designing software frameworks as well. When using something like Django, there are a relatively small number of core components used to solve problems: views, models, context processors, apps, etc. When solving a problem, someone with a bit of Django experience can generally determine which of these components they should reach for. A counterexample I’d cite is CSS, where there are so many different directives and relationships between them to learn to gain a working knowledge that understanding it makes someone a very hot job market prospect. On the other hand, semantic HTML and frameworks like Bootstrap provide a more modular approach to building web pages that I’ve personally found much more intuitive.

While “Lego pieces” is often used as a shorthand in explanations for modular components, I believe a lot more about good platform design can be learned from Lego. A successful platform doesn’t just need to be powerful, it also needs new people to learn it, grow with it, and eventually graduate to building whatever their creativity can imagine with it. I believe Lego’s approach to intuitive components that connect with a small number of simple interfaces as well as providing high-quality tutorials for a range of outcomes in the form of sets is an important subject of study, and a lot can be learned from it when designing frameworks of any kind.