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

development

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.

Steve Yegge

After a little diversion I’m back into my digital reading list:

http://steve-yegge.blogspot.com/

I am not sure how to describe Steve Yegge.  I’ll start with some bullet points:

  • Lately, and sadly, he has been an infrequent blogger
  • Plug in your laptop before you start reading one his posts…you thought I had a few posts that went on and on and on and…I’ve got nothing on Steve
  • Bloody brilliant communicator
  • Insightful comments and vision regarding the industry we all work in

I don’t remember where I found Steve.  I forget if it was Joel’s Reddit feed or if I stumbled across him while on another software related blog, but every time he publishes I clear my calendar for the morning.

“Helen, hold all of my calls, Steve has posted again.”

:: Now, right this second, I don’t have a need for a secretary, and I’m not sure on the Helen part…maybe a Sally, or go another way, how about a Johnson.  I like Johnson, you can really let it rip from your gut…sounds manly.  ‘Johnson, (pause for effect)…Hold all of my calls’. ::

Steve is long winded.

“How long winded is he?”

Long.

However, those who embark and complete the journey will be pleasantly rewarded.

http://steve-yegge.blogspot.com/2008/10/programmers-view-of-universe-part-1.html

A couple of years ago I had a 55-gallon freshwater fish tank running in my living room, and I learned a few things from the experience.

  1. I’m not very good at keeping fish.  Towards the end of the experience every morning I awoke to a few less living fish and a few more dead fish.  Emotionally keeping fish can be very difficult.
  2. I never kept Bettas like Steve, but could relate to the heartbreak he had at the end of his post.  I think my algae eater died in the same fashion as his Betta.
  3. You can’t play catch with a fish…I confirmed through the experience of owning fish that I’m a dog person.

:: It didn’t take a tank full of fish to make me realize I was a dog person, but it’s always good to have confirmation. ::

Steve’s post is a classic post, referencing a non-industry related event to make a pointed statement about software and the world of computers.

Not all of his posts are downers.

http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html

Any post that references Godel, Escher, Bach: An Eternal Golden Braid is ok in my book…as Steve states:

Get yourself a copy and settle in for one of the most interesting, maddening, awe-inspiring and just plain fun books ever written. The Pulitzer Prize it won doesn’t nearly do it justice. It’s one of the greatest and most unique works of imagination of all time.

http://steve-yegge.blogspot.com/2008/09/bellic-school-of-management-training.html

I still haven’t completed the Niko Bellic management-training course.  I’m finding it harder and harder to fire up the Xbox 360 and devote the required hours needed for this management course.  One of these I will re-enroll…

Who turns an M-Rated Xbox 360 game into a post relating to management?  Steve Yegge.

http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html

How many times have you had an idea for something, anything?  You know the type of ideas, like the ones Ron Popeil puts up there in late night TV, but rather than creating the next ‘Pocket Fisherman‘ you want to write a complex software system to make your life and the lives of other people easier.

What if there was a website where tenants could pay for their rent with their credit card?

Seems like a good idea, property owners are paid immediately with recurring credit card payments, and tenants get points on their credit card when they pay rent.  I could use a system like this…dealing with checks every month is a major pain in the ass…I could build a system to do this.  I could do it in Ruby on Rails, play in a language I don’t use on a day-to-day basis.  I have server space…this could all come together.

Here is the rub…financial transaction systems are not my passion.  I would be writing something for me, but in an area I know very little about.  This is a case where I might use something like this if it existed, but to build, maintain, and support a system that I’m not passionate about is a recipe for failure.

Steve dives deep into the idea of building business for yourself, in areas you know, and you are passionate about.

http://blip.tv/file/319044/

This video ranks up there with my favorite web videos…his talk is titled “How to Ignore Marketing and Become Irrelevant in Two Easy Steps.”  Ever wonder how Verizon came to be the company they are today?  Steve Yegge answers all.