Benjamin Hysell – Software, Projects, and People Rotating Header Image

coding

Breaking Down the Game Film – Micro Code Reviews

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Micro Code Reviews

Article: “The Joy of Code Reviews”

Author: Tom Hollander

Link: http://blogs.msdn.com/tomholl/archive/2009/01/06/the-joy-of-code-reviews.aspx

Short Summary:  Full code reviews are done too infrequently, and take too much time to complete to be done with any real regularity.  Micro code reviews, performed before every check-in, provide you and your project all the benefits of a full fledged code review, but also facilitate knowledge transfer between team members, an avenue to provide mentoring, and a chance for your team to “show off” to one another that cool new algorithm they have been working on.  All in 15 minutes or less!

Analysis:

When was the last time you reviewed the whole codebase for your project?  Stem to stern?  I know, I know, who has the time.  Everyday the codebase gets larger and larger, and each one of your team members becomes more and more specialized in whatever it is they are working on day in and day out.  What happens if one day George walks in and goes, “I’m off to Alaska to follow my one true calling.  Being a software developer is nice and all but I wanted to be… a lumberjack!”

::Deep down you know he’s a lumberjack, and he’s ok.  He likely will sleep all night and work all day, but I digress…::

George is gone.  When was the last time anyone was looking at his code?  Who on your team knows how his really cool, yet very complex, algorithm runs?  Sure it all works, but who last put eyes on his code to try to and understand it?

If I know your team, and I likely don’t, but I’ll assume I know them, no one has looked at his work in a while.  Why would they?  George’s code worked, all of his tests passed, who has the time to review working code?

Your project has just suffered a major brain drain, and you don’t have a plan on how to recover quickly.

Tom’s article, “The Joy of Code Reviews”, provides some great reasons for you and your team to adopt what I’ll call micro code reviews.  A micro code review works like this:

  • Before every check-in to source control George grabs a fellow team member, Stan, and they review all the changes that are about to be committed to source control.
  • In Tom’s article he states these reviews often last 15 minutes, some much shorter, some a little longer.  Fifteen minutes seems just about right for a couple of programmers to review a bug fix or feature enhancement and has been the typical amount of time my team and I have taken for our own micro code reviews.
  • After George and Stan have reviewed the code, ensured the unit tests pass, and then check the code into source control.

Pretty simple and straight forward; spend 15 minutes before every check-in, or 30 minutes billed to your whole project, to get a second set of eyes on the code that is getting into your source tree.  On top of that:

  • In his article Tom calls out one of the great benefits in doing these reviews is the mentoring that can take place between two developers.  George has a chance to show Stan the new functionality he has implemented and possibly a new way to write code, debug, or write tests.  As Stan is exposed to George’s style he may pick up a tip or trick just watching him work.
  • I’ve personally seen George improve his ability to explain complex thoughts and algorithms to Stan.  Oftentimes we work in isolation, only explaining things to ourselves.  By sharing with Stan and forcing himself to verbally explain things George has a chance to work on his presentation skills as he breaks down a complex problem to Stan.
  • Micro code reviews provide a chance for a team to feel more like a team as they work directly with one another.  I feel my team has gelled together a little more with these mini interactions that take place during these micro code reviews.
  • One might think developers would be resistant to these micro code reviews, however I found when I argued one could “show off” that cool new thing they did everyone seemed to get on board after doing a few code reviews.  Software developers love to have the admiration of their peers, give them a stage and most of them will step up and gladly perform.

I’ve adopted micro code reviews for my team and have had some excellent results.  Team members are grabbing one another when before new code is committed to the system.  Spirited debate takes place between the developers while reviewing the code, and learning is going on as each one learns from one another.  For us it has been a huge win win.

So when George answers his primal calling to be a lumberjack…

:: He cuts down trees.

He eats his lunch.

He goes to the lavatory.

On Wednesdays he goes shopping

And has buttered scones for tea.

I’m done, I’m done, I swear.  No more Monty Python for this post…::

You and your project will be prepared.

Tools in the Toolbox – Source Control

“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.

You use source control, right?

Good, I’m not going into the benefits of using source control, it should be a no brainer in this day in age.

