Agile Development with Pair Programming: Just Like Playing Ping-pong (Part 2)

Recently, we published a post about pair programming. In that text, you could find out what pair programming is and what programming is not, and how to pair your developers. However, we haven’t talked about the shortcomings and the benefits of this learning method. We are so into pair programming, but we want to make sure that you got all the information you need.

At the very end of the text, you can find a few tips to make this method work. Let’s begin!

pair programming

First, the disadvantages

This method is not a perfect one, and there are some drawbacks. Here are some challenges we’ve faced:

Being passive is the enemy

In order to make this work, both programmers must be engaged in the task, actively trying to find the solution. Asking questions, talking, sharing different opinions, arguing — these are all parts of the learning curve. Sometimes this is not the case, and that is why developers are not really interested in this technique.

No good can come out of keeping things from your pair programming mate!

Not everyone can work together

Oh, let’s not talk about interpersonal relationships. We are just going to say that companies should be aware that not everyone can work together. However, everyone should be open to trying pair programming.

Double the people, double the cost

Yup, this can be true. According to Agile Alliance, it is estimated that there is 15% more cost due to pair programming. However, no cost can win over a better code quality and programmers engagement.

If pairing hasn’t been done well, then this is most definitely a cost.

Don’t worry, there are far more benefits…

Well, of course, there are! This, as a technique, is used in so many IT companies all around the world. Some of the benefits of pair programming (that we discovered) are:

Synergy rules

The whole story behind pair programming is about synergy. Basically, synergy means that if several programmers work on one project separately and create amazing results, their results won’t be as good as the ones if they were working together. Synergy is all about working together, sharing knowledge, experience, and skills.

Instant code review = instant code quality

Two heads are better than one. By reviewing the code instantly, both sides can find errors easily and find hidden details in the given task.

Less time

Again, synergy never lets you down. Although it may seem like pair programming takes more time, it actually doesn’t if you look at the bigger picture. Developers use their time wisely and, by pairing, shorten the time they would spend fixing bugs and refactoring code.

Sharing knowledge and skills

This is especially the case if the pairing is done between programmers with different seniority — Senior and Junior developers. The one that is more familiar with the task and the component can use that knowledge to provide guidance. Furthermore, a Junior can pick up some tips, tricks, and skills from the Senior developer.

If pair programming is done right, both developers can learn about:

  • codebase, architecture, and design,
  • language and development platform,
  • framework and its tools and
  • testing.

Focusing on the task is easier

If one of the partners is in any way interrupted, the other one can keep the focus on the task. As soon as the first one is ready to work again, the second can intervene, and they can easily pick up where they left off.

Long-term productivity goes up

Of course, this depends on how you measure the productivity. If you are trying to be agile, you’ll probably measure it by counting the tested features that made through per release or iteration. You may find that working in pair produces fewer code lines per week, which is always a good thing.

Amazing for high-risk and new projects

Pair programming is perfect for adopting new technologies and high-risk projects.

Your developers will love it

How could they not? According to Rickard Dahlstrom form Raygun96% of the paired programmers stated that they feel more comfortable working in a pair then they do working alone. They are happier, not just because they have contributed to the project, but because that they get to hang out with some new people and learn new stuff.

So, why are we so into pair programming?

Not too long ago, Vivify Ideas came face to face with two problems:

  • not all of our colleagues knew parts of the system,
  • not all of them had the same level of efficiency, experience, and performance.

Pair programming helped us with that. Creating two-part teams resulted in a productive environment in the long term, where each team member felt like a part of something bigger.

At Vivify Ideas, we have one rule. Give your co-workers a chance to further develop their knowledge and write an excellent code.

Let’s be honest, we have far more rules that the previously stated one, but you get the picture. We want our developers to learn and share their knowledge with each other. If they have a chance to make progress, they are happy. And so are we.

Final tips to make pair programming work

The biggest tip we can give you is: speak your mind. Just like in school — doesn’t matter how stupid you think the question is, you should always ask it.

Furthermore, we suggest you to:

  • tell your partner what you don’t understand,
  • tell your partner when to focus,
  • have/start an argument without worrying,
  • know when to give up and suggest you bring in another pair of eyes to help you.

Also, if you think that you’ll be more productive by doing the task by yourself, don’t be afraid to speak up.