3 Doubts Product Owners Have About Switching To Pair Programming

Making changes is not an easy task. Whether it comes to buying a new car or making an important business decision. Doubts before making the final decision are only natural. Same goes for product Owners who want to improve their product development process.

One of the ways of doing that is switching to Pair Programming. Here are the three biggest doubts that a Product Owner can have when it comes to this technique, with answers that explain the benefits.

Why would I ever spend extra money on two developers if the job can be done by one?

That’s the biggest doubt of most POs and founders thinking about Pair Programming. And a good one. Everyone takes the costs and investments into consideration.

Pair Programming has benefits that make it a better quality development process. I’ve written about those in my previous blog post. What do you get with that quality? Higher productivity. There is a a unit of measure called “lppm”, which stand for “lines per person-month”. How does Pair Programming score? In one of the studies pairs were more than twice productive compared to individuals. They had the same problem to solve working on it as a pair at all times. Their total productivity was 175 lppm while the average individual productivity was at 77 lppm.

You might ask now if that productivity is worth the money, since faster often doesn’t mean better. Well in this case it does. Pair programmer’s code has less defects and bugs. It actually passes 15% more test cases than code of individuals. And that means that less time and cash will be spent on fixing those.

Additionally, pairs admit they work harder and smarter on their tasks because they don’t want to let their partner down. Or maybe they simply don’t want to look stupid. This is something hard to notice in programmers working individually.

So, why should you spend the money on Pair Programming? Because it can cut your product-to-market cycle by a half. Because it saves time (between 0.5 and 88 hours per bug!) and cash spent on debugging. Because you’ll have a harder and smarter working team. Because it’s a high quality, efficient service at the right cost.

The money you spend on hiring two guys instead of one is not doubled. Studies show that pairs spend only about 15% more time on coding the same stuff than individuals. And the fact that debugging will take less time means that those 15% comes back to you in a different part of the process. All in all, the cost of hiring two pair programmers can be the same as hiring one individual.

Most developers are introverts and I don’t believe that they could work efficiently with someone as a pair.

The efficiency of Pair Programming is covered above. Let’s talk about the rest of that doubt then. Developers attitude. There is an important keyword right at the start of the sentence above — most. Stereotypes like ‘when programmers are left alone they perform at their best’ are often inaccurate. Devs love to learn new things and gain new skills. And there’s no better way to do that than Pair Programming.

In fact, many developers appreciate working in pairs. Pair programmers have been surveyed and asked about their satisfaction. Almost 90% of them said they enjoyed their work more when paired. And 96% said that they felt more confident with work done in that way. It’s not something unusual. We all feel more confident when there’s a somebody we trust to ask about opinion.

You will find many opinions from developers saying that e.g. “I don’t like Pair Programming, I need my own space to work, I want to listen to music while I’m at it” etc. Fair enough. It’s not for everybody and there’s no point in making anyone do something against their will. It might be hard to build a Pair Programming team from scratch. Finding the right people is difficult. But if you have a chance on hiring a team that already has Pair Programming experience, it’s definitely worth the shot.

If I’d lose a member of my Pair Programming team, pairs are disrupted and new people will have a hard time to adapt.

Now this doubt is not true. Thanks to Pair Programming and the satisfaction of it, people are less likely to quit and change jobs. Even if some of them do, your risk of losing a key person is minimal. The knowledge about your product spreads over all team members. There is a metaphor created by Jim Coplien that visualizes the fact in a fantastic way. Answer this question “How many people on your team would have to be hit by a car (or quit) before your product is incapacitated?”. The worst possible answer to this is “1”. With the knowledge about your product, pairing teams won’t have a problem keeping up with tasks. Even when several members of the team are not present.

Pairs are not disrupted due to anyone quitting because they are not set in stone. Two people don’t stick to each other at all times. They swap and work in different pairs, on different parts of the projects. In this way they learn about your product in the best way possible. And what if the number of your team members is odd? That’s not a problem at all. Pair Programming isn’t done around the clock. There’s always stuff that can be done individually. For instance doing research. Or even writing some part of the code that is simple enough and pairing isn’t quite necessary. The person who doesn’t have a pair at the moment is doing things that will support the rest of the team. Always moving forward!

Adaptation and learning is also much, much easier with Pair Programming. People work together, and learn how to communicate. Developers working in pairs will pick up not only coding skills but also simple things that make their work efficient. Juniors will feel more important. Not only will they learn from Seniors but they will also give them some knowledge back. Even soft skills cross between partners. And Seniors will appreciate that and respect them more.

Pair Programming is definitely different to a usual development process. So, like said at the start, the doubts are only natural in that case. But switching to that technique can bring many benefits to your product. If you want to bring your product to another level Pair Programming might be the way to go.