Pair Programming Guide

Two heads are better than one — Teamwork within an organization is far from a subversive concept, but in an area where representatives are mostly promoted to work freely, it can be demanding for two developers to hook up.

Pair programming is basically a growing software development technique in which two individuals work on the single block of code. The programmers undertake one of two parts — the Driver and the navigator.

The driver in the process is responsible for diligently drafting code, while the navigator’s job is to review and concentrates on the plan of action.

There are numerous studies that depict the tremendous perks of increased output and productivity and a safe and sound product. However, the opinion differs significantly from one individual to another.

It’s a cold call to persuade some officials to allot the limited programming resources to this technique, specifically since it can be viewed as a misuse of precious resources in the first place. The matter of fact is, pair programming technique can take around 15% longer, yet produces 15% lesser defects (Read https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF for more details).

The purpose of this article is to provide organizations with a basic pair programming guide along with highlighting the advantages and challenges the developers need to overcome with this technique. Excited? Let’s explore!

Pair Programming — Introduction

To recall, pair programming was first brought in as an integral element of the extreme programming software development technique. Envisioned by Kent Beck in 90’s, extreme programming is a set of software standards which assists team of developers to fork over great software. It stresses on exchanging information, clarity, response, determination, and consideration, all of which will eventually points to a decisive pair programming knowledge.

According to 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 to the team’s practices. Pairing”

How it Works?

As mentioned above, pair programming includes two individuals (developers) working on a single system, with one typing and the other one navigating or observing. Generally the one responsible for typing is known as the ‘Driver’, while the other one called the ‘Navigator’ continually revise and review what is being coded or typed. During the whole of their time with each other, the duo invariably keeps in touch, enabling the other partner to participate and help outline the code direction.

The objective is to share the workload between both the participants in order to maintain the constant development stream and also to help spread knowledge over the team. The driver and the reviewer should constantly interact with each other as it will add to the knowledge and efficiency for both the members.

In conclusion, the concept isn’t only about throwing two developers together and instructing them to go crazy. Over the past few years professionals have devised methodologies to utilize in diversified circumstances. Through experience and proper practice, these individuals have outdone and polished these procedures.

Pair Programming Techniques

At Weblab, we’ve been using pairing techniques for quite some time now. Generally we use it for complex pull requests review and coaching and fixing. We’ve watched developers who have never drafted code with someone else, and also witnessed individuals who have been drafting codes in pairs for multiple years. So, I assumed I would jot down some experiences and theorization I’ve developed about pair programming and the most widely used styles associated with this approach.

Driver-Navigator Roles

Generally, pair programming has been popularized through the driver-navigator technique. Ideally both the team members should switch their duties for better results.

In this style of pair programming, the navigator instantly loses his or her interest. That’s possibly because the person in charge of typing isn’t communicating, or perhaps the reviewer doesn’t want to bother him. Many times I’ve observed where the driver put forth ‘just a minute, I’ve got an idea’ and keep on working, the navigator check their social accounts or do some other irrelevant tasks.

Well, to efficiently carry out this style of pair programming, communication is what that makes all the difference. Sadly, this level of interaction isn’t inevitably inherent to a fresh pair. Due to this powerful communication specification, I usually consider this type to be a more transitional way of doing pair programming and I instruct beginners to stay away from it.

Strong & Traditional Pairing Techniques

Strong-style pairing is the approach in which 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 carryout the control from the observer position. This approach completely engages the observer.

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 code and do testing is the biggest challenge with this pattern. In fact sometimes I invest more time on the test refactoring than the coding. 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. Plus, it also helps individuals in doing TDD efficiently.

Recent Statistics

• Around 96% of the pair programmers reported in an online survey that they enjoyed their work in a pair programming environment than working alone.
• Also, 95% of the surveyed developers declared that they felt more confident when they worked in pairs than when they worked alone
• The impact on productivity and output is also positive as pairs generally have more design substitutes than programmers working in pairs. Plus, they also tend to catch the design flaws and errors better than individuals.
• Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% less mistakes

Pair Programming — As a Recruitment Tool

Pair programming used in company interviews is one of the best ways whereby the interview is regarded more like a test of ability. The basic idea is we link up with the applicant as they undergo a coding issue. It’s possibly somewhat different from a conventional pairing in that the respondent is more active for the most of the time.

One of the best things about using this approach is that it’s on a verge of what an actual situation on a task would be. In addition to that, it helps the company get a precise picture of the expertise level and capability of the respondent.

As an interrogator you get an opportunity to observe how swiftly the respondent will take up fresh concepts, their potential to work with other individuals, and most importantly their skill level to accomplish convoluted coding tasks.

Significant Pair Programming Markers

During Pairing

• Let me drive
• Could you assist me?
• Let’s do it together
• Here’s my plan
• What plan do you have in mind?
• How does this code block work? Let’s perform unit test
• I’m tired? What’s up?
• I don’t get the point. Draw me a design
• Did we overlook something?

Take a Short Break

• Can we take a break?
• Can we switch roles?
• Let’s go out for a cup of coffee

Remember

• Don’t force it
• Give your partner an opportunity to drive at the RIGHT time
• Encourage open communication
• Don’t ignore breaks
• Trust
• Identify your mistakes
• Criticize yourself first
• Slow down

Pair Programming — A Final Thought

Is pair programming for everyone? Well, the answer isn’t simple. We all are different, so definitely the outcome will vary. Pair programming works wonderfully for some, while the results are reversed for the others.

Since this technique should augment the consolidation of effort for both the partners, it may not always be the situation. Keep in mind, not every project is suitable for pair or shared programming. The idea specifically works great on the complicated projects where one experienced solo or a team of beginners can handle the task. In this situation, establishing a senior-junior combo might be a great step to refine the junior’s skills and proficiency.

From my viewpoint, there’s nothing bad with the approach itself as it all depends on finding an appropriate combination of programmers for the particular project. Please feel free to leave some comments below to let us know your opinion. We would love to hear back!

by Oleksandr Knyga, Software Engineer

Sharmeen Hayat, author & Data Specialist

Dima Dmytriienko, editor & Brand Specialist