Peer code reviews are well recognized for their benefits. Among them include:
Many highly functional teams incorporate code reviews into their standard processes, and developers tend to expect them more often than not when working together.
But sometimes maintaining the elements of code review which contribute to velocity – “Review-ocity” – can be tough. Some teams may even start to approach “Review-itis”, where the pains and stiffness associated with pull requests start interfering with their agile flexibility.
“All the code for this iteration is done, we’re just getting it all through review.”
“Well, once this gets through review we’re going to have to deal with all the merge conflicts.”
A touch of “Review-itis” isn’t completely unexpected and can be relatively easily addressed. It does pop up now and again (for healthy reasons) and can even be seen as a good leading-edge indicator for some team improvements which might otherwise not be caught until much later when harder to address trailing-edge symptoms occur.
Over time, change happens. More features, more code, a little bit of siloing, team members change, some team members are a little more familiar with certain bits of code than others, and perhaps the team is starting to apply some lessons learned and reduce technical debt or increase maintainability or flexibility and bam … some “Review-itis” kicks in.
“How do we handle a ticket across iteration boundaries which is just awaiting review?”
(In Retro) What Didn’t Go Well – Code Reviews
But those might be on the horizon.
If these symptoms aren’t addressed, they can start to become more problematic. Technical debt and siloing continues unchecked, cross-functionality starts to wane, and pretty soon wam … you’ve got a full blown Stabilization Sprint or even those oh-so-enjoyable Spike vs. Refactor conversations. So celebrate that opportunity to address a little “Review-itis” before the really nasty symptoms kick in!
The below assumes valuing collective or shared code ownership over a code stewardship model. It also assumes that reviews are encouraged across boundaries, that reviews aren’t merely a mentoring exercise or a procedural check box, and that everyone participates in the process. If any of the above do not apply, some of these might be differently (or even less) applicable.
“Whoever first sees the pull request just go ahead and click Merge”
“Let’s pause for a while and figure out a complete fool-proof set of processes, standards, and checklists”
Nope, we want to get the ball meaningfully rolling. With the above caveats, here’s a few simple steps and questions which may help your team maintain its “Review-ocity” … and avoid “Review-itis”.
What tickets are in code review right now? How many are there? How long does it take on average for code review? What visibility is there for pull requests in review? Chances are you already track “To Do”, “In Progress”, and “Done” (or some equivalent thereof). Perhaps you’ve also added “In QA”. Many teams dislike the proverbial 16 step workflow which gets a ticket from “To Do” to “UAT Test” to “Reopened” and so on, so there is sometimes a reluctance to add additional ticket statuses. But in this case, it does help.
Pro tip: This can sometimes be difficult if you issue multiple pull requests against the same ticket. Break those stories into subtasks and issue a pull request per subtask.
The first thing you did before starting a new ticket was look over the existing ones awaiting review, right? Those 5 pull requests aren’t just going to review themselves, perhaps we can look at them after standup? This often flows naturally from the first tip. Once “In Review” is a status, seeing the outstanding pull requests on the board or in Standup usually happens automatically as a consequence. But, as a starting point some teams skip the status and just look over the open pull requests in their Source Code Control (SCC) of choice together on a daily basis.
Are you always doing code reviews solo, perhaps entirely by commenting in your collaboration tools or SCC of choice? Alternatively, are all code reviews done together as part of a desk check or other face-to-face setting? Mix it up! Get on a screen-sharing tool and do some reviews together. Or, utilize some heads-down time to enter a few comments solo without the rest of your team. It’s human nature, sometimes we get in a bit of a rut. Always be open to new ideas and methods, you might just learn a thing or two.
Pro tip: Always be on the lookout for methods that apply to multiple techniques. If you’re doing a code review in a group setting, enter in comments and treat it as a learning moment for when you don’t have that luxury. Teammates who missed the meeting (or have to look at the code tomorrow) will thank you. Conversely, there are times when screen-shots, drawing tools and the like can help to convey meaning when whiteboards, a scribble pad, or hand-waving aren’t available.
Really, you can do that? How in the world? Huh, what? Honestly, this tends to flow naturally from mixing up review techniques. Seeing the tools that other team members use, and how they use them, can sometimes be incredibly helpful. Share these tips and tricks frequently. From tags and labels, to markdown, to templates, to integration between your various tools, there are almost certainly capabilities you have in your development environment to optimize code reviews which you’re not even aware of (yet). Find them, try them, use them if helpful, and always share what you learn with your team.
Is a code review really the place to address this? Is there back and forth to the point where immovable force has met irresistible object? Is QA waiting to test something … anything? Code review might not be the right place for an ongoing conversation. The alternative to having to create all your standards and checklists all up front and having to enumerate simple things which everyone on your team already knows … is to build those standards up slowly over time and only having to address the areas where there are differing opinions. “Please consider adding a standard for this to our wiki,” “Please consider adding a technical debt ticket for this,” or even “Please feel free to refactor if you feel appropriate” sometimes are helpful if consensus isn’t quickly reached.
Pro tip: For these cases, it is important that the team have an agreed upon process to address the punt. Doing so once for a given issue is understandable. Doing so repeatedly, however, can lead to some unhealthy team dynamics.
Yes, there are several ways to improve code reviews via softer people skills and collaboration techniques. For example, small frequent pull requests with context are usually easier to review. Avoiding conversation killers which shut down feedback or invalidate others can be helpful not only on reviews, but in all team rituals. Perhaps some day there will be a perfect code review language along the lines of I can can I me to me to me to. But these skills sometimes take a bit longer to master.
If you’re seeing some symptoms of “Review-itis” today, now … try one (or more) of the above and see if you can bring back that “Review-ocity”! Don’t let a tough iteration slow you down. Peer code reviews are rightly praised for their many benefits, make sure they are recognized in your team.