Exploring the Truth Behind Software Quality
Code review is a well-established practice in both open-source and proprietary software domains. But is it the savior for better software quality?
What makes a code review good, and how does it compare to Pair Programming?
I will share what I have found to work best to get the most out of Code Reviews and how it compares to pair programming.
Code review can be done in many different ways. In this post, we will focus on a regular, change-based code review that can be defined as
A lightweight type of code review in which the scope of each review is based on the changes to the codebase performed in a commit or pull-request.
Wikipedia
Lightweight code review gives fast feedback, compared to a formal code review meeting where the criteria for starting the code review is much higher.
Top 3 benefits of using code review
Finding bugs seems like the most apparent reason for conducting a code review, but it is not my experience that this is one of the top three benefits.
1. Resilience to Changes in the team through shared ownership
In a rapidly evolving software landscape, having shared code ownership can make the team more adaptable and resilient to changes such as team restructuring, personnel turnover, or shifting project priorities. By spreading knowledge and responsibility across the team, the absence of any single team member becomes less disruptive, ensuring continuity and stability in the development process. Code review serves as a mechanism for knowledge transfer more effectively than documentation, enabling smooth transitions during times of change.
2. Accelerated Learning
When team members feel a sense of ownership over the codebase, they are more likely to actively engage in discussions during code reviews, ask questions, and seek clarification. The exchange of ideas and perspectives improves the code’s quality and accelerates individual learning as developers gain exposure to different coding styles, problem-solving techniques, and best practices.
3. Faster to change and implement new features
Software development is 99% reading and reasoning on code and 1% writing or changing the code. To avoid trying to understand the code all the time, it is good to have Martin Fowler’s quote in mind.
Any Fool can write code computers can understand, good programmers can write code humans can understand.
Martin Fowler
A simple way to ensure the code can easily be understood is to have another developer review it before it is merged. This is especially true if the code review is done without the author explaining it to the reviewer(s). In this way, the reviewer needs to use his or her understanding of the code.
This helps the developer in the team to follow the same coding standards, maintain consistency, and strive for excellence in their contributions.
Common fails in Code Review
Even though there are many reasons for doing Code reivew, there are som typical failures that teams do when practicing Code Review.
Rubber stamp
If teams are forced to have code reviews but are uncomfortable asking questions, or the review is just a rubber stamp in the commit process, this will naturally bring little value to the team. The team needs psychological safety to avoid this pitfall and ensure a collaborative environment where members feel empowered to contribute to the code review.
Time pressure
Another pitfall with Code Reviews is that they are skipped due to high pressure to deliver. When the team is pressed by a deadline, the Code review is omitted, or the feedback is not used.
I worked with one team with a deadline that pressed the team and, at the same time, had a rule that all code commits must have a name for the reviewer. Here, the code review was more of a burden than something that improved the quality.
The team must be very disciplined to have valuable code reviews if pressed by a deadline.
Code Review Vs. Pair Programming
Comparing Code review with Pair programming is not to rate one practice better. Both practices can improve the software quality and the team’s knowledge.
Both code review and pair programming help with shared ownership, accelerated learning, and higher code quality, but have different drawbacks. So when should you focus on Pair programming, and when should you focus on Code review?
Team dynamic
Pair programming only occurs when software developers are comfortable writing code in pairs. If the level of trust in the team needs to be higher, Code Review can be a good alternative to Pair programming and even a stepping stone for the team to use pair programming.
Feedback
Feedback is an important area where Pair programming and Code review differ the most.
Code Review: Asynchronous collaboration where the feedback happens after the code change has been written. The delay can be from a few minutes to weeks.
Pair Programming: Synchronous collaboration where all feedback and comments are done instantly
Short feedback times are essential when it comes to learning and solving complex problems such as Software development. Pair programming gives instant feedback. If learning is critical, Pair programming is the fastest way to learn.
If the developers are working in different timezones, like distributed teams, pairprogramming is not possible.
To manage feedback time, teams can measure the time between starting a code review and approving it. This can help the team minimize work in progress and its derivative effects, such as developers trying to multitask and wait for one another.
Speed and Efficiency
Regarding speed for solving a specific problem in software, my observations and the studies from Laurie Ann Williams’s Master’s Thesis shows that the code change is faster and the quality higher with Pair programming compared to having a single software developer. But not twice as fast as a single software developer. Unfortunately, I haven’t found a comparison between Pair programming and Code Review.
Efficiency is more challenging to measure. Efficiency is both how much time the developers have used and the output quality.
When should the team use Code review and Pair programming
Both code review and pair programming have their strengths and weaknesses, and the choice between them depends on project requirements, team dynamics, and individual preferences. The team can easily switch between the two practices depending on the situation and task.
When to use Pair Programming
Learning
The team members needs to learn new technology or there is a new team member that needs to be quickly onboarded.
Ensuring code quality under time pressure
If the team is under a constant pressure to deliver new features and handle bugs, changing the default development method to pair programming, can help the team deliver with a higher quality.
Dependencies between developer task
If the developers have problems working on the same feature because the changes are dependent and give merge conflicts, pair programming can help the team complete the feature faster.
When to use Code Review
Flexibility and Autonomy
Pair programming requires dedicating two developers to work on the same task simultaneously. When resources are limited or multiple tasks are to be completed simultaneously, code review allows developers to work independently on different tasks and then come together later for review and integration.
Flexibility and Autonomy
Some developers are motivated and prefer autonomy and flexibility in their work process. Code review allows them to work independently, focus on individual tasks, and receive peer feedback during review sessions.
Low Psychological Safety
If the team is uncomfortable with pair programming, Code review can be a good alternative and even serve as an activity to improve psychological safety.
