Aside from their attraction and the many other joys of owning LEGO, there are lessons to be learned and applied to the world of software development from this humble little brick.
My son gets his first LEGO set on his 3rd birthday this week.
If you want to build a world, start by building a carOf all the kids I ever met growing up, even the ones who had parents with bottomless pockets, they still only bought one set at a time. The lesson here is that you buy one set, you play with it, you integrate it, you take it apart and change it around and not until it becomes part of everything else do you move on to the next set. With LEGO even the smallest set can deliver and look great with the rest of your LEGO world.
So here's what we too often try to do with software: We ask the customer what they want, they want the full package, we market them the full package and we try and deliver them the full package. Month's later we're still trying to build the full package.
The lesson we can learn from LEGO: First build that racecar, then deliver, play around with it, and when it fits in, then move onto the next step; maybe a gas station, maybe a garage for the LEGO person to park their car in. Build your system in small functioning parts, the benefits are obvious: Spot issues earlier; It makes more sense when integrating new functionality to see how the existing functionality works and view the context; Incremental improvements and incremental changes, when you finish the entire project if you do it incrementally you will deliver something closer to what the user actually wants and will have months of feedback.
Everything is made from something smaller that already exists
This should go without saying, but we still as developers continue to reinvent the brick every time we build something. After decades of software development you would think it would be easier, so were are our magic bricks and why is it that you are still hand coding forms for web sites?
Many frameworks allow you the felixibility of utilising built in APIs for things such as form generation etc. A fully fledged framework may not be the answer every time for the work you are doing. But have you thought about working as a team to put together your own toolbox of functionality that you seem to be writing over and over again. We have a function for building html select elements that can be populated from any array or database table and I've used it again and again and it sits in a utilities class that anyone can use.
The lesson we can learn from LEGO: Don't build it, customise it. Make use of your existing blocks and you can build something rapidly again and again with the same reusable parts.
If you've played with one LEGO set you've played with them all
The benefits of a system that is familiar and requires little training when newly built are endless and scalable. Think of this when you are designing and writing requirements. If you can make your system seem familiar to your users they will adapt and adopt faster. You should be also working towards having the best in class practices for building your 'familiar' systems; think of the many companies that have a software brand and how familiarity works in their favour.
The lesson we can learn from LEGO: The instruction booklet you get from LEGO doesn't tell you how to play with your LEGO set, but a very straight forward step by step guide on how to get you up and going. The idea is to show you what you can achieve not how you should use it. You should build your software with familiar steps and controls.
There are many more lessons we can learn and apply from LEGO, including scalability, reuse, minimalism and familiarity. These lessons are worthy of consideration for your next project.