Lately, I have been thinking a lot about how to increase the value of reviews, with the goal of making reviews great again.
In a well-functioning team, I regard peer reviews of code and designs as key in making sure that the team’s deliveries are of high quality. Code reviews are also great for spreading knowledge within the team. This learning process goes two ways: the reviewer gives valuable feedback to the reviewee, thereby growing her into a better coder or designer. And the reviewee gives the reviewer new knowledge, through sharing her code. (Yes, reviewee is an actual word!) Therefore we might get just as much value from a junior programmer reviewing the code of a senior developer, as from the senior-reviewing-junior setup.
Hence, reviews are both a stamp of quality approval and an instrument of learning. Reviews grow both quality and people!
However, many teams have come to see The review as just a required step in the development process, a tollgate which has to be passed through before testing is begun. To me, this feels too much as waterfall. With such a mindset, the code review process may easily degenerate. Teams will hurry through reviews with the mindset of getting them done as fast as possible. Ultimately, the review may become a ceremony that adds no value. What started out as a way of ensuring code quality might end up as a cargo cult.
Instead of regarding The review as part of the development process, regard it as part of the coding process. When you are working with a user story, do not wait to send out review requests until you are ”done”. Instead, get your code reviewed continuously. If you continuously send the reviewer digestable chunks of code to review instead of insisting on reviewal of huge piles of code, she will have a much better chance of making a high-quality review.
One could of course argue that this type of code review is borderline pair programming, and that we should instead experiment with replacing our reviews with pair programming, if we find that the review process has failed. And that may be true. But still, for a distributed team where pair programming is hard or impossible, I believe continuous reviews can be a great tool, with the potential to maximize both delivered customer value and learning.
If do you go for continuous reviews and have a Sprint/Kanban board with a review column, I strongly advise that you remove this column. Remember, the review is not a step in the development process anymore. Instead, it is something that is done continuously as part of the coding.
Happy continuous reviewing!
