So now, many of you are convinced that code review is valuable and would like to give it a try more seriously. Or perhaps, you succeeded in introducing code review in your team, but still struggle to get it adopted company-wide.
Let’s discuss such aspects of code review.
In the first installment I explained how code review relates to agile development practices, especially when you have distributed teams, changing personnel and the a need for cross-team coordination.
Ready to try adopting code review within your team or across your organisation? Read on.
Misconceptions
Firstly one needs to clearly understand what code review can and can’t do for your team.
Code review is not:
- A bug hunt: Code review won’t guarantee you’ve found all the bugs in your code, no matter how many people participate. Consider it another tool in your kit for making better software, along with automated and manual testing, static analysis, etc.
- A blame game: When you focus on finding deficiencies in people rather than the code, code review will quickly become hated and it will rather destroy your team than help it. Instead, focus on code reviews as an opportunity to learn, teach and improve your team’s collective performance.
Starting With Code Reviews
How do you convince decision makers in your organization to adopt code review? It depends. If they encourage improvements in collaboration, innovation, and continuous improvement for both your code and employees, then introducing code review will be easier (surprisingly it’s not any different than introducing common agile practices like unit testing, refactoring or pair-programming). If your decision makers aren’t as forward-thinking, you may still try to start inside your team – a bottom up approach. When a single team introduces some practice which boosts productivity, morale or product quality, sooner or later other people follow (including bosses who might take credit for their team’s improvements 😉 ).
Increase the chance
OK, you started. How to avoid failure with the adoption? Here are several ideas based on real-world experience:
- Keep it lightweight: Starting too much process and too many rules for code review almost guarantees failure due to push-back from the teams. Make the review process dead simple. No special rules, no pre-authorization, no designated decision makers, no formal reports.
- Don’t force it: Recognizing the value of code review by your team members can take time. They may have previous negative experiences with code review, so don’t be surprised by some resistance. Encourage reluctant developers to give code review another try, with a more lightweight, less time-consuming approach.
- Don’t micro-manage: Don’t force your team to review every changeset, nor to follow a rigid process during the code review. Remember: agile code review is mostly about knowledge sharing! All other things are good side-effects.
- Encourage asynchronous reviews: Code review meetings take your developers away from their work, breaks their flow and will be met with resistance. A better approach is to enable them to review code when it’s convenient, the same way they read email, RSS feeds, etc.
- Actively share interesting findings, constructs, design decisions via code review – be the champion: Build an easily accessible knowledge base from your code reviews.
- Treat code review as yet another state in your project workflow: Don’t wait for code review until the end of the iteration. Late code review is often worse than no code review at all – it’s often tool late to react to the findings. Instead, treat code review as one more step between ‘To Do’ and ‘Done’, so that it happens constantly throughout your iteration.
- Small and frequent over large and rare: We’ve found that it’s much easier to focus on code review when the code under review is relatively small and the changes are well-defined and reason behind them clearly visible (additional highlighting of the changeset diffs helps a lot). Continuous code review (the term I call it) share all the merits of continuous integration – you avoid late reverted code, misunderstanding, unexpected refactoring, hanging reviews for ages because they are to big and too time consuming and, most of all, skipping code review in the name of “more important tasks” at the end of the iteration.
- Concentrate on the code and conversation, not on the code review tool and its endless capabilities: Whatever tools you use to facilitate code review should be a means to the end of better communication and understanding (just like your email, IM and other communication tools).
- Do not include too many reviewers: The more people involved, the longer the review takes, and the greater the cost. In practice, we’ve found 2 – 4 people is enough to perform an effective code review. Increasing the number of participants results in diminishing returns. Considering that there are a limited number of hours in the development day, we’ve found it more effective to perform more reviews with fewer people involved in each than to have everyone involved in every review.
Measuring the value and adoption of code review …
… is not so easy. You cannot count on collecting reliable and meaningful metrics. Code review is a soft process, involving human beings – very sophisticated and unpredictable agents. Most of the metrics related to code review cannot be quickly and easily derived.
What are the immeasurable benefits? fewer bugs, less future rework and technical debt, improved team morale and cooperation, improved truck factor, and smoother integration between systems.
You cannot expect to derive meaningful metrics by just measuring the activity volume in code review (like number of comments, created reviews, issues found, time spent on reviewing the code, etc.). These simple metrics may however help measure the adoption (and cost) of code review. If you need metrics – go for it. But remember: you were warned!
I am sure you have some lessons learnt too and can share your advice. Please share your comments!
In the third and last instalment I am going to compare pair programming with code review and reveal a few best practices around code review that evolved at Atlassian.
“Fist” picture courtesy of tms. / CC BY-NC-ND 2.0
“Measuring Tape” picture courtesy of aussiegall / CC BY 2.0