DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
11 Monitoring and Observability Tools for 2023
Learn more
  1. DZone
  2. Culture and Methodologies
  3. Methodologies
  4. Behaviors To Avoid When Practicing Pair Programming

Behaviors To Avoid When Practicing Pair Programming

Pair programming requires collaboration from both parties. Engagement in the task at hand occurs when both are focused, collaborating, and avoiding distraction.

Matheus Marabesi user avatar by
Matheus Marabesi
·
Feb. 25, 23 · Opinion
Like (5)
Save
Tweet
Share
3.41K Views

Join the DZone community and get the full member experience.

Join For Free

When two people get together to write code on a single computer, it is given the name of pair programming.

Pair programming was popularized by the eXtreme programming book by Kent Beck, in there he reports the technique to develop software in pairs which spiked the interest of researchers in the subject. Lan Cao and Peng Xu found that pair programming leads to a deeper level of thinking and engagement in the task at hand. 

Pair programming also carries different approaches. There are different styles of pair programming, such as the drive/navigator, ping-pong, strong-style, and pair development.

All of them are well described by Birgitta Böckeler and Nina Siessegger. Their article describes the approach to how to practice each style.

Here, we will focus especially on only two of them: the drive/navigator and ping-pong, as it seems that both are the most commonly used.

The objective is to have a look at what should be avoided when developing software in pairs.

First, we briefly introduce each pair programming style, and then we follow the behaviors to avoid.

Driver/Navigator

For my own taste, the driver and navigator are the most popular among practitioners. In this style, the driver is the one that is writing the code and thinking about the solution in place to make concrete steps to advance in the task at hand. The navigator, on the other hand, is watching the driver and also giving insights on the task at hand.

But not only that, the navigator is the one thinking in a broader way, and she's also in charge of giving support.

The communication between the driver and navigator is constant. This style also is the one that fits well with the Pomodoro technique.

Ping/Pong

Ping-pong is the style that "embraces the Test Driven Development" methodology; the reason behind that is the way in which that dynamic works. Let's assume we have a pair that will start working together, Sandra and Clara. The ping/pong session should go something similar to the following:

  • Sandra start writing a failing test
  • Clara makes the test to pass
  • Now, Clara can decide if she wants to refactor
  • Clara now writes a failing test for Sandra
  • The loop repeats

It is also possible to expand the ping/pong to a broader approach. One might start a session writing a class diagram, and the next person in the pair implements the first set of classes.

Regardless of the style, what is key to the success of pair programming is collaboration.

Behaviors To Avoid

Despite its popularity, pair programming seems to be a methodology that is not wildly adopted by the industry. When it is, it might vary on what "pair" and "programming" means given a specific context.

Sometimes pair programming is used in specific moments throughout the day of practitioners, as reported by Lauren Peate on the podcast Software Engineering Unlocked hosted by Michaela Greiler to fulfill specific tasks.

But, in the XP, pair programming is the default approach to developing all the aspects of the software.

Due to the variation and interpretation of what pair programming is, companies that adopt it might face some miss conceptions of how to practice it. Often, this is the root cause of having a poor experience while pairing.

  • Lack of soft (social) skills
  • Lack of knowledge in the practice of pair programming

In the following sections, we will go over some miss conceptions of the practice. Avoiding those might lead to a better experience when pairing.

Lack of Communication

The driver and navigator is the style that requires the pair to focus on a single problem at once. Therefore, the navigator is the one that should give support and question the driver's decisions to keep both in sync.

When it does not happen, the collaboration session might suffer from a lack of interaction between the pair. The first miss conception of the driver/navigator approach is that the navigator just watches the driver and does nothing; it should be the opposite.

As much communication as possible is a sign that the pair is progressing. Of course, we haven't mentioned the knowledge variance that the drive and navigator might have.

Multi-Tasking

Checking the phone for notifications or deviating attention to another thing that is not the problem at hand is a warning that the pair is not in sync. The advent of remote pair programming sessions might even facilitate such distraction during the session.

The navigator should give as much support as possible and even more when the driver is blocked for whatever reason. Some activities that the navigator might want to perform:

  • Checking documentation for the piece of code that the driver is writing
  • Verifying if the task at hand goes towards the end goal of the task (it should prevent the pair from going into a path that is out of scope)
  • Control the Pomodoro cycle if agreed

On the other hand, the driver is also expected to write the code and not just be the navigator's puppet. When it happens, the collaboration in the session might suffer, leading to a heavy load on the navigator.

Computer programming Programming team Software development process Test-driven development

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Top 10 Best Practices for Web Application Testing
  • Fargate vs. Lambda: The Battle of the Future
  • 10 Easy Steps To Start Using Git and GitHub
  • Little's Law and Lots of Kubernetes

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: