Make your code reviews Agile

When discussing dealing with technical debt, fragile and buggy code base, and improving quality of the technical community, code reviews are a popular suggestion. Code reviews sound wonderful in theory: a junior or simply not-so-good programmer presents his work for review to an experienced grander-than-thou colleague, receives excellent suggestions within one hour, and another hour later all suggestions are implemented and the code transforms from nasty to near-perfect.

Enter reality. Thorough review of non-trivial code takes a long time. It is becoming increasingly harder to do a quality review as the time needed for the review increases. The pressure to provide a quality review suggests that more time is needed, and more time spent in review leads to poorer reviews, creating a downward spiral leading to deadlock.

Team dynamics are also affected. Giving a small number of reviewers the authority to dictate changes in work they are barely familiar with, without much feedback on the outcome of those changes, reinforces the bad habits of the reviewers and further entrenches their biases into the codebase. People required to accept suggestions without a possibility of challenge or feedback soon start to despise the reviews, the reviewers, and the suggestions. Neither reviewers nor authors feel responsible for the quality of the end results: reviewers because they only spent a little time reviewing, and authors because they were forced to make changes against their judgement.

So, are code reviews doomed to fail?

For code reviews to be a successful code-quality tool, consider an Agile approach. Make code reviews small and nimble, and have the entire team in charge of making, accepting and implementing generated suggestions.

That means everybody reviews everybody else’s code, in tiny little chunks. No formal meeting should be required. Everybody is invited and encouraged to generate improvement suggestions on all other team member’s work – and expected to defend their ideas. There is no separation of roles into those who critique, and those who are being critiqued. All team members are required to ask for and work with peer feedback.