Pair Programming, popularized by Kent Beck thanks to Extreme Programming (XP), is increasingly important in IT organizations. However, some people misunderstand or misperceive the advantages of these practices. This article will highlight the interest and advantages of Pair and Mob Programming for a team and more globally for a project.

What is Pair Programming? (and mob?)

The concept is to program with two people (Pair) or several (Mob), usually with the whole team. Roles are defined for who holds the keyboard and observes/leads the development (Driver/Navigator), and rotations are set up to reverse the roles. We will not detail the different forms of Pair Programming (Ping-Pong, Strong-Style); you will find more information on this link, with recommendations on the implementation. 

Five advantages to keep in mind 

 

#1 A positive impact on the source code

Two developers working together is an efficient method to challenge their point of view, share their questions, and imagine the most appropriate solution for a given context. It is also to reduce the time of blocking on a problem and to prevent the risks related to the “Sunk Costs”: if you develop alone and face issues on a problem for several hours, as you already invested a lot of time, you’ll continue until finding a solution (and it would worsen the situation).

Working together on a task optimizes the chances of achieving a more accomplished result in terms of design and code quality, reducing future maintenance costs The exercise generates by nature a real-time code review since only one person holds the keyboard. It also reduces the risk of over-engineering. All participants in the session are responsible for ensuring that the code is minimal and understandable when the task is over.

#2 Fewer bugs introduced

Even though it is difficult to generalize, several studies have, since the early 2000s, highlighted the beneficial impact of Pair Programming on the number of bugs. Pairs tend to write code that contains fewer bugs than single people. We do agree that studies can be biased (since a practice takes time to be adopted). But do we really need to be convinced on the benefits?

By working as a pair of developers and doing a code review in real-time, we can assume that the overall quality of the work is better than a work produced alone. These mechanisms allow preventing the risk of bugs introduced into our source code.

 

#3 Knowledge sharing

We had already talked about this in a previous article on code review. Pair/Mob Programming is a communication exercise between developers within the same team. This communication includes the transmission of technical know-how but also the way certain parts of the code are structured and designed.  

Participating in a Pair Programming session on code you are not familiar with is an excellent way to increase the collective ownership of the code, avoiding knowledge silos within a team. The person who reviews the code can suggest alternatives for code writing, and it’s easy to guess the learning process happening there thanks to communication.

#4 Better team cohesion

It cannot be said enough, software development is a team process. Practicing Pair/Mob Programming is virtuous for the collective dynamic and for consolidating the links between each person. Pair programming sessions have a positive impact on team morale. Communication and knowledge sharing consolidate everyone’s well-being! This is also feedback we frequently get with Promyze’s Craft Workshops.

Finding solutions to problems together and achieving a better result faster generate satisfaction. It reinforces the belief that there is a collective accomplishment in work done, and that we are not isolated people who have to solve problems on our own.

#5 A better “focus”

It may seem secondary to mention this point. Still, several studies have also shown that developing with several people increases the focus of the participants and reduces the risks of distraction. The idea is quite simple: alone, one may tend to be more easily disturbed by notification, an email, to switch tabs, in short to leave his IDE for other subjects. With several people, there seems to be an effect where people, eager not to disturb the Pair/Mob Programming session, will let themselves be less distracted and stay more focused on the current ask. This finally mitigates the effect of “Context Switching”, which in turn can waste time. 

This also raises the importance of setting time limits in the sessions, allowing each person to have time for themselves and decompressing!

 

What about productivity during Pair and Mob programming ? 

This is a sensitive subject when you talk to people who are rather reluctant to implement Pair/Mob Programming. They think the project will cost more money because it will take longer to deliver features.

In software development, productivity is a tricky concept. Can it be measured in terms of time to complete a task? Not only. Because at the end of the day, isn’t our goal to produce code that works from a functional point of view, is sustainable and above all tested? In which case, wouldn’t productivity amount to measuring the time to finish the task, the time it will take later for another person to understand and rework the code, the time it will take to fix any bugs that may have occurred in the code, etc.? 

Some studies have shown that pairs take longer to finish a task than single people, but this overhead was nevertheless quite small (15% on average according to the studies). Once again, this data is short-termist and difficult to generalize, because as we said, we have to take into account the content of the work produced (architecture, design, …), not only the time. 

 

Wouldn’t it be easier if tasks are parallelized? 

Well, we would tend to answer “yes” if software development consisted only of achieving tasks whose execution is precisely known and detailed in advance. This is of course not the case, and like any engineering activity, solutions to a given problem are multiple and get refined as we progress in the code.

As Woody Zuill explained very well, “It’s in the doing of the work that we discover the work we must do”. We could even talk about the #NoEstimate, but that would be a bit of a departure from the subject at hand. Development is made of unforeseen events and problems to overcome, so there is no known recipe in advance.

Is it always necessary to do pair or mob programming? 

It turns out that some trivial tasks, such as minor bug fixes, may not have much added value when done by several people. Some studies have also highlighted that even if some developers enjoy the social dimension of pair Programming, others are keen on developing alone from time to time. This is particularly the case for “Junior” profiles, for whom being able to complete a feature by themselves boost confidence and self-assurance. 

A good way to know if the session is still interesting is to see check whether participants are still focused and attentive to the discussions. It’s okay, after a few hours, to stop feeling productive and let others continue the session.

Some points of vigilance…

Pair Programming, like many methodologies in our field, is not a silver bullet. It is not because we practice it that everything will get better. Like other methodologies (Code Review or TDD for example), if you don’t apply the right recipes, there is little chance to obtain gains. 

It is important to explain the approach and the objectives beforehand. It is also important to take into account each person’s personality, especially when doing Mob Programming. Some people may find it intimidating to code in front of the rest of the team. Others are afraid of being judged if they want to leave a Mob session. Some more experienced profiles may also get tired of spending all their time coaching more junior people, and will need to have some time during the week to work on other things. It is a balance to be found.

 

To conclude 

The objective is not to go from 0 to 100% of pair programming in a few weeks, but to position the right cursor for your team. To achieve that, objectives and expectations of this approach have to be shared, and feedbacks should be continuously collected from the team. This remains the best way to identify which adjustments to make to take advantage of the Pair Programming sessions. 

Promyze is