Understanding the Experience of Code Review
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Understanding the Experience of Code Review: Misalignments, Attention, and Units of Analysis , a paper by researchers at Lund University in Sweden that identifies common problems that frustrate developers in the code review process. Leaders may find this paper helpful to spark discussions and identify ways to improve the code review process within their teams.?
My summary of the paper
Modern code review (which is defined as “tool-supported” code review) has been found to have a positive impact on software quality. However, the process requires a lot of effort and is not always effective. While previous work has explored different reasons why the code review process may at times be ineffective, the researchers here sought to understand the experience of code review from the developers’ perspective.?
The researchers conducted a mixed-methods study at two multinational companies. They started with a series of semi-structured interviews to learn about the developers’ experience of code review, and then analyzed the themes that surfaced. Then, they conducted a follow-up survey to understand the prevalence of certain obstacles in the code review process.?
Here’s what the study found:
Misalignments in the code review process
After conducting interviews, the researchers categorized the different types of misalignments they surfaced into two high-level themes: misalignments between the tool and the review task, and misalignments from the process. They used a follow-up survey to better understand the prevalence of these problems.
Here are some of the common misalignments the researchers identified in the code review process:?
Process-related misalignments refers to situations where processes don’t fully support the task of a reviewer.?
Tool-related misalignments refer to situations where the code review tool doesn’t fully support the intended task of the reviewer. On average, developers experience tool-task misalignment every fourth code review.?
Final thoughts
Most advice for leaders looking to improve their team’s code review process centers around improving the reviews themselves, by way of checklists or tips for reviewers to give feedback more appropriately. These are all useful, but I appreciate that this paper provides a different perspective. It looks at problems with the processes and tools involved that are either hampering—or at least not fully supporting—the tasks involved in code review. Leaders may use this paper as a starting point to learn whether these problems exist in their teams’ review process.?
That’s it for this week! If you’re interested in more research, send me a connection request or message on LinkedIn with the note “research” and I’ll share a downloadable bundle of my top 10 favorite papers of this year.
I dont like code reviews. I prefere not to use it and use instead code management strategies.
Senior Software Engineer @ Mollie | Extreme Programmer | I Help Software Engineering Teams to Excel
1 年Been introducing pairing and mobbing in the team. Pairing is slowly but steadily becoming the norm. Mobbing wise we have a 2h session every week. I've been observing increased efficiency and effectiveness in delivering value. The team is enjoying it a lot and everybody has a collective ownership of the project. Needless to say, when working in pair/mob we remove any delay in the code review process. As with other engineering practices, it takes time to adapt and develop the discipline, but once mastered you won't get back.
ADAS/AD Software, Solution and Developer Experience Architect
1 年And last but not least, asynchronous code reviews are an effective way to handle software development inside cross-time-zone teams.
ADAS/AD Software, Solution and Developer Experience Architect
1 年Very interesting post and insightful comments. I can relate to the friction caused by either type of reviews (synchronous, asynchronous). I tend, though, to favor asynchronous reviews - at least when the changes go past a few lines: - Discovering and analyzing code on one's own offers a new perspective on the code, thus favoring the discovery of possible flaws or optimizations (of the design, of the algorithm, of the code), a process which might be impeded when the author presents, and especially leads through the review. - A good marker for an appropriate amount of documentation and code cleanliness is whether the code can be understood on its own, without additional guidance through the author. An asynchronous review is a good test for that aspect. - Asynchronous reviews require more time, but offer on the plus side a deeper analysis time. When being asked for an order of magnitude for the various software engineering phases, I answer with this rule of thumb: implementation time = testing time = review time. Code review is not a necessary evil that can be banged out at the end of the sprint, it's an integral part of the software creation and should be allotted an explicit and sufficient amount of effort.