What Software Design Can Learn From Lego
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.
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
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 art. In 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.
Windows Server 2008 install troubles
I wanted to re-purpose an old computer I built into a web server using Windows Server 2008. I got an error message saying "Required cd/dvd drive device driver is missing." I found it funny since I had to use the DVD driver to get to this point.
If you do a Google search on this topic, you will notice a lot of frustrated installers who have a similar problem and no solution. One solution I kept reading was to switch the DVD jumpers from master to slave. I wasn't expecting this to work, but to my surprise, I got to the cd key screen.
Hope this helps someone trying to install Windows!
TrueIfAll and TrueIfAny Functions for Javascript Arrays
I'm primarily a .NET programmer and therefore, I've become very familiar with LINQ. I recently needed a trueIfAny function on a few javascript arrays, much like the All<> and Any<> functions in LINQ. I am aware of LINQ to Javascript which does implement those functions, but I just needed something simple.
Fortunately, it's very easy to extend functionality of objects thanks to prototype. Here is the code I wrote to accomplish the task of creating a trueIfAll and trueIfAny function:
if (Array.prototype.trueIfAny == null) {
Array.prototype.trueIfAny = function (conditionCheck) {
for (var i = 0; i < this.length; i++) {
if (conditionCheck(this[i])) {
return true;
}
}
return false;
}
}
if (Array.prototype.trueIfAll == null) {
Array.prototype.trueIfAll = function (conditionCheck) {
for (var i = 0; i < this.length; i++) {
if (!conditionCheck(this[i])) {
return false;
}
}
return true;
}
}
And to use it:
if(myArr.trueIfAny(function(ele) { return ele.Toggle; }))
{
//Run if any records are true
}
if(myArr.trueIfAll(function(ele) { return ele.Toggle; }))
{
//Run if all records are true
}
The trueIfAll and trueIfAny functions iterate through the array, calling the passed in function (conditionCheck) each time. The passed in function accepts one parameter and needs to return boolean. The parameter is the element produced by the iteration.
In the case of trueIfAll, if the passed in function ever returns false, trueIfAll will return false. In the case of trueIfAny, if the passed in function ever returns true even once, trueIfAny returns true.
Hope this helps someone!
A Month Later — Self Employment
After one month of consulting, I am not much closer to figuring out what I want to be when I grow up. I am fairly confident I want to create my own company... not because I want to make millions of dollars, not because I want to be my own boss (although those are perks I wouldn't mind having) but because I truly believe I have the chops to do it. I consider me being self employed was a test, to see whether I would prevail or crash and burn under it all. So far, so good!
I feel like I have more creativity when working by myself, managing my own projects. I can work at my own pace, for how long I want, take as few or as many breaks as I want. I don't have anyone breathing down my neck about deadlines, I am not getting lost in a sea of politics, and day to day annoyances are minimal. It's nice to take a break from work to... work on a blog post! Lastly, it's nice to stay home and not bother with the ridiculous amount of snow we've gotten here on Long Island.
It's not like I don't have deadlines and sometimes, they take me to working a lot of nights and weekends. You have to really work on the relationship with your clients, because they are providing you with work so you can make money. If you are sick or just not into the day, you HAVE to make up that work... there's no sick days or vacations. You have to watch your money LIKE A HAWK... because you don't get a check every two weeks. You have to make sure your computer is working at all times; there's no IT department to replace your computer. Obviously, as with all important decisions in your life, there are a lot of huge pros and cons.
I decided to reflect on my success and my failures. As an aspiring leader/owner of a company, one thing you need to do is be positive but realistic. However, I've come up with a list of things that I've learned and accomplished unrelated to my profession in case this is all a really big failure:
- I've upgraded my home operation to be more secure and more backed up.
- I've learned how to manage my money better
- I've learned how to manage my time better
- I've become more organized
- I understand taxes a lot better
- I've learned how to express my opinion a lot better
- I've learned that sometimes the biggest failure you can have is the failure you didn't have.
I am generally honest with myself and would admit if this wasn't working for me. So far, I'm enjoying myself and recognize that over the next several months I need to make some big changes and advances. I hope I don't burn out and lose sight as to what I want to accomplish, even if that hasn't been truly defined yet.
Leading up to my full-time consulting gig
Here is a disclaimer: I wrote this for me, to congratulate myself on my accomplishments. Sometimes is just feels good to write out a pat on the back.
Ever since graduating college, I've wanted to run my own gig. I was looking into business school and wanted to focus on degrees which focused on entrepreneurial studies. I also knew that having more business experience was beneficial for me, so I looked for everything. Long story short, I got kind of the best of both worlds... I landed a job working with Brand Integrity on a project with just two other entrepreneurs. I learned a lot about building a company from the ground up, some of the difficulties start ups have, to work as efficiently as possible with the leanest budget as possible and most importantly perhaps, how to work in a coffee shop.
After three years, I decided to leave the location and move back home, because I was missing family and felt I could severely benefit from more experience. It was the hardest decision I've ever made. When I came to Long Island, Brand Integrity allowed me to work full time at home. I was able to find a job working for a larger firm with an actual IT department. I felt it was a necessary jump. I learned lots there, but something was missing...
After a short while, I realized where my passion was: helping clients solve IT problems. It's broad and almost impossible to do 100%, but that is what I wanted to do. Working at a larger firm made me realize that working without being on the ground floor of the decision makers was not what I wanted. I thought about project management training, but really, I just wanted to run my own consulting practice.
And that is where I am today. I am self-employed and loving it. Working for myself has unique challenges I must face every day which force me to be creative and efficient. I pray that I will have the strength and intelligence to keep this up for a long time.
Clients and Sandwiches
When I was a kid, I had a weird habit when I ate a sandwich. I used to disassemble the ingredients and eat each ingredient separately. My reasoning? It felt like more food, and I could enjoy the components I liked most, separately. I'm sure I wasn't the only child (maybe even adult) that deconstructed their sandwich on a regular basis. Was this unconventional consumption of a sandwich incorrect? Perhaps, but I still reached the same goal: consume the sandwich and remove the hunger I was feeling. It's hard to argue with little Matthew Doyle.
What does a quirky behavior like eating a sandwich have to do with clients, or anything for that matter? Clients and users use devices and websites in unintended ways. We as technical professionals may analyze a user's behavior and conclude "wow that's not right" and try to correct them. The user may be grateful for your help but also feel confused, frustrated and left with an attitude of "why did they feel the need to show me this? The way I am using my device works for me!"
Your professional opinion is correct. The user IS using the product in an unintended fashion. You have a better way, but you don't want to alienate your customer. What to do?
First things first, make sure those unintended uses do not cause unintended consequences.
You've personally tested your application billions of times, and there is NO way someone will break it. The first user comes along, does a few right clicks, a left click, several enter key strokes and he has managed to mess up your caching mechanism you tested. Always be on the lookout when you design and implement your project for potential pitfalls the user may encounter. Does your website work when a user opens into a new window? A new browser instance? When they bookmark? Unchecked paths can lead to a frustrating user experience, invalid data flow or breached security.
Next, make a decision on how to handle the unintended usage:
1. Do nothing for the customer or client, and follow your standards. The user has to conform.
This isn't always a bad answer. There are times when it's better to ask the user to conform. It's the cheapest approach and the one where you have the most control. You need to tread lightly when using this approach however, and you need to have solid reasons for your decision. Apple's locked down approval process for apps on their mobile devices is sometimes portrayed unreasonable and a little "big business" focused, they have voiced reasons for their decision and may be the answer to their great success.
Just remember this is generally a consumer unfriendly approach and expect some users to be disgruntled and not use your products.
2. Customer is always right. YOU have to conform.
Suppose you design cutting-edge websites with beautiful professional graphics, AJAX, interactive flash, the works. If you take a client in the non-profit industry, you have to understand most non-profits (not all) are a little behind the technology curve. They may be using older browsers and computers. Asking them to install the latest software may push their 6 year old computer to a grinding halt. Cutting-edge will simply not... well, cut it.
It's times like these which separates good professionals from great professionals. You need to figure out how to give the best product and service for your client with the tools necessary. If that means going easy on the glitter and really challenging yourself to work with what you have, then so be it.
As a side note, "The customer is always right" is an old and played out message. We need to update it.
"The customer/client always want to be treated with respect in getting to their goal." I like the sound of this better. The customer may not be right, but that's okay, as long as they get to their goal with the minimal stress and frustration. Work on helping your customers achieve their goals, and you should be successful.
3. Everything in between.
It's very hard to design a fully functional website that is flawless on every browser, device and resolution. In most cases, you need to do your homework. What are most of YOUR USERS going to use? Suppose 75% of your users use IE and have resolutions of 1024x768, your web site should probably work best in IE and at 1024x768. However, it should still be very usable in other major browsers, and look presentable in other resolutions --800x600 is not dead yet. If your user doesn't support javascript and your site requires it, it should at least politely tell the user to use a javascript-compatible browser. Even Gmail works without javascript and most big time websites which require it generally display a nice message.
In conclusion
You can guarantee one thing about users and clients: They will always be different from each other, and they will always surprise you. You need to have a keen sense of your users, and make sure their needs are met. If it's impractical or impossible to meet their needs, make sure your application at least lets them know of the alternative, and doesn't completely break when they use it.
Now, where is that slice of cheese from my sandwich?
Scott Pilgrim vs. the World: Quick Review
Scott Pilgrim vs. the World for those who don't know is a movie about a 23-year old played by Michael Cera who finds the girl of his dreams in his dreams and has to defeat her seven ex-boyfriends in order be with her. For more information on the synopsis, go to IMDB, because I am not going to do the explanation justice without ruining it.
This movie was a must see for me. Michael Cera is one of those actors whom I enjoy in just about anything he has done. The idea of a movie which borrows very heavily from a video game plot is refreshing and the production, while ridiculous, was necessary. Being a gamer myself, I didn't get insulted. There wasn't a moment where I felt the writers and producers have never played a video game before.
The production value was excellent. The fight scenes were well choreographed and the video game elements were great, and not too obvious. If you are not a big fan of fighting movies, there not enough fighting where you couldn't enjoy the movie.
The movie wasn't overly sexualized either. Video games sometimes tend to overdo it (impractical clothing for women and stupid "that's what she said" stereotypes for men for example). Anything 'sexy' between any characters felt necessary and important to the plot.
My only complaint about the movie is the ending. I am not going to spoil it (it's probably obvious from the synopsis what the conclusion is) but it seemed like it was wrapped up funny. Then again, it did remind me of some of those "awesome" retro video game endings. I am probably over-thinking it.
If you are in the mood to try something different, love Michael Cera or love video games, this is a must watch. For the rest of you, go check out the trailer, I think you'd enjoy it.
New happenings
Just figured I'd post quick since I haven't in a while and I wanted to 'touch base' with my blog:
- I have finally moved to Long Island and am working remotely full time. It's a weird experience, but not one I hate, at least not yet.
- The weather down here has been very nice, and where I am living is beautiful. I've also enjoyed watching the Mets both make me happy and break my heart.
- I am getting an iPad. Remember my previous post, Where's my iTablet? Yeah, I played with the gadget in the Apple store and was very impressed with it. Also, the announcements of the Courier and the Slate being canned basically made this decision pretty easy. I still want a pen, I still want something I can use next to my desk to jot quick scribbles down (and not with my finger) but I believe iPad experience will be awesome and I cannot wait until I get it. Apple wins, yet again.
- That personal website is on hiatus until I get a big chunk of time to work on it. I cannot wait until it's done however, it's my first Django application.
Keep It Simple!
It's getting closer to move date. My fiancée and I have created a large list of things we need to do before going. Change addresses, cancel utilities, and notify people we care about of our move.
While there's a lot of excitement, I cannot help but be a little overwhelmed. Every time I try to fix what should be a simple "hey, this is our new address" or "we need to cancel service x", we seem to be met with another task! I just want to cancel my service! I don't want to do homework! We tried getting a PO Box for to forward mail to two weeks ago, and we STILL do not have a resolution!
Then comes Time Warner Cable. I gave them a call, and ask them the process. "All you have to do is come in, drop your box, modem, remote and plugs off, give us a forwarding address and we will prorate your account and cancel it."
Wow. So you are telling me is my expectation is the reality? In amidst of all the hard work I have to do, Time Warner decided to help me out with a very simple, easy to understand process, AND give me back money for the time I don't use the service.
Simplicity is key in a world filled with complex problems and processes. By just keeping it simple, you can hold onto a customer, draw one in, or have one leave on good terms.