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

Trending

  • Write a Smart Contract With ChatGPT, MetaMask, Infura, and Truffle
  • Hibernate Get vs. Load
  • How to Handle Secrets in Kubernetes
  • Measuring Service Performance: The Whys and Hows
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Top DZone Article of 2011: I Hate Pair Programming (and your code and you)

Top DZone Article of 2011: I Hate Pair Programming (and your code and you)

David Bland user avatar by
David Bland
·
Jan. 26, 12 · News
Like (0)
Save
Tweet
Share
28.07K Views

Join the DZone community and get the full member experience.

Join For Free

“Are you pair programming?” our manager asked in his snarky tone, while using exaggerated double air quotes to emphasize his skepticism. He then walked away without waiting for a response…

This is merely one example of numerous instances I’ve experienced over the years from skeptics of pair programming.

This isn’t a particularly new concept, and in the past both hardware and software developers worked in pairs on a routine basis. However with the recent popularity (and notoriety) of agile software development, the pair programming debate continues to rage on.

Why does this practice evoke such an emotional response from people?

Pairing fatigue

Pairing fatigue seems to be one of the more common arguments against pair programming. In fact, one conversation I had recently was with an individual who paired for over 6 hours straight and then never paired again. His face scrunched up when speaking about it, so much so that I think he felt actual pain even thinking of it. I inquired as to why he didn’t take breaks, or use the pomodoro technique but he was not willing to divulge the details.

Note: It is important to work at a sustainable pace and to take small, but frequent breaks. This also applies to pair programming!

Single points of failure

One of my favorite quotes from a past employer is “We are not a single threaded organization”. Boy was he wrong, we had single points of failure everywhere! Unfortunately pair programming was viewed with such disdain that it didn’t survive pilot mode. At other organizations I’ve seen people pair and share knowledge in such a way that the single threaded organization remark actually held water. People could step into the code successfully instead of calling a software engineer while he’s on vacation at Disney World with his family. (true story)

Note: It is important to have a shared knowledge of the code base, otherwise your organization may not recover when key team members leave (and they will).

It is too expensive to have 2 people at 1 computer

Another argument against pair programming is that it is far too costly to have two developers work together at the same time. I’ve watched executives make the case that pair programming is doubling their cost to operate software engineering, and then promptly killing the initiative. However it seems the cost of bringing new people up to speed is often overlooked in this equation.

Note: When attempting to realize the cost/benefit analysis of pair programming, contrast the amount of time a new hire takes to get up to speed on his own versus when pairing with an existing team member.

To help visualize this argument I’m making, imagine a pair programming slider.

Pair Programming Slider:
0% []————————————–[] 100%

On the left at 0%, your team members have absolutely no idea what each other is working on within the code base.

On the right at 100%, your team members emphatically hate one another.

Neither extreme fosters team growth, so as with most practices you’ll need to strive to find the correct balance for your team and organization.

Yeah, yeah… give me real world examples

A year ago our development team practiced pair programming at least 4 or more hours of our 8 hour work day. Envision the paring slider at or over 50% every day. This was mostly because we had existing team members with a great deal of domain knowledge transitioning off and new team members transitioning in. And before you ask, yes we did our best to screen the new team members during the interview process. Interviewees were required to pair with existing members to get a feel for what an average day would be like before signing on.

It is now a year later, and we are currently pairing at roughly 25% for 3 days a week, and 45% for 2 days a week. We’ve revisited how we pair at each and every iteration retrospective (2 weeks). This is important because we need to talk openly about how we are working together as a team and adjust things as needed.

We’ve learned a great deal about each other and how we work over this past year.

I’ve found that when we dial back the slider and pair for fewer hours that we tend to communicate less with each other. The team room buzz is reduced significantly during these times, and it is more difficult to keep a pulse on the team as a whole.

I’ve found that having rotating pairing schedules as an artifact of our daily stand up helps keep us honest. We now even ask the question “What would you like to pair on today?” since at times multiple team members want to sign up for the same task.

I’m quite certain we’ll continue to learn over the next year as well.

So in short, before you declare your undying hatred for pair programming, try giving it another shot with some well thought out checks and balances. It just may surprise you.

agile DZone

Published at DZone with permission of David Bland, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Write a Smart Contract With ChatGPT, MetaMask, Infura, and Truffle
  • Hibernate Get vs. Load
  • How to Handle Secrets in Kubernetes
  • Measuring Service Performance: The Whys and Hows

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

Let's be friends: