Code Review - How to miss the point...

Sometimes your arguments just don't weitght enough in the balance... 

I had the opportunity to "attempt" to contribute to Esther Schindler's article on Code Review.  She reached out on LinkedIn and I offerred help.  Now that I am reading her article I have many dissapointments.  Mostly related to not being able to make my contributions useful. 

Right from the get go I warned her about "meeting driven" code reviews.  These code review sessions where people each bring a tree's worth of paper and then beat the s**t out of the code worked on for a month.   They generally also spend a day reading a massive and scary amount of code before the meeting, a very costly process needless to say with limited output in general (at least from my experiences 10 yrs ago at Bell Northern Research and later at Nortel).

I could see from the other contributions she was provided with that this was the route she was about to embark when talking about code reviews.   Her article is filled with reference to "weekly review meeting"... or "meeting driven" code reviews. 

A couple good take aways are:

1. Jason Cohen from Smart Bear who is talking about a code review style that makes more sense, closer to what we believe in at Macadamian. 
   
2. Someone from Google who's is suggesting to do design review before you even consider doing code review. 

If I had to write that article I would put emphasis on what has helped us here to improve quality:

1. Small and frequent code review.  Get code reviewed on a daily basis.   This ensure you catch errors as soon as possible. 
2. Do design patch review - Just In Time Design - JITD (expression first heard from the mouth of Francis Baudet's sometime in the summer of 2008... ;-) )  This process, not only ensure that the first line of code will be a valid one, but also ensure that the deveopper starting the work took a step back and thought about the code to be written before to start writting it. 
3. Tools stack.  Do not neglect the use of proper tools to do the job, emailing a patch to each other works, but now a day there are very good tools out there.   

Last but not least, for code review to be effective you need:

1. this process to be part of your culture,
2. to foster an egoless programing environment, ensure understanding of the "what's in it for me" for your developpers,
3. to not only rely on this process to ensure quality.     

First and foremost, you need to not do code review once a weeek but have this process part of your complete breakfast.