I currently feel like the odd one, out. It appears that many people are associating peer review in software with code reviews via pull requests. I don’t, on what side are you?
Even before I transitioned into leadership roles, where coding took on a secondary function, I did not engage in pull requests. In fact, I haven't submitted a pull request in a professional context since 2017.
Leads Horizons is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Let's delve into the nuances of the peer review process in this article.
Understanding Peer Review
Peer reviews, also commonly referred to as peer assessments, involve a rigorous and structured process whereby a professional's work or research is evaluated and critiqued by one or more individuals who possess similar competencies, educational background, and expertise. This concept and methodology of peer review originated and took root in the academic sphere, where it is routinely employed as a critical tool to appraise and judge the value of scholarly outputs and research findings.
The primary function of this system is to serve as a form of quality control, significantly bolstering the credibility, reliability, and overall accuracy of the work that is being reviewed. This is achieved by providing an additional level of scrutiny, thereby eliminating any potential errors or oversight that might have been missed by the original author.
Fundamentally, peer review is a cooperative and collaborative process. It is meticulously designed to enhance the quality of work produced, encourage continuous learning and improvement among professionals, and support the establishment and maintenance of objectivity. It ensures that the work produced adheres to the highest standards of excellence, providing an essential layer of accountability in professional settings.
Software Development Peer Reviews
Within software development, peer reviews often manifest as code reviews. This involves a developer scrutinizing a software project's source code to identify bugs, errors, or potential enhancements. It's about more than just pinpointing issues—it's also about understanding varied methodologies and learning from colleagues.
Types of Code Review
I want to emphasize this point, as it appears that the contemporary software development scene may not fully grasp it.
Code reviews aren't always synonymous with Pull Requests 🤯
Let's delve into the alternatives:
Kent Beck has offered a two-dimensional perspective on the types of peer reviews in his article. The two dimensions are:
Synchronicity: Refers to the timing of the review process. It can occur in real-time as the code is being written (synchronous) or after the author has completed the code (asynchronous).
Continuity: Considers the workflow in relation to the review process. It can either allow the author to continue working (non-Blocking), or require the author to pause until the review is completed (Blocking).
Let's explore what does each of this peer review means:
Formal Review: A formal review is a thorough and systematic evaluation of a project, product, or performance. It is often conducted by a group of qualified individuals and follows a specific procedure or set of criteria.
Pull Request: A Pull Request is a feature in version control systems, like Git, where a developer proposes changes to a codebase. The request is a way to communicate the changes to the team and ask for review and integration into the main code branch. This technique was created for 0 - trust environments where people don’t know each other.
Over The Shoulder Review: This is an informal method of code review where one developer looks over the author's shoulder as the latter walks through the code.
Code Comments: In this approach, developers annotate the source code with comments. These comments offer insights, point out potential issues, and suggest improvements.
Pair Programming: This is a method where two programmers work simultaneously at one workstation. The “driver” writes the code, while the “observer” reviews each line of code as it's being written.
The Relation Between Feedback Cycle & Waste
Inherent to the process of peer reviewing is its role as a “quality” gate. As such, many these processes tend to fall into the blocking quadrant of operational procedures. This characteristic of peer reviews can create situations where individuals become idle, waiting for the process to be unblocked. This idle time is not only detrimental to productivity, but can also affect morale and engagement among team members if they span over time. Therefore, it is important to streamline the feedback cycle to minimize these idle periods and maintain efficient workflow dynamics.
In addition, the involvement of a second individual to review the work is also necessary for any type of peer review process. Implying that the longer the feedback cycle between the generation of code and its review, leads to an increase in waste and rework. This is due to the fact that the longer the delay in feedback, the greater the potential for the initial work to diverge from the optimal path, necessitating more significant changes and revisions later on.
Therefore, it is crucial to establish a swift and efficient feedback cycle in peer review processes. By doing so, we not only reduce the likelihood of waste and rework, but also enhance the overall productivity and effectiveness of our teams.
If we take this into account, we want to be as much as possible in the sync & non-blocking quadrant, as the synchronicity causes a small feedback cycle and the non-blocking minimizes the IDLEs.
Debunking Pair Programming Myths
Why're then we not all doing pair programming?
Pair programming is often misunderstood and associated with numerous fallacies, specially in the realm of efficiency of project resources and velocity. With this in mind, let's review the studies:
The significant benefits of pair programming are that: • many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews); • the end defect content is statistically lower (continuous code reviews); • the designs are better and code length shorter (ongoing brainstorming and pair relaying); • the team solves problems faster (pair relaying); • the people learn significantly more, about the system and about software development (line- of-sight learning); • the project ends up with multiple people understanding each piece of the system; • the people learn to work together and talk more often together, giving better information flow and team dynamics; • people enjoy their work more.
The development cost for these benefits is not the 100% that might be expected, but is approximately 15%. This is repaid in shorter and less expensive testing, quality assurance, and field support.
A field experiment was conducted using experienced programmers who worked on a challenging problem important to their organization, in their own environments, and with their own equipment. Findings revealed that all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions.
Management Impact on Software Cost and Schedule: Regarding the performance of pairs vs individuals:
Final project results were outstanding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 llpm. […] The error rate […] was three orders of magnitude lower than the organization’s norm.
The Collaborative Software Process: One key finding was that pairs took 15% more developer hours to produce their solutions, but those solutions had 15% fewer bugs.
An experiment was run in 1999 with approximately 40 senior Computer Science students at the University of Utah. Two-thirds of the students worked in two-person collaborative teams […]. The other students worked independently […] to develop the same assignments. The productivity, cycle time, and quality of the two groups have been compared. Empirical results point in favor of the collaborative teams […].
Having reviewed the data, it's important to recognize that our industry leans against this technique not due to the data, but for other subconscious underlying reasons:
The data might seem counterintuitive.
The available tools are more attuned to a different technique (pull requests).
Given our inherent social tendencies, there's a psychological aspect to consider that we believe spending too much time with a person is not enjoyable.
Pairing in Other Engineering Roles
Pairing can be applied effectively in these roles in the following ways:
Design
In design, pairing can be used for brainstorming, critiquing, and refining design concepts. This includes sketching, prototyping, user testing, and iterating on designs. Pairing helps to bring multiple perspectives to a design problem, leading to more innovative and inclusive solutions.
Product
In product roles, pairing can be beneficial during product planning, strategy discussions, and execution. Two product managers can collaborate to define the product roadmap, prioritize features, and make decisions based on customer feedback and data analysis. Pairing can lead to more robust product strategies and better decision-making.
Leadership
In leadership roles, pairing can be used for decision-making, strategic planning, and problem-solving. Two leaders can work together to guide their team or company, make critical business decisions, and navigate complex challenges. Pairing in leadership can foster a culture of collaboration, improve communication, and lead to better outcomes for the team and organization.
Closing thoughts
Peer review, in software development, is a critical quality control process. It involves evaluation of a professional's work by others with similar expertise, enhancing the work's credibility and accuracy.
However, peer review isn't synonymous with pull requests and can take various forms such as formal reviews, over the shoulder reviews, code comments, and pair programming.
Pair programming, often misunderstood, is an efficient method that reduces errors, improves design, and enhances team dynamics. It can be applied to other roles like design, product, and leadership for brainstorming, refining concepts, strategic planning, and decision-making.
Thank you for reading Leads Horizons. This post is public so feel free to share it.
I love hearing from readers, and I’m looking for feedback. How am I doing with Leads Horizons? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?
Use the links below, or even better, hit reply and say hello. I’d love to hear from you!
Mini-example: I try to use the help of other people to double-check dates when I'm in charge of booking (especially for tickets or non-refundable stays).
Thank you, Alvaro, for including my article on lessons from change in your selections!
It is a great summary of Peer Reviews.
Mini-example: I try to use the help of other people to double-check dates when I'm in charge of booking (especially for tickets or non-refundable stays).
Thank you, Alvaro, for including my article on lessons from change in your selections!