Pair Programming – So how good is it, really?

Pair programming (sometimes called peer programming) is a controversial topic.

Some developers love it and some grow horns of hate as soon as they hear the words mentioned.

There are studies that show the great benefits of higher productivity and a safer product. Who ever I ask, there seems to be strong opinion either for it or against.  I’ve done some research in an attempt to bring some clarity to why it’s so controversial and how and when should it be performed.

Other questions I’d like to answer are…

• What’s the good and the bad?
• How common is it?
• Why aren’t more developers pair programming?
• Where is the proof?
• How do we measure the value?
• What are the things you might not have thought of.

What is pair programming?

Pair programming is when two developers are coding together. Meaning one is typing and one is observing. There are different approaches and best practices of how best to co-operate.

Most commonly the one who is typing is called the Driver. Their main focus is to write and think about the current task. The current task is usually a smaller piece of a bigger task. The person beside is called the Navigator. The Navigator will focus more on detecting bugs and problems, structure and what to focus on next.

The idea is to split up responsibility between the driver and navigator to keep a steady development flow, and help share knowledge across the team. The Driver and Navigator should be constantly talking to keep each other involved. Pair programming can be enhance the learning for both participants.

Statistics

In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone.

Additionally, 95% of the surveyed programmers stated that they were more confident in their solutions when they pair programmed.

Pairs spend about 15% more time on programs than individuals.

However, the resulting code has about 15% fewer defects.

IBM reported spending about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”. Pair programming significantly reduces these expenses by reducing the defects in the programs.

Pairs typically consider more design alternatives than programmers working alone and arrive at simpler, more maintainable designs. They also catch design defects early.

Benefits, promises and opinions

• Safer code: Since we have two brains focusing on the code we will reduce errors and failures.
• Save time: The actual development time might be a bit faster or slower but with a higher quality we will save time in error fixing and refactoring code.
• More money: Since we know that time is money we will save money too. But also if we have less errors and other issues we will have happier users. Happy users is often equal to more money.
• **Better code: **With a partner you’re able to discuss different structures and solutions you wouldn’t come up with by yourself.
• Better team knowledge: Pairing means more communication. The side effect is better spreading of knowledge across the team regarding coding, project, company, workflow and anything else.
• **Faster learning for Juniors: **Juniors often learn much faster when pair programming with a senior. Getting more insights of the code and the company.
• **Better understanding of the task: **To have good collaboration, it’s important to be clear about the task. By explaining the tasks we often get an better understanding of it. Maybe questions arise and solutions are made before any code is written.
• **Shared experience across the team: **While pair programming you will constantly learn from your partner. Yes, even if you’re senior, you have things to learn. It’s also a good time to share your tips when you’re coding.
• Confidence: Pair programmers often have a higher degree of confidence since two brains have been part of the development and testing.
• Happier employees: Some think it’s more fun and are more satisfied with their work environment. It’s also a great time to make friends with the ones you normally don’t hang out with.
• Higher focus: Since you have to collaborate you’re more likely to focus. Having a constant dialog also helps you to stay focused.

The downsides

But, can it really be that good? There must be some downsides as well.

• **Lack of will: **Some simply prefer and work better alone.
• Wrong tasks: Pairing at the wrong time can be both time consuming and inefficient.
• **One can slow down two: **If one is a slow thinker/typer or unfocused it can slow down the other one as well.
• **More talk less coding: **You might end up explaining things that would be faster to just code.
• **Lack of code ownership: **Since two developers are responsible for the code both can feel that the other one is more responsible. If an error occurs there could be a discussion of who should fix it or if it should be done in pair again.
• Loss of confidence: Some developers find that pairing a lot loses their confidence of coding alone and they want to pair on more things than necessary.

Pair combinations

Senior – Senior

Even though you’re a senior you can make mistakes, won’t always see the best solution and will always have something more to learn. Pair programming could be a good way to fill those gaps.

Senior – Junior

This is great to speed up the learning curve for the junior. The junior may have a more open mind and question things the senior just got into a habit of doing. This could be a great way to increase experience across the team.

Balance is important. If cooperation is not good, the junior might end up just watching. The senior could be annoyed by explaining and feel resistance in his/her development flow. Make sure to find a good balance that works for everyone. E.g if the manager/boss is clear about the importance of everyone’s learning, the senior might feel better taking the time to explain. The employer invests in a productive team so pair programming could in this case be a good investment for the company. That could make the senior developer more motivated to teach and less frustrated of slowing down his/her coding.

Junior – Junior

This combination could significantly improve productivity and quality. Since juniors have more to learn and more questions, they can now learn from each other and develop their skills faster.

When to pair and when not to

Since pair programming will/should increase the concentration for both, it may not always be the case. Many tasks may not be suitable for a pair. Simple tasks for example. What is a simple task depends on the experience. For a difficult task, either a solo senior could solve it or a pair of juniors. Or maybe it’s touching a core feature so having a senior – junior combination might be a good opportunity to strengthen the junior skills and knowledge.

