Pair programming in a software house: yes or no?

What do we actually consider pair programming

Pair programming (or pair-programming if you will) is a practice of the extreme programming (XP) agile software development framework. The main foundations of the latter one were laid by dynamically changing software requirements, risks resulting from fixed time projects, small colocated development teams as well as automated unit and functional tests. Extreme programming emphasizes values such as communication, feedback, simplicity and courage in the face of issues which may arise along the way.

Enough with the background. Simply put, pair programming is a situation when two people code together. There exist several models of its occurrence varying in regards to factors such as level of expertise (senior and junior) of both coders in a pair or roles assigned to them. To capture the possibilities offered by pair programming, let us stick to the distinction based on the latter criteria, yet still using the former to highlight the shades of grey.

Driver-navigator

This is probably the most classic model of pair programming. A driver is typing and navigating between files, being also responsible for basic implementation. A navigator’s task is to see things in a bigger picture, express broader concerns and to look for the mistakes. This model is said to work very well with two seniors who can switch their roles any given moment. It also may work in the configuration where a senior is the navigator while a junior performs the tasks of a driver.

Backseat navigator

This is a model pretty reminiscent of the previous one, however the authority of the navigator is stronger this time. The navigator’s position is more tactical, being responsible for strategic decisions which are later dictated to the driver who executes them. This one works best in a junior-expert pairing. The junior, who takes the position of a driver has an opportunity to learn things the way an expert would do.

A tour guide

In this case, it is the driver who takes on a major part of responsibilities. While typing the code, they also do strategic thinking. As they do all that, they tell the other one in pair what they are doing at a given moment. This one is most frequently practiced with a senior driver and a junior “tourist”. It can be done the other way round, though, with a novice driving and telling what they do, while the senior gives real-time feedback and correction.

The statistics of pair programming

In a research published in 2015

• 95 per cent of the surveyed programmers stated they were more confident in the solutions they ended up with working in pairs,
• 15 per cent more time was needed for pair programming than solo programming but the resulting code had around
• 15 per cent fewer defects, because they were easier to catch at an early stage. Also, the designs they arrived at were simpler and more maintainable according to how they felt about them.

Two heads better than one? Pros and cons

The main advantages of pair programming include:

• Clearer code. Another pair of eyes helps eliminate errors already at the time when the code is being written.
• Time and money. Pair programming may accelerate the process of development by joining forces. It can, on the other hand, slow it down a bit, but with the proportionate increase in bug elimination. So, all in all, it can actually save time that would be spent later on getting rid of errors and failures anyway. Let alone the money this would require.
• Knowledge and skills distribution. Pair programming requires communication. This results in better knowledge sharing across the entire team (be it regarding coding, the particular project or the company in general). This contributes to a better understanding of tasks. It’s also a great opportunity for juniors to learn good practices seniors employ. And vice versa: the experienced coders can get new insights.
• Happy users and bigger revenues. If pair programming decreases bug risks, it surely has an impact on user experience with the product. The bigger the satisfaction, the bigger the popularity of the software and the more money you earn.

But some also point at the disadvantages:

• Some people are better off coding on their own. Period.
• Lack of code ownership. Coding is creative work. Where two people are responsible for it, it may be unclear, who actually is the author of the code. In such cases, the tasks should be explicitly discussed.
• One slowing down another. People being slower at coding can have a negative impact on their partner.
• More distractions. Pair programming requires communication. That’s the tricky part - you should remain focused instead of just endless chattering.

Pair programming in a small software house

I asked some of the Prograils devs about their experience with pair programming. In a small software house like ours, its use is rather incidental, however proven helpful. The first instance is when too much time is being spent on solving a single problem. A fresh pair of eyes is always of a helping value. Whereas we usually don’t base entire projects on the traditional "driver/navigator" model, some of our coders find it useful to separate these roles every now and then in order to track down something they have had difficulties seeing.

There is yet another type of situation worth highlighting. We call this one cross-project pair programming. It happens when a developer enters a project they have not been related to in any way before and take over the navigator role, while the other person is the driver. This is when having an additional pair of eyes may help solve an issue.

In case you want to learn a bit more about our work flow, feel free to read more on that in our playbook.

Summary

There are numerous advantages to pair programming, proven by research. However, it may seem pretty obvious that there are some reasons for sticking to doing the coding work on your own. Even though we do not base the majority of our projects on pair programming, there are situations in which our work simply benefits from that and the classic “driver/navigator” model works in favor of both. Still, if you consider yourself a good Ruby on Rails driver, but want to see things in a bigger picture, don’t hesitate to grab a book and learn something new!

Photo by Robert Magnusson on Unsplash