When a new approach is suggested that will impact a team, one of the first things I was taught to consider is: "How am I going to socialize that idea?" That phrase bends the meaning of socialize, but only by a bit; I like this definition from the American Heritage dictionary:
To convert or adapt to the needs of society.
What should I say/do to demonstrate that a new approach will work for my team? Instead of forcing a change, I would prefer to get buy-in up front. In order to do that, I need to show that the proposed change can fit my team and I need to have ready answers to their concerns.
When code review is added to an existing software development process, up-front buy-in is very important. Even if the workflow change is small, developers will rebel if they feel like it is being rammed down their throats. End result: team morale drops and the hoped-for improvement to software quality does not happen.
But it does not have to be that way! Code review has been successfully implemented by hundreds of software development teams and in addition to improving code quality, if done correctly it improves team morale. The key to success is to anticipate the social effects and prepare to address them.
- "It’s too much hassle and we hate meetings and paperwork." This is a common complaint and its origin is the old heavyweight processes that were associated with code review. The solution is simple: use a modern tool-assisted approach to code review. No meetings, no paperwork, and no time wasted.
- "Code review will ruin our team culture. Some people will be jerks about code review and use the opportunity to terrorize others." When the right attitudes are set up front, most teams unite around the concept of becoming a better team, learning from others to become better developers, and producing better products. Code review almost always brings teams together because it gives developers a framework for communication. Once developers start communicating online, they frequently work better in person too.
- "I don’t like to be criticized." Feedback does not have to be critical or viewed as such; it is an opportunity to learn and improve. The trick is to make sure code review suggestions are phrased in a positive tone instead of a critical one.
- "We don’t want to change our process." Code review does not necessarily mean a change in process – it can fit into any existing process. But the proof is in the pudding – try it for just one week and then count up the number of bugs found and compare that to the time spent so the team can see the payback. A trial period provides more time for buy-in.
- "Code review takes time we don’t have, and we’ll miss our deadline!" If you barely have time to do it the first time, you definitely don’t have time to go back and do it again later! Finding and fixing a bug in review is much faster than waiting until it is reported by QA or a customer. A compromise would be to just review the highest-risk portion of the code.
- "Big Brother is now watching and grading me on my defects!" Defect metrics are not a useful tool for evaluating a software developer, so make it clear that they will never be used that way. The goal is to review the code, not the coder.
Most software developers already know that code review improves code quality. But they are frequently surprised to learn that it can also improve team morale. Implementing the tips above leads to an environment where developers work together, learn from each other, and pick up momentum as product quality and their own development skills improve.
This is the first entry in a three-part series. In part two I will provide some tips for development managers. 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.