What Software Design Can Learn From Lego

Lego Emporium

Completed Emporium

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.

Lego Modules for Emporium

Module Demonstration

Modular building
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.

Lego Manuals

Lego Manuals

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?

Better Code: Code Reviews

In my new role at Brand Integrity as lead developer, I am tasked with the responsibility to perform code reviews on our platform.  It’s one of my favorite parts of the job (besides the fame, fortune and socialite lifestyle) because not only does it help the platform, it helps me become a better developer as well.

If you look up “how to perform code reviews”, you can find a plethora of blog posts on how to perform and survive code reviews.  I’ve decided to highlight a few things to share that I have learned from my experiences which I believe are very important.

For Reviewers

Consider doing the review in two pieces:  one together and one separate.  Generally whenever I code review, it’s mainly because an important module has been changed or a developer is working through a unique solution.  It takes time to understand approaches.  I’d suggest as a reviewer, take a look at the code before meeting together and write down anything you would like to review. Once you get together, you can have a healthy dialog about how a particular piece of code was approached, rather than wait 15 minutes while the reviewer goes traverses the source code.

Only make minor changes, don’t make major changes.  It is the developer’s responsibility to fix and rework the code based on the review.  If there are simple code guideline changes, it’s okay to make those changes as long as the developer is aware of it (it’s just easier and quicker).  Make sure before you end your review both the developer and reviewer know what is expected to be completed.

Don’t do surprise reviews.  I just think this is a terrible practice.  I did it once and felt bad after it.  Allow someone to decline the invitation.  Sometimes someone just isn’t ready for a review on a particular module.

Make a list of priorities specific for the review. Everyone involved in the process (the reviewer and developer) should be aware of what is important within the review.  While developers should not code just for what is in the review, it’s good to know what you as a reviewer are looking for.  This can be different between reviews, and it should be reflective on what is important to the development department as a whole.

For Those Being Reviewed

Have pride and confidence in your artIn most blog posts, you will see “don’t take it personally” a lot, and generally as one of the most important points.  I respectfully disagree with the advice.  It is true that you shouldn’t be emotional in a code review and think any recommended changes as a personal slight, but have pride in your work and you SHOULD take it personally!  Have faith in yourself as a developer and explain why you did it your way.  As a reviewer, I may have not have realized what you’ve done (after all, I’ve only looked at your code for a small time) and you may be right.

If you are the one reviewing work, recognize you may be treading into sensitive territory, and recognize that everything is generally written for a reason.

Be prepared to justify your work. Be ready to defend what you did. You wrote it and it is yours.  If you are in a situation where you are truly not sure if what you did is the right approach, still try and justify your solution because it may still be the right path.

Coding in General

Make functions do precisely one task.  One thing I’ve learned as a reviewer (anyone’s code, including mine) is that it is infinitely easier to review code which has been structured where functions have a single and specific purpose.  Of course, this seems like “well duh” but if you do a lot of UI coding, it’s easy to forget.   One of the worst offenders is within code behind development on .NET pages.  It’s easy to put all functionality within the event handler.  It’s obvious what btnSubmit_Click does within the context of the control.

Given little to no context however, it’s difficult to review and make design decisions.  Having the general knowledge of the system, I don’t remember what btnSubmit_Click on page X vs. page Y does.  I may remember however, that page X  and page Y has a function called SaveUser.  Because of the duplicate functionality, it’s obvious that both page X and page Y should share the same SaveUser function and its functionality should be pulled outside of the view tier.

Comment frequently but don’t write a novel. I feel that young developers, especially those who went to school, are beaten over the head about creating a lot of comments.  I think this is much better than no comments.  However, it misses the point.  The BEST form of commenting is to program your code to be self commenting.  This means that variable names must be clear and concise,  the flow must make sense and be as simple as possible and the code formatting must be consistent and standard.  This is FAR better than a ton of comments.  As a reviewer, it’s more important for me to read the code than the comments so I can make better suggestions.

If it feels wrong, it probably is.  Go get it reviewed.  Sometimes you write code which just doesn’t feel right.  You are probably right to feel that way and something just isn’t right.  Get your code reviewed before it goes into QA or even into production.  However, come to the review with a description as to why you chose your approach.