No, you don’t use a system to back up every revision you make to your code?

Ok, here’s what you are going to do.

  1. Finish reading this blog post and then never come back to my blog again.
  2. Close your browser
  3. Uninstall all of your development tools and never write another line of code.

I’m not kidding.  If you are not using some form of source control for your daily coding activites I’m not sure we can be friends any more.  I mean, before I learned this about you I thought of us as at least friendly, but this is a deal breaker.

All snarkiness aside, source control is one of those fundamental tools like a hammer or screwdriver that needs to be in your toolbox.  Having a system that allows one to go back in time and see every change that has ever been made to a piece of code is invaluable.

Are you telling me you wouldn’t want to time travel back in time given a chance?  I’m offering you that opportunity to do so without the need of a DeLorean or a Flux capacitor.  You would turn down time travel?  Sir, I must say good day.

Won’t stop reading eh?  Maybe there is hope for you yet…let’s look at two scenerios, one with source control and one without.

It is 10pm, you should have been home hours ago.  Diner is cold, wife is mad.  You are in the office, your hard drive died at 4 this afternoon.  You have lost all of your code for your presentation you are going to give tomorrow, and you are only half way done recreating all of that code.  You have a long night ahead of you.

Try that same situation, but this time you and I are still friends because you use source control.

It is 5 pm and you are sitting down for a nice meal with the family.  You had a rough day in the office, your hard drive died right around 4 pm right after you put the finishing touches on your presentation you are giving tomorrow.  Since you use source control you have copies of all of your code in a repository on a seperate server.  You contact your IT guy, grab a spare laptop, connect to the source control server and pull down all of the code you have been working on.  You check it over, its all there.  A minor emergency before your presentation, but luckily you have avoided a full night of rewriting all of your code, and can go home and relax.  Thank goodness for a good source control system

Contrived?  Yes, but still proving the point of having copies of your work in a system off of your main development computer will avoid disaster.  Sure, you could have avoided this scenerio if you just stored a copy of your code on a thumb drive or a network drive, but then you would lose all of the benefits a source control system brings to your development environment, each done with only a few clicks:

  • One click check in process – Most systems now a days integrate directly into your IDE.  With a few clicks a copy of your code is placed into the system.  Total time, five seconds, max.
  • One click get the latest copy – When working on a team often times people make changes you’ll have to get a copy of.  Instead of bothering them you can normally right click on your project and select ‘Get latest’ to pull down the latest copy of all of the code stored in the system.
  • Compare – Allows you to take the copy of the code you are working on and compare it to the code that is sitting in the source control system for changes.  Did you accidentally erase a key section of code and then re-save your code?  Compare it and pull back that key piece of code.
  • Merge – Are you working on the same piece of code your buddy is working on?  Who has chnaged what?  One click and the source control system can help you merge his changes with yours.
  • Shelve – Are you working on a cool new feature only to have an emergancy bug crop up that needs addressing ASAP?  Take your code and put it on a shelf in the source control system.  Shelving code takes a snap shot of your current code and places it in a special area allowing you to go get a new copy of your code from the repository, fix the bug, check in the changes, and then go and get the code you were working on, apply the changes, and then continue on your merry way, saving time and energy.
  • View older copies of your code – This is the “Back in Time” scenairo, you need to see changes made last month to a key algorithm, with a source control system you can go back and grab those changes since you are saving a copy of every change ever made this isn’t an issue.

I use source control for everything I write, code or otherwise.  Every document I write for this blog is backed up in a source control system.

For the sake of our friendship, please go and grab something, anything to put your code into.  I am a huge fan of Team Foundation Server from Microsoft, but SVN has been growing on me.  There is a huge list of systems out there, pros and cons, if you Google for them.

Take a hour, download a source control system, set it up, and move all of your code into it.  You might not thank me today, or tomorrow, or the next, or even late next year.  Some day, some day in the future, you are going to rely on that source control system and you will be thankful you have it.

Understanding the Wheel

I hate reinventing the wheel.

The phrase ‘reinventing the wheel’ is tossed around in software development, as it likely is in other professions, to signify you are probably doing something someone else has already done.  Moreover, others who have solved your problem have hopefully had a chance to iterate on the solution several times to find an optimal answer.

