All About Pair Programming

Test

Software development is a complex job and you can find a myriad of interesting practices that can make it easier, faster, or more optimized. Moreover, software developers have to always find the most efficient way of developing their products in order to keep that competitive edge.

We’re very loyal to the agile methodology as we’ve stated often, and mix agility with accuracy to stay ahead of the game. One proven method in doing so, and a method proven to increase efficiency is pair programming.

Let’s see what this method stands for, what are its common tactics and what are the most suitable tools if you want to approach it.

What is Pair Programming?

Starting from its self-explanatory name, this dev method is as simple as that — 2 devs pairing up to maximize the efficiency of development. It was first introduced as the Dynamic Duo Concept by Larry Constantine in the ’70s, but now it has evolved to the pattern where two developers share the same computer to work on a coding project.

We can call it Dream Team, too 🦸

When done correctly, this technique can deliver software faster and decrease the costs of production.

In some organizations, developers’ code is passed to a test or quality assurance department, which finds many of the remaining defects. Typically, in systems tests it takes between four and 16 hours per defect. Using a fairly conservative factor of 10 hours/defect, if testing finds these “extra” 225 defects they will spend 2250 hours — fifteen times more than the collaborators “extra” 150 hours!
If the program is sent directly to a customer instead of a test department, pair programming is even more favorable. Industry data reports that between 33 and 88 hours are spent on each defect found in the field. Using a fairly conservative factor of 40 hours/defect, if the customer is plagued by these “extra” 225 defects, field support will spend 9000 hours — sixty times more than the collaborators “extra” time!
— The Costs and Benefits of Pair Programming (page 4)

How to approach this practice

Within pair programming, two developers share the same computer. The roles for these two are The Driver & The Navigator and they can switch between each other depending on the development cycle and their level of expertise.

But, like with any agile practice, this is not a done-do approach, and you can adapt it to your needs or perspectives. Explore the benefits of it, without getting stuck on the rules.

Two heads are better than one, and that’s the main reason why there will be less time of completion if you put two programmers together than have them work separately on two different projects. Or another perspective that can successfully sustain this practice is The Four Eyes Principle , where two individuals approve an action before it can be taken.

This is the most common way to go:
→ The Driver is the person operating, and usually narrates what he/she’s doing and why. Also, the key is to focus on one issue at a time, and not think about the larger perspective.
→ The Navigator is observing, while his/her colleague is typing. They review the code on the go, give directions and other observations. The Navigator is also the one who has to keep an eye on the larger perspective and keep notes, in order to identify the next obstacles.

This is how a pair programming flow can look like:
→ Pick the most complex, but the well-defined task at hand.
→ Split it into tiny goals and go through them one at a time.
→ Switch roles often in order to keep each other engaged in the project. Remember, this is a collaborative approach.
→ Stay aligned with your duties according to your role — the driver has to be engaged with the coding details, while the navigator has to be engaged with long-term thinking.

Ultimately, we can’t deny the fact that in most cases, developers are more creative and efficient alone, so it is also important to identify the right context for pair programming.

Discover the most suitable tools

Today’s pair programming is mostly remote, as we are too. Good news is, there are very effective tools to enable this collaboration. Check them out:

→ Visual Studio Live Share
→ Code With Me
→ Teletype for Atom
→ Remote Collab
→ CodeSandbox
→ Codeanywhere
→ CodePen

What is your favourite collaboration method? We’re always curious to find out more from fellow devs so don’t hesitate to give us a shout. Also, we’re constantly on the lookout for talented coding hands, so check out our Careers page to see if you’re our next driver or navigator! ⛵