Pair Programming, The Good, The Bad, The Ugly

O

In an organization, always two heads are better than one, which means teamwork is more productive than an individual one. But when it comes to promotion, the those two heads only will bang each other. Same is the concept of Pair Programming.

What is Pair Programming?

Pair programming (sometimes called peer programming) is a delicate subject. While some turn red with its love for it, others turn red with anger. It is basically a growing software development technique in which two programmers work on the single block of code. One types and the other one observes, so, there are undoubtedly different approaches and practices to co-operate and finish it. Mostly the one who is typing is called the Driver while the observer is called Navigator. The driver focuses to write and think about the current task which is usually a smaller piece of a bigger task, while the Navigator focuses on detecting bugs and problems, structure and what to focus on next.

This type of division is sone to keep a steady development flow and help share knowledge across the team. There has to be fine coordination between both the driver and the navigator. There are numerous studies that depict the tremendous perks of increased output and productivity and a safe and sound product. Pair programming enhances the learning for both participants.

According to Kent Beck, “Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable for the team’s practices. Pairing”

The Good

  • When two brains focus on single coding, errors and failures will reduce, hence coding will be safer.
  • 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.
  • Fewer errors and other issues will reduce cost and in turn provide us with happier users. Happy users are often equal to more money.
  • With a partner, you’re able to discuss different structures and solutions you wouldn’t come up with by yourself. Hence, better coding will be possible.
  • Pairing means more communication. It improves better spreading of knowledge across the team regarding coding, project, company, workflow and anything else.
  • It’s a huge benefit for newbies. Juniors often learn much faster when pair programming with a senior.
  • It improves better understanding of the task. To have good collaboration, clear communication happens and thus we often get a better understanding of it.
  • Experience sharing will benefit all. Pair programming is all about constantly learning and sharing. 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 level will shoot up. Pair programmers often have a higher degree of confidence since two brains work together, double will be the confidence.
  • New connections. It’s good to work with different colleagues. You’ll get to know others as well as learn from them.
  • It will help you stay focused on a particular coding. Having a constant dialog also helps you to stay focused.

The Bad

Not everything comes with positive aspects only, there are some drawbacks in every matter. Following are they:

  • Not necessary everyone enjoys working together. Some like it alone.
  • Pairing at the wrong time can be both time consuming and inefficient.
  • If one turns out to be a slow thinker/unfocused, it will affect the other one too.
  • More talk less coding. You might end up explaining things that would be faster to just code.

The Ugly

  • Code ownership conflicts. Since two developers are responsible for the code both can feel that the other one is more responsible.
  • Blame games. If an error occurs there could be a discussion first of who did what wrong and then who should fix it or if it should be done in pair again.

When to pair and when not to?

Not all tasks are made for each other. You must pair only if they are worth pairing. Pair according to the requirements. Unnecessary or pairing up wrong tasks can lead to complications. Also, pair according to the nature of the task. 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.

Pair Combinations

Driver-Navigator Roles

Generally, pair programming has been popularized through the driver-navigator technique. It can be either senior-senior, senior-junior, junior-junior and both should be open to switching roles as and when required. But, in this style of pair programming, the navigator instantly loses his or her interest. It occurs when either the person in charge of typing isn’t communicating, or perhaps the reviewer doesn’t want to bother him. Effective communication is the key thing to make this type of programming work. Sadly, this level of interaction isn’t inevitably inherent to a fresh pair.

Strong & Traditional Pairing Techniques

In this approach, the driver does nothing that the reviewer did not direct them to. As explained by Llewellyn, “For an idea to go from your head to the computer it must go through someone else’s hands.”
Whenever the driver requires pitching in the idea, he must handover the system to his partner and then carry out the control from the observer position. This approach completely engages the observer. The traditional approach, on the other hand, requires the navigator to ask for the system to give his input or implement his idea.

Ping-Pong Pairing

One more pair programming pattern frequently employed by developers is the ping-pong pairing. In this approach, the driver drafts a test for behavior and requests the reviewer to apply the behavior. Once implemented, the navigator takes his turn and the new driver jot down the next test for the fresh navigator to apply.

The problem is making time to refactor both codes and do testing is the biggest challenge with this pattern. Implementing a feature can be complicated and it will make testing complex too. It’s simpler to carry on a progressive momentum where properties are being applied, but we also require paying attention to the simplicity of the code so that it can be effortlessly maintained in the long run. The similar idea also applies to the testing part. In short Ping-Pong pairing helps professionals keep an eye on both the coding as well as the testing elements.