With all this time and effort invested by others why bother trying to duplicate all that effort?  After all, others have already solved your issue, no sense trying to out do them, is there?

Like all issues, reinventing the wheel in software development is not so black and white.

Jeff Atwood wrote about not reinventing the wheel unless you intend to learn more about it: http://www.codinghorror.com/blog/archives/001145.html

Joel Spolsky wrote a few years back that reinventing the wheel is a very good thing if that wheel happens to run your business: http://www.joelonsoftware.com/articles/fog0000000007.html

It is these two key points that will hopefully dictate when you as a software developer decide to break out the case of Mountain Dew and start coding your problem from scratch or to pull a code snippet off of http://stackoverflow.com/ and plug it into your production code.

I am a huge proponent of not reinventing the wheel.  I used to expound to my developers constantly that I am a very lazy programmer.  Why should I spend the time and effort to code something up from scratch if someone has already done all of the legwork?

What isn’t normally fully communicated to someone when I say, “be lazy and don’t reinvent the wheel,” is you have to understand the wheel to know that you are reinventing it.  This is the point Jeff makes at the very bottom of his article, http://www.codinghorror.com/blog/archives/001145.html:

If anything, “Don’t Reinvent The Wheel” should be used as a call to arms for deeply educating yourself about all the existing solutions — not as a bludgeoning tool to undermine those who legitimately want to build something better or improve on what’s already out there.  In my experience, sadly, it’s much more the latter than the former.

I get to be lazy, reuse my old code, and not reinvent the wheel because I understand the wheel I am about to not reinvent.

I have done a bit of legwork myself to understand the piece of code I am about to plug into my system before choosing to plug it in.  I have done some research on the forms to see how others are tackling the same problems I have, and I have done some testing to ensure what I am about to use is going to work.  With all of this legwork under my belt hopefully the next time I encounter a similar problem I won’t have to work so hard for a solution, in effect be a little lazy and modify or tweak an already existing solution to use in a new problem.

It is with this experience that one can become truly effective at producing robust software, learn from the past, and not treat every problem by starting with a blank sheet of paper.

However, one also needs to be smart enough to know when to break out a blank project in your IDE and start from scratch.  As Joel points out in his article, if the piece of code you are about to borrow is a key piece of your product, and this code is going to differentiate your product from your competition you might want to get to know the ins and outs of that code yourself.

What do you do in your software or business that sets you apart from everyone else?  Whatever that is, don’t outsource it or borrow it from others!  If you do you are at the mercy of others for what you are claiming is your advantage.

Joel gives several examples in his article of items not to outsource those items are the cornerstone of your business.  One more recent example Joel did not reference was Zappos.

Zappos sells shoes online.  That is their whole business, online shoes.  Not special fancy shoes you couldn’t buy a hundred different places, just normal run of the mill shoes.

Yet, they are one of the more successful companies operating today on the Internet.

http://www.inc.com/magazine/20090501/the-zappos-way-of-managing_Printer_Friendly.html

Zappos prides themselves on their customer service and quick and speedy order fulfillment.  Guess what are the two things they don’t outsource?  The one part they can’t outsource, the actual delivery of the shoes to your door, they compensate by paying out of their pocket for overnight delivery on most orders to give the end user the allusion of faster than normal service and fulfillment.  Zappos has taken to heart the idea of what sets them apart from everyone else is customer service, and they do everything in their power to ‘reinvent the wheel’ when it comes to that.  They are reinventing the wheel to make a better wheel, a wheel more and more people are starting to use.

I leave you with these thoughts:

  • Don’t reinvent the wheel.
  • Understand the wheel well enough before making a judgment call to reinvent it or not.
  • If the wheel is the corner stone of your software/application/business, you had better be reinventing the heck out of that wheel.

Your Baby is Ugly

I’m not kidding, you have one ugly baby.

Its not your fault…well probably not your fault.

Did you drop him a lot in the first few weeks you brought him home?

No?

Hmm….

I’ve never personally had this conversation with anyone,

