Are you a Lego maniac? I’d consider myself one. I have collected a few of the recent modular designs. These are 2000+ piece kits which connect to each other. They are great, because it’s relaxing to build a kit and they are display pieces after they are done.
In my constant education about software design, it dawned on me a few days ago that there is a lot to learn from the Lego company and their products when it comes to software development. NOTE: Keep in mind I am not saying that “building software is like building a Lego model,” which would be WAY over simplifying software design.
What can we learn?
Early designed bricks work with current Lego models
It took the Lego company a few tries in the beginning but once they settled and patented a design in 1958 it hasn’t changed (http://en.wikipedia.org/wiki/Lego). If I had bricks from 1958, they would fit my current models in 2011.
In software design, sometimes new technologies come along, old ones are considered old, have passed support life cycles and it’s required to make changes to the software. However, software patterns and practices don’t change too frequently. It’s better to plan out a design as if it will last 50 years rather than to have a short term attitude of “eh, it will change in 5 years anyway.” Have pride in your initial designs!
Quality is important
I just checked, I have about 30 Lego boxes in my closet. I cannot think of a single time when a piece has been malformed, broken or missing from a kit. Not. One. Time. These models are generally not cheap, but instead of paying for only a brand name, I pay for a brand name and the knowledge in which my model will be complete and perfect.
In software, it’s okay to charge your customers a premium, given your product and service is perfect.
The beauty of the modular designs is that… well they are modular. The picture on the left shows 4 parts to the building. This allows for an easier build as well as gives builders easier, shorter tasks to complete the model. It also helps budget time to finishing a model and it gives easy stop times.
In software, sometimes we build and build and build and build, eventually causing a tightly coupled system which is hard to implement unit and quality assurance testing, thus leaving more room for mistakes. Software must be planned out into the most modular components and designed as such. The authorization provider should not have to depend on the logging provider and vice-versa.
Slow and meaningful release schedule
As a consumer, sometimes this can be frustrating. However, the Lego company doesn’t spew out mediocre model after mediocre model and when one is finally release which I am interested in, it’s almost euphoric. They spend lots of time and resources planning every one. Even though I don’t care much for the Star Wars or Harry Potter series, I know that if I were to buy a kit, it would be fun and nicely detailed. There’s a consistency among all the models.
I get frustrated with fast release timelines because it becomes difficult to know where you are on the curve and whether your system is compatible with build 494820. If you are designing software, focus on a solid, well thought out, well planned release so that the wait was worth it, rather than slapping it together. I’m more impressed with software releases which benefit me as a customer rather than who updates the most.
Know what you are building
On the Lego box, there is a nice bright picture of what I’m building, as well as details on the back. In the instruction manuals, images are language-agnostic, precise, colorful, and represent exactly what is being built.
In software development, an SRS document is essential for major products. Software needs documentation before it’s built! Every architecture, connection between two modules, business requirement and design must be available. Think of it this way: if I needed to hire a developer, how long would it take for them to realize the project’s vision? If the answer is anything but “however long it takes them to read the documentation” then the documentation needs to be revised and completed.
Extensive instruction manuals
Lego provides great instruction manuals, which anyone can follow along. They have no words or complicated diagrams but still convey a great answer.
Provide users with detailed instructions which aren’t too wordy or complicated so they may get the best experience.
Users will find interesting ways to break your model
The awesome thing about Lego models is that they don’t HAVE to be built exactly as Lego intended it. While I generally don’t do this with buildings, I always try to modify vehicles so they perform better. When I was a kid I used to roll vehicles down the stairs so I can fix and rebuild them.
Users will find unique and unintended ways to use your system. While rewarding this behavior (as Lego does) may not be advantageous in a program, the user needs to be redirected to the right path without insulting them with a bizarre error message or blank page.
So are you a maniac?