Tips for Managers: Social Effects of Code Review, Part 2

In part 1 of this series, I described the importance of getting up-front buy-in for adding code review to a team's existing process. The task of getting a team to embrace code review frequently ends up in the lap of the development manager, and if you're a manager, your most difficult job is probably dealing with your team's emotions and human interactions.

Those emotions and interactions are important because one of the most overlooked factors when doing code reviews is a positive outlook. When properly implemented, code reviews can be fun, light-hearted, and build team morale. But when your team is put on the defensive, you run the risk of developing bitter feelings amongst both the authors of the code and the reviewers.

To create an environment where positive emotions and interactions come from doing code reviews, the key to success is to set the correct tone. These tips can help you get started on the right foot:

• Explain to the team that you want them to find defects. The more the better. Each defect they find is another one that doesn’t clog up the QA pipeline, or worse, get into the customer’s hands.


• Make sure everyone (including yourself!) understands that code review is all about reviewing the code.  The goal is to review the code, not the person who wrote the code.


• Encourage team members to review different people’s code.  That way, everyone can get to know others and their styles.


• Never use metrics from code review as part of your team’s performance evaluations. Make it clear to the team that review statistics such as number of code defects will never be used in reviews of the person who wrote the code or the person who reviewed the code.


• Don't single people out. If someone is not approaching code review with the right attitude (e.g. bullying their coworkers or doing political jockeying), don’t single him or her out. Have a general discussion with the group instead.


• Insist that your team always review at least some code, and explain why. When developers know that their peers will be reviewing their code, they instantly become better developers. They don’t want their colleagues finding bone-headed mistakes, so they give their code a quick review themselves before checking it in. They even pay closer attention as they work – so you get better code before reviews even happen.

It's all in how you look at it - with the right approach, code review has extremely positive effects on teams and their personal interactions.

This is the second entry in a three-part series.  In part three I will provide some tips for developers. If you do not want to wait, however, check out this recently published white paper: Improve Quality and Morale: Tips for Managing the Social Effects of Code Review.

Comments

[Scott Sheppard]

I never use defect metrics from code reviews on people's annual performance reviews; hwoever, I do pay attention to the number of reviews people participate in so they get credit for spending time to help inmprove the work of others.