Understanding the Experience of Code Review

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.?

  • Process-completion was the top problem theme reported by developers. This refers to the problem where the expected time to review a task and the actual time for completing that task are misaligned. Both authors and reviewers feel frustrated when reviews take longer than they should.?
  • Another commonly reported problem: there is confusion about who is responsible for following up on comments within the review. In interviews, the researchers found that some developers described the responsibility as being up to the author, whereas others described it as being up to the reviewer. This finding connects to previous work which identified “organization of work” as a top challenge in the review process.?

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.?

  • In the study, researchers identified that the most common problem within tool-task misalignment is the problem of not having the information needed within a code review tool to complete a review. This causes the developer to leave the review environment and pull the change into their editing environment to find the information needed. This finding relates to previous work which has identified “code understanding” as a challenge in the review process.?
  • Another common problem that developers experience: the conversation needed for the review task is not supported by the code review tool. Sometimes the best path for moving a code review forward is to have a white board session or otherwise meet and talk through it. Code review tools typically do not support or facilitate these types of conversations. This finding relates to previous work which has identified offline discussions as a coping strategy to resolve communication issues in the review process.

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.

回复
Ruggero Enrico Visintin

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.

Roland Sarrazin

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.

Roland Sarrazin

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.

要查看或添加评论,请登录

Abi Noda的更多文章

  • Structured rollout boosts Copilot adoption and satisfaction by 20%

    Structured rollout boosts Copilot adoption and satisfaction by 20%

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    10 条评论
  • Platform vs. DevEx teams: What’s the difference?

    Platform vs. DevEx teams: What’s the difference?

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    10 条评论
  • 2024 DORA Report

    2024 DORA Report

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    61 条评论
  • What’s a good developer survey participation rate?

    What’s a good developer survey participation rate?

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    9 条评论
  • Why developers lose trust in AI tools

    Why developers lose trust in AI tools

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    5 条评论
  • Copilot productivity gains at a Fintech company with 2K+ engineers

    Copilot productivity gains at a Fintech company with 2K+ engineers

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    33 条评论
  • What three experiments tell us about Copilot’s impact on productivity

    What three experiments tell us about Copilot’s impact on productivity

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    25 条评论
  • Pfizer’s Future of Development

    Pfizer’s Future of Development

    This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class…

    8 条评论
  • How do developers want to use AI tools?

    How do developers want to use AI tools?

    This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer…

    15 条评论
  • Cognitive load drivers

    Cognitive load drivers

    This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer…

    6 条评论

社区洞察