Get certified - Transform your world of work today


Real Pair Programming

19 August 2016

Sandeep Khaira
Wirecard AG

Image source: Wikipedia

What is pair programming?

In pair programming, two programmers work together on one computer or system to achieve a defined goal or objective by applying their ideas through collaborating and communicating with each other. The programmer writing the code is called the Driver, and the programmer who reviews the code and suggests changes in the development is the Navigator. Driver and Navigator swap roles after defined intervals.

Debunking misconceptions

Members on some teams believe that they are following pair programming when two programmers sit together for one or few hours a day. After that period of pairing, both programmers develop code separately on their own systems. Working on different teams, in my experience, is not really pair programming. Pairing within a team is generally visible even to those who are not working with a particular team. Pair programming can be observed when a few pairs are sitting and working together for almost the whole day. They repeat this process until they are finished developing the module they are working on. Pairs are usually sharing the same computer while working on the delivery; in that sense, pairing is visible to outsiders.

Pairs can finish development by following these guidelines:
  • Know that communication is more important than technology and tools.
  • Take turns; swap the Driver and Navigator responsibilities.
  • The Navigator reviews the written code and provides suggestions.
  • Understand the indicative and interrogative moods.
    • Yours / Mine
    • Yours / Mine?
  • Navigator has active responsibility for driving the code.
  • Implement ping-pong programming by using test-driven development.


Achieving pair programming in today’s global environment is a bit tricky. The team has to be more creative to make sure that international team members don’t feel isolated. To achieve pair programming in a global environment, consider the following:
  1. Three constraints exist: network connection, shared coding environment, and peer communication.
    Solution: Multi-user editors, screen sharing, and SSH Terminal access.
  2. Use of technology.
    1. Use VoIP over traditional phone.
    2. Use headsets.
    3. Hold video conferences using Skype.
    4. Use Google Docs for document sharing in a live environment.
  3. Include remote counterparts in local conversations.
  4. Do not turn on mute or turn off video while communicating to other team members.

Pair programming indicators

  • The team’s mindset changes about pair programming.
  • The need for SMEs within the team is diminished.
  • Consistent reports are generated because of equal team contribution.
  • High-quality product development is achieved at more or less the same cost.
  • The team is more self-organized.
  • A decrease in the number of bugs and defects is reported.
  • The team’s skill set is fully developed.
  • The team is more interested in achieving a common goal by sharing ideas.


Many teams believe that pair programming is expensive to follow because the cost of development increases when two programmers develop the same module together. Based on my experience, I agree that the cost of direct development increases, but do not forget that the indirect outcomes achieved through pair programming are far reaching in comparison to the increased development expenses, for the following reasons:
  1. Code has fewer typos.
  2. Two programmers have different perspectives and approaches to developing code; two minds consider varied use cases instead of one mind considering only one use case.
  3. Code quality is improved, as both programmers have varied experience and backgrounds.
  4. Fewer defects are reported due to improved development.
  5. Time is used efficiently when resolving critical issues; there are two minds to work on one problem.
  6. The pair is more focused, and one member of the pair motivates the other.
  7. Communication is improved.
  8. The team is more cross-functional.
  9. There is an increase in self-organization within the team.
  10. Knowledge sharing occurs across teams; hence, the absence of one team member does not so critically impact development.
  11. More and varied expertise is developed within the team.
  12. Team members have better chemistry and deliver better quality.

Negative outcomes

  1. Productivity can decrease in the beginning.
  2. There is less autonomy, as most obstacles are resolved by discussion.
  3. Not everyone is as productive in a pair as they are on their own.
  4. Each pair needs to handle tremendous synchronization while working and taking breaks.
Every team can try pair programming, because it has remarkable advantages. Getting a successful outcome is completely dependent on the team's work setting, product, working style, and a few other factors. Hence, it’s a better idea to taste the cake than to wonder whether it’s tasty.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.6 (8 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up