Published in: Uncategorised

Learning culture in software engineering teams: Code reviews & Mob programming (5/7)

This post is part of a series of 7 blog posts on the topic How to create a learning culture for software development teams:

#8 Code reviews

Code review is a widespread practice in the IT industry today. It consists of asking one or more people to review the source code to propose improvements, detect potential defects, non-compliance with standards in force in the organization, or highlight the quality of the contribution.

Above all, the code review is a communication exercise that requests the know-how of the teams and their ability to comment on the code while taking care to formulate comments that do not target the person who wrote it. While it can have a beneficial impact on the quality of the project’s code, it can quickly prove to be counterproductive in the case where :

The size of the code to be reviewed is too large (several hundred lines of code), which will make the review superficial and with insignificant added value;
A single person is responsible for reviewing the code (generally a Tech Lead profile). In addition to generating latency, this can lead to fatigue and repetition, leading to frustration for the people requesting the review.

This second point is confirmed by recent studies on the subject. Why such feelings of weariness and repetition? The main reason lies in the lack of knowledge of the teams about the best practices to apply. Since code reviews are usually limited to two people (the submitter and the reviewer), the scope of the discussions is limited to the review. Therefore, it is likely that comments made in one review will find their way into the following code reviews of other team members. The dissemination of the practice will lack effectiveness.

Thus, if the code review is an excellent support to transmit knowledge, we observe an apparent lack of capitalization. If the review is independent of any tool, it is common to use the Pull/Merge Request (PR/MR) features offered by GitHub, GitLab, BitBucket, or Azure Devops allow to have an overview of the changes made and to add comments. Once the reviews are completed, and the PR/MRs closed, their content and comments are generally not taken back for later.

There are, therefore, still areas for improvement to optimize this practice. A first approach, which is commonly applied, consists of rotating the role of reviewer within the teams, avoiding concentration on a single person, and reinforcing the collective ownership of the code. In addition to fluidifying knowledge sharing, this will optimize the value delivery flow. Indeed, what a pity to spend two days developing a feature, then having to wait three days for someone to finally be available to proofread the code (not to mention the potential corrections to be made that will have to be proofread!).

#9 Pair and Mob programming sessions

Co-creation method promoted by Extreme Programming, pair programming involves two developers who will work together on a given task. One person at the keyboard, and one guiding and proofreading in real-time, all with a rotation of roles at regular intervals (10 min., for example). This methodology has several advantages:

Development being an engineering activity, it is likely that two people together will find a better solution sooner to a given problem;
One person reviewing the other leads to a code review without latency, and thus to earlier detection of problems, which shortens the feedback loop;

Like the code review, it has a strong social dimension and reinforces communication and team cohesion.

Its extension, Mob programming, will invite several people from the team, or even the whole team. If your teams are not familiar with this exercise, keep in mind that it is not a problem not to do Peer/Mob Programming daily. Not all development tasks are appropriate. Developing a core business functionality will be a good playground, where a minor patch may be less relevant.

A Pair/Mob programming session will become ineffective when there are signs of fatigue, loss of concentration, or disinterest in the exercise. In particular, because the problem’s content to be solved is too trivial, or because you are struggling for a long time without being able to step back and radically change your approach to implementation. In this case, it is better to take a break and start again later. So there is nothing wrong with stopping the session after 2 hours.

In practical terms, especially since the COVID-19 episode and the rise of remote work, tools to develop together in real-time have become increasingly popular. We can mention Visual Studio LiveShare, a plugin for VisualStudio, or Code With Me proposed by the editor JetBrains.

Because of its very strong social dimension, these sessions will foster knowledge sharing, thus promoting the technical progress of the teams. Nevertheless, just like the code review, the process of capitalizing on these exchanges can be improved to benefit the rest of the team or even other teams.