Can code reviews really change design?

The other day I wrote about effective code reviews. Once problem I've seen with check in reviews are that once the review take place it is common that one or two days of work have been put into the change so any comments on how the design of the code can be changed are typically too late once we reach a check in review. A bad design is usually changed but an OK design is rarely changed into a great design basically since the design is OK so both reviewer and author does not feel it is worth another day just to improve the design. So check in reviews are not the silver bullet for better designs. You have to do something else too.

On our team we have design reviews. A design review is something each developer calls out (just like a check in review is called out) and then the developer goes over a proposed design or a few test cases with another developer before he starts implementing things in code. These design reviews have proved to be valuable and has resulted in less design comments during check in reviews.

As of yet we have not tried pair programming which would replace both the design reviews and the check in reviews in a natural way.

Comments

• Anonymous
  January 29, 2009
  I suggest you read this link http://www.faqs.org/docs/artu/ch01s06.html#ftn.id2878872 with particular attention being paid to rules : 15 and 16...

• Anonymous
  January 29, 2009
  @anthony.tarlano: I don't know if your comment was ment as a suggestion to complement my text or as critisism because you think I don't use the rules you reference. Assuming the latter I can see how you misunderstood what I wrote when I wrote about design reviews. The design I'm talking about is not a complete detailed design that we will stick to. The design I'm talking about is the gathering of ideas on how to implement a certain feature. The design review will happen after any prototyping in order to under stand the problem. All in all I think all the principles descibed in your link are things you should keep in mind when developing software but that does not stand as opposed to design and design reviews since the design does not have to be complete and detailed. I realize I should have made that much more clear when writing the initial post so here it is: By "design review" in this text I mean the review of an idea/strategy on how to solve a specific problem.

• Anonymous
  January 29, 2009
  And one more thing... Rule 16 "Rule of Diversity: Distrust all claims for “one true way”." is pretty much used all the time with "design reviews" since you then have to discuss a solution before you start implementing. So I'm a little confused about what you want to say with your comment...