Do you have a lot of code battles? Do you feel victorious when you make it through? Do you wish someone was there to witness it all? Some people do. If your one of those that do then you’ve probably heard of a code walkthrough. The question is - are they fit for purpose?

First of all, let’s give you a brief explanation of what a code walkthrough is. As the name suggests it’s when you explain your code by walking through each part (or line).

Walkthroughs are a good way of controlling quality in the code used by an organisation. Most businesses have a certain set of rules to follow when coding so that everyone can identify and write codes in a similar manner. After a program has been written a meeting is held where the programmer explains what they’ve coded. So you can imagine, everyone around a table, programmer standing next to a screen (smartboard) as if they’re about to give a presentation.

So now everyone is waiting for he’s awesome code explanations. The programmer will most likely show them a piece of code and then explain it to everyone so that when they come across it they don’t get flabbergasted by the complexity of it. Some people may give suggestions and offer better and more efficient ways to reduce lines and speed up the code. More often than not, everyone just accepts the code when there is good justification behind it.

Why they are bad
Code walkthroughs can be pointless if not done correctly. The main reason this can be the case is that in some situations the programmer will be justifying all his code whilst everyone takes it in and accepts it, what they should be doing is thinking deeply about the code. This may be hard when you’re trying to listen to the next part at the same time. It can also be shallow because understanding 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.

Another bad thing about this process is that the next person who may develop the code further won’t have the benefits of the initial programmer walking him through it. Too often everyone in the meeting room just accepts what they are told because it makes sense at the time, but the confusing or important comments don't make it into the code. Meetings take more time than lone reviews. It's also easy to get sidetracked on tangential discussions. Even though a good moderator can mitigate this problem it's hard to schedule a strict set time when people could be separated by different time zones and work hours.

I agree that walkthroughs can be a better forum for teaching new developers and generally sharing and learning from each other. Instructive conversations happen that don't happen during 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.

Many may argue that, in fact, code walkthroughs are counter productive and peer reviews and lone reviews should be used instead.