::Two points

  1. Yes, I’ve seen this done on Seinfeld…if you haven’t watched Seinfeld go grab a copy of the complete series.  It still holds up.
  2. I actually did see someone tell somebody their puppy wasn’t cute…so sort of in the same vein as telling someone their child is ugly.  Needless to say, “awkward” doesn’t being to describe the mood the conversation took on.

I digress…::

I’ve never seen anyone tell a parent their child is ugly, however, when it comes to creating software, I advocate telling people who write ugly code that yes, indeed, your code child is ugly.

First, for those of you who don’t design software and write code for a living a little background on the parent/child relationship people have with their software.

Software, like children, requires massive amounts of time and energy.  You, as a designer/architect/coder, conceive the code, often times starting with little more than a blank page.  From there, you outline the basic functions of your code, you test your code to make sure it meets specifications, and you clean up your code to ensure it follows all of the best practices dictated by your company.  Hopefully, in time, when your code is completed you can send it off to play with all of the other code in the system.  With any luck, you’ve written a good piece of software that is well behaved, has good manners, and is robust enough to function for many years to come with very little maintenance.

However, with all of the work that goes into the code sometimes it just turns out ugly.

What is ugly code?  Ugly can be described in so many ways…it could be:

  • Inefficient, taking way too long to perform simple tasks
  • Overly complex, possibly a piece of code performs a task in 50 lines where if someone took some time with the code and refactored it the same task could be performed in 10.
  • Incorrect, not producing the correct results.

This is by no means a complete list, but a small sample of items I have run into in my career.

Like anything anyone spends any amount of time with people often grow attached to their output.  With such an attachment people do not take kindly to having that output being called ugly, be it real life children or code ‘children’.

However, as I have said, it must be done…

To their code children, not their real life children…. geez you are a monster.  I’m not sure you should continue reading this blog…

If you can control yourself and your urges for calling kids ugly please continue, we have much to discuss.  Otherwise, I bid you good day.

How you tell someone they write ugly code is up to you.  I don’t advocate sending a company wide email letting everyone know that Johnson can’t write a for loop to save his life, and he would serve the betterment of mankind if he never touched another keyboard.  No, that’s just mean.

Nor would I post their code on the refrigerator and write a large ‘F’ on top of it with a red sharpie…although humorous, after sending that first company wide email Johnson may get the impression of not only do you think he is a horrible coder, but you might not like him either.

No, I’ll leave the delivery of the bad news to the parent of the ugly code up to your discretion, but something must be said, because lets face it, that ugly code child is going to grow up and become your whole team’s responsibility.

Failing to correct ugly code when it is first generated leads to all sorts of problems and heartache.  Firstly, for you, you will likely be the one on call when the code begins to fail in your company’s application, and it will be up to you to fix it at 3am on Christmas Eve.  You will be up all night attempting to track down the module that is failing, and once you find it you will attempt to get something working as quickly as possible, because every second the system is failing your company is losing money.

This is no way to conduct a career…working under the gun to fix a problem, hopefully you didn’t cause.  Especially if it could be avoided by telling the original designer they created one ugly child, and you, for one, do not want to support it when it starts misbehaving and throwing a temper-tantrum.

I recommend several steps in approaching and telling someone they have just written some ugly code:

  • Come out and say, ‘I’m not calling your code ugly, but we need to talk about how you implemented requirements x, y, and z.‘
  • Lay it on the table that there are concerns about the code, not the person who wrote the code.  Attempt to separate the parent from the child.
  • I suggest approaching this situation as a learning exercise.  Point out why you believe the code, although possibly technically correct, has room for improvement.
  • Make sure people know during this exercise this isn’t an indictment on their ability to program or create working algorithms, it just so happens this one isn’t up to snuff and needs some work.  The important point is to stress this isn’t personal and you hope to fix the code to avoid problems in the future.
  • Be able to back up your suggestions on how to fix the code with industry standards.  Share with the individual why you believe their approach isn’t quite correct and show how it is done everywhere else in the industry.  Even if you don’t have Johnson’s full respect it is very difficult to argue with how the rest of the world performs a task.

Lastly, put others at ease around you by inviting them to call your code ugly.  Separate yourself from what you have created and attempt to learn from their years of experience.  It’s the ability to take criticism and to learn from it that will help you grow in your career.