Within the Culture Amp development team, the Agile development technique we use most frequently is the humble code review. Whether it's a bug fix, a performance tweak, or the addition of a whole new feature, developers are expected to ensure their code is reviewed by the most appropriate team member before it is released.
“Appropriate” tends to be defined by who's available, and who has the most exposure to the area concerned. Importantly, everyone, regardless of experience level, should regularly play the role of reviewer.
Although regular code reviews are common practice among software developers, I believe the technique can and should be applied to other disciplines. To explain, let me first outline what I believe are the true benefits of such a review.
- Multiple eyes are searching for potential issues in each piece of code.
- It creates an opportunity for two-way learning. I’ve just as often found opportunities to learn from my peers whist conducting reviews as I have whilst receiving review feedback.
- Regular reviews facilitate conversations about how the team wants to handle particular situations and the pros and cons of particular approaches.
With regular reviews, the code base is far more likely to be consistent, and the greatest complexities are more likely to be understood by a larger number of developers. This is because developers involved in the review process feel a sense of collective ownership for the code base.
The process works because everyone in the team values it, and puts time and effort into ensuring it is effective. Sounds self-fulfilling? That's because it is! The real value is in short, iterative feedback loops, and in ensuring that the focus remains on collaboration, shared learning, and consistent approaches.
To implement an effective output review process takes three components - regularity, action and communication.
How useful would these reviews be if we did a big audit of the entire code base once a year? After several months had passed it would be very unclear who had written what, and the opportunities for learning along the way would have been lost. Not only that, the sheer volume of change means it would not be feasible to review everything, and it would be impossible to change everything!
What would happen if reviewers diligently examined the code, only to have their feedback completely ignored? It would not take long before reviewers stopped reviewing entirely.
3. Communication of results
Reviewing takes effort. Ensuring the benefits of the process are understood by all involved is important in ensuring that authors and reviewers alike buy into the next cycle.
It surprises me how often review processes outside the software development arena fall into exactly these traps: reviewing infrequently, changing little, and forgetting to communicate to others what the company has learned.
It doesn’t take much to embed review cycles into your regular work activities. The benefits are invaluable.