Thank you for great post. I agree 100%

Fair points Jason, no doubt there is some value in a middle ground. I’m obviously describing what seems to work well in my experience, as are we all, I guess.

Best regards,

You make good points about how code reviews can be inferior to pair programming, but I think a few counter-points are in order as well.

1. “Code reviews require a lengthy feedback cycle.” I agree that if it takes you 2 days to get a code review back, the developer (and t he code?) has moved on and it’s harder. But there’s no reason code reviews have to be delayed that much when everyone is in the same timezone.

At Smart Bear we do multiple code reviews per day, typically while we’re waiting for a code review of our own. Reviews rarely last as long as a day, and if it does gum up you just assign the review to someone else.

2. “Code reviews are intrinsically confrontational.” This depends on the attitude of your developers, not on the code review process.

Are you telling me that having someone whispering in my ear every time I make a mistake isn’t confrontational? Or could lead to anxiety or social problems? It could — or not — depending on the attitude of the participants.

3. & 4. “Code reviews are hard to do well and can be boring.” I think these points could equally be applied to pairs. You get tired of pointing out the nits. You get bored while someone keys in boilerplate code so you drift off or do email.

Or, during boilerplate time (or just simple code) are you wasting your time as a pair?

In summary, I don’t see how anyone can deny that in the “getting someone up to speed” category — the main subject of the blog post — pair programming is best.

But once you have programmers who know what they’re doing, perhaps code reviews take 10% of the time and, say, 50% of the effectiveness. That could be a good trade.

misko, the point is, it has been measured and you didn’t even bother to look, even worse you crap out anecdotal evidence and act like this is some defense.