Why should you implement "pair programming"?

"Pair programming" is a working method that involves having two developers work together on the same machine and the same screen, rather than having them work in parallel on separate workstations.

This method fits within the framework of agile development, as stated in the "Manifesto for Agile Software Development" in the sentence:

• Individuals and interactions over processes and tools

Because yes, it is a form of collaboration that is much closer than what we're used to seeing in the software development world in general, one that pushes participants to exchange and share their ideas and solutions in a more recurring and fluid way.

But despite the benefits it brings, this practice still has a hard time becoming standard among software publishers, which is why we're going to look at the advantages it can bring, and how to make sure that implementing "pair programming" happens under the best possible conditions!

The principle

We understand well that this practice involves having two developers work on the same machine, but how exactly does a work session unfold?

In pair programming, there are two distinct roles for each developer: the driver and the observer. Neither of these two roles should be neglected because, as in the navigation of an ocean liner, the two jobs are complementary: one observes potential pitfalls to avoid and the best route to take, while the other turns the helm to follow the course while feeling the strength of the wind and keeping an eye on the state of the machinery.

Unlike steering a ship, the two developers must switch roles very frequently in order to have an effective session.

Let's take a look right away at what these roles correspond to in development!

The driver

The driver's role is mainly to write code, clean code of course, and they can work very efficiently with the support of the observer, who serves as a guide.

They are the one holding the keyboard and mouse, they are assigned the tactical side (as opposed to the strategic side) and should be able to focus on code optimization, its documentation, and everything directly related to the pure code.

The observer

The observer's role is to think about the structure of the project as a whole, to make strategic design choices, but above all to carry out a continuous review of the lines of code as they are typed.

Unfortunately, this is a role that is sometimes taken lightly, even though it is essential to the balance of the pair and to the quality of the software produced!

Best practices

Here are a few tips to help implement pair programming smoothly in your project (and your company).

Changing your perspective

The biggest fear that holds most companies back from implementing this practice remains the man-day profitability of project development, which is in fact only a matter of perspective.

Indeed, if you have two developers working on the same machine, you will potentially write half as much code in the same amount of time. Except that the gains from this practice can be enormous if you know where and what to look at.

Implementing good pair programming allows you to:

• Write more robust and efficient code
• Reduce costs related to support and debugging
• Have a more easily reusable codebase, because it's better thought out
• Train your developers continuously and much more effectively
• Improve communication and team-building within teams
• Bring patience and pedagogy into the company's values

Introducing it gradually

Whether you're a developer or a project manager, there's no need to try to impose pair programming as something exclusive, you could very well propose implementing it just one day a week to start.

Then, if this method works well, try to gradually increase the number of days in the week until you reach your point of balance.

It's also possible to implement it occasionally for certain sensitive tasks requiring greater vigilance and code quality, such as financial systems, for example!

Not forcing developers

Some developers are very patient and naturally good teachers, while others aren't at all. Don't impose pair programming on developers who aren't comfortable with the concept, let the idea take root, give them time to see the results of the method, and maybe they'll change their minds over time.

Better no pair programming at all than pair programming that goes badly!

Mixing skill levels

Learning and skill development are real positives of this method, and mixing different skill levels can be even more beneficial.

Having an experienced developer work with a junior developer will allow the latter to progress faster and pick up good habits more quickly, while the junior developer's questions can help challenge established procedures that have sometimes been around for too long and no longer make sense today.

Be careful, however, that the pair works well together and that the junior isn't simply relegated to the role of observer ad vitam eternam, which would cancel out any benefit of pair programming!

Alternating roles

As explained earlier, alternating roles is essential and should happen over relatively short periods (less than half a day), without being too short either (no less than a quarter of an hour).

This gives the driver time to accomplish one or more tasks and allows the observer to maintain sufficient stimulation.

Personally, I would place the optimal period between half an hour and an hour, but ideally, the pair should find their own cruising rhythm to make each session as efficient, stimulating AND enjoyable as possible.

I hope you enjoyed this article, feel free to let me know if you've implemented pair programming in your company and what the feedback has been!