How Pair Programming helps deliver better projects

Among the many other perks of the agile methodology comes the idea of pair programming. I’m using “perks” in this case in the most positive way possible — after all, our team at Code Runners has been following the agile way for some time now.

The Definition

The idea behind pair programming is, simply put, that two developers sit at one work station and write code together.

Of course, it wouldn’t be a popular development method bar some cool terminology .  The person writing the code is called the “driver” and the one pointing fingers and giving feedback is called the “observer”.

The Disadvantages

Employers are often sceptical about pair programming, as it takes up the time of two developers working on a single feature. In a saturated market, where processes revolve around resource optimization, it sometimes feels counter-intuitive for (senior) management to understand why pair programming is a good practice.

Disadvantage Backsides

Truth be told — if you take cost into consideration, it is indeed more expensive for two developers to work on a single task that can otherwise be completed by one.

However, the ROI of pair programming is greater, when you consider less tangible advantages. For instance , increased productivity and smaller technical debt.

There are numerous studies on the subject, dealing with the exact amount of productivity increase and the reasons behind it. In one of them, a pair of programmers working on a single problem produced 175 lppm (lines per person-month), compared to 77 lppm written by a lone developer. One might argue that just a higher number of written lines doesn’t necessarily mean better quality. Still — the difference is pretty significant.

Our Take On The Matter

In our own experience, our colleagues admit that they code smarter and more carefully, in order to impress their coding buddy or simply to avoid embarrassment from poorly written code .  Something an individual programmer doesn’t automatically think or do, especially in encapsulated projects. Additionally, the process cuts the number of bugs from the final version and facilitates a faster release, ultimately leveraging the cost of development.

In essence, the amount of time spent on debugging after an individual programmer was measured to be roughly the same as two developers working on the same feature. It evens out in terms of time, but you also get quite the added value. Namely, higher quality code and developers who actually learn more in the process.

Additional criticism

A popular notion is that developers are introverted and would rather work alone and not communicate with others. Surely, getting accustomed to working in pairs takes some time. Yet  developers love learning new skills and improving what they already know. Working side-by-side with a fellow programmer helps them gain more experience at what they do while advancing the project at the same time. They get another point of view, and through a very short feedback loop – actually way shorter than the usual merge request review.

In fact, surveys show that 90% of developers asked about pair programming, report they enjoyed it more than working alone. It’s natural human behaviour — we feel more at ease when there’s a person we trust overseeing our progress.

Even More Positives

Another effect of pair programming that ultimately saves time is the increased focus on a task. Everyone has been the victim of that short YouTube video or that person who dropped us a “quick question” on Slack. Distractions would, in most cases, cost a lot of time and effort to regain your focus back and complete your task error-free. Minor distractions tend to be ignored when discussing your work with another programmer.

Of course, some developers do prefer working alone and concentrate better while doing so. This should be respected and forcing someone to work in pairs could only have negative effects. Another important disclaimer is that once two programmers work together it’s not set for life. It’s actually better to mix up the pairs and diversify the knowledge spread between your team. It also bonds the team together and makes everyone familiar with a given project, allowing for more flexible team arrangements. One last thing – we don’t pair program all the time. We only use this technique when working on the core functionality of a new product – or for quite complex tasks.

Conclusion

To recap —  pair programming can not only cut costs in the long run but also make your team better at what they do. While also bringing some additional joy at the workplace. Still, it’s far from a universal truth and as a product owner, you should consider the team background and general setup before choosing to go that way.