4 Reasons I don't like code walk-throughs

  June 08, 2009

The code "walk-through" is the most common kind of code review.  Whether it's really informal with a reviewer hovering over the author's shoulder or a walk-through meeting with several people and a projector, a "walk-through" is when the author runs through his changes and gets feedback from others.

I don't like walk-throughs.  Here's why.

1. No Context inside the Code

The next developer who has to understand or maintain the code won't have the benefit of the author walking him through it.  Too often reviewers accept what is told to them because it makes sense in the conversation, but the important information doesn't make it into the code.

2. Shallow

To understand complex code takes thought.  You have to look up related code in other files.  You have to run through possibilities of error-handling and thread synchronization.  When you're being walked through the code there's no time for finding the subtle problems -- exactly the ones that are hardest to find later.

Consider a bug fix in a simple method.  You see the fix in the walk-through and it's fine.  But what other code depends on this?  Does that code depend on the old behavior?  These are questions you can easily answer when you're looking at the code alone with your IDE, not in a meeting.

3. Driven

Too often the author drives the meeting, explaining why she did this and that.  Sometimes it's questioned, but often the participants are playing a matching game -- "Yup, the code matches what she said she did" -- rather than thinking deeply about the code.

4. Time

Meetings take more time than individual reviews.  It's also easy to get sidetracked on tangential discussions, although a good moderator can mitigate this problem.  A harder problem is scheduling meetings for people who are separated by many timezones.

Some concessions...

Walk-throughs can be a better forum for teaching new developers and generally sharing and learning from each other.  Instructive conversations happen in person that don't happen in lone reviews.

Sometimes it's nice to have multiple people in the room, especially when there's a domain expert plus a language expert plus a product guru.

Therefore, in the end I suggest examining the code alone (but you still have to communicate!) as the default mode, but at the same time don't prevent people from doing walk-throughs when they find it useful.