Experiences of an experienced pair programmer

From my experience there are often very strong opinions about pair programming, love or hate.

Statistics may say one thing but some developers mean the opposite. Mark Piper has 5 years experience of pair programming and 2.5 years as a manager of pair programmers. He wrote a great hate/love article and made many good points I’d like to share with you.

He talks about an enormous learning curve when he started pair programming. Not only about the code, but insights about the products, past history, the organisation and about other technical areas. He talks about the fun of pair programming but also the understanding of other programmers. Class names and structure that makes sense for one might not for someone else. Pairing with experts taught him real insight into Test Driven Development, far more than he could ever have gotten from books or websites.

The frustrating part of working with someone that’s slower or having to explain things, means he would prefer to solo code. Working with someone with violently different views on developing software makes it hard to agree on a solution.

As a manager he has seen a common feeling of dis-ownership of the code. He also sees developers getting too used to pair programming so they become afraid of doing things alone. Wasting time, e.g waiting for the partner’s meeting to finish. When one person is disruptive or unfocused, it disrupts or un-focuses two people instead of one.

Courage is the most important factor to make it efficient.

• Telling your partner you can do the task better alone
• Telling your partner to focus
• Asking for an explanation you think you “should” know instead of waiting and hope things get clearer
• Having an argument that you might just lose
• Courage to admit that you’re both stuck and need to swap pair partners to bring a fresh pair of eyes to the problem

Is pair programming for everyone?

We are all different so obviously the result will vary.  Steve Chafer says…

I think it works great for some people, and awfully for others. And there’s not much in between. Some people code faster than they think, and pair programming works well for them, because of the obvious “checks and balances” that you have in that situation. Others need to get into “the zone,” to do well, and that usually means zero distractions.

How to measure Pair Programming

Of course it’s hard to measure the value. One reason is, there are many things to measure. The other one is, it’s just hard to measure. **Values that are worth considering could be: **

• Development time: How much more/less time is spent on development
• Fixing time: How much more/less time is spent on fixing errors or refactoring
• Enjoyment: How much more/less work satisfaction do the employees feel
• User satisfaction: How much more/less happy clients and end users do you have
• Money: If you get this data you should have an idea of the economic value as well

If you’re not already doing it, catching ALL errors from your software/app/website/etc is a must. If you launch a product without receiving all errors your users experience in real time you will probably lose costumers and money. So first of all, track all your live errors. Yes we at Raygun know the importance and the value of this. That’s why we made Raygun. So sign up today and get invaluable insights about your product. Once you know all about your errors you can easily compare solo-/pair -programming.

Summary

After a lot of reading I still find it hard to tell how common pair programming is. On one side we have companies that use it as a well implemented method and have proof of the benefits in terms of less errors, repairs, support and are saving money. On the other side we have companies that would never touch it.

So why are solo programming companies solo programming? Is it because it’s just better for them or is it lack of experience and knowledge, fear of the change, lack of motivation (not being convinced about the benefits) or is it because they didn’t even make a choice?

First of all I think the question is wrong. It’s not about being a solo company or not. It’s not about being a pair programmer or not. Pair programming is just a tool. Like all tools it’s great for some tasks and garbage for others. It’s like asking a design company if they are a Photoshop company or not.

Of course they’re using the tool that suits the task best, sometimes illustrator, in-design and sometimes Photoshop. With this point of view I understand even less why so many are for or against pair programming. For me it’s more of matter of using a great tool when it make sense.

I believe that with an open mind all companies can find some use for it. Some very little and some a lot. I also believe that there’s only one way to find out. TRY IT. I don’t think we have anything to lose but a chance to win.

Are we a different kind of developer?

It seems like it’s not only the task that determines if it’s a good choice to pair program or not, but the type of person matters as well. Maybe we are just different, some prefer solo and some pair.

In sports it’s well known that some perform better as individuals and some in teams. Some athletes are hybrids and work well in both scenarios.  Why would developers be different? Maybe it’s a matter of understanding ourselves better to know what works best for us. Maybe some companies choose to be solo coding companies because they have more individualists in their companies.

It’s hard to tell if it’s good or bad, when it’s good or bad and for whom it’s good or bad. But again try it to find out. Ask the team about their opinion, test it on a small scale and ask the team again. You might find that some people love it and some hate it.

Some like to pair program and some do not. You will find small benefits and get encouraged to try it on a bigger scale. Or you’ve realised that pair programming was just not for your team, but at least you know it now.

From my understanding there’s nothing bad with pair programming itself, it’s just a matter of finding the right combination of developers for the right task. For that, experience is required. For experience trial and error is required.

Please leave some comments to let us know your opinion.

And, this excellent post on “How Exception Monitoring Increases Innovation”