I am always amazed at my fellow developers who claim how pair programming is “better”. Better because it increases code quality, reduces knowledge silos and increases collaboration. This recital sounds all well and good on the surface but the benefits seem to favor business objectives in the short term over the longer-term satisfaction of the employee.

Extreme Programming (XP) and more specifically pair programming (PP) in recent years has attracted significant interest in the technology community. Pair programming is when two programmers work together at one workstation. One programmer writes code while the other, the observer or navigator, reviews each line of code as it is typed in, switching roles frequently.

It was something theoretical (or so I thought) I had learned about in my Introduction to Software Engineering class in college. I thought it would stay in my textbook. Sure enough it is showing up everywhere as the latest management fad right along with open work spaces. I want to discuss the very real negative side effects this practice can have and how we might address the drawbacks and still achieve the perceived benefits pair programming provides.

The Benefits

No company is going to pay some of the most expensive resources (developers) they can hire to double up on everything they do unless the benefits outweigh the cost. So let’s break down the perceived benefits:

  • Increased code quality: Real-time code reviews as your partner types the code.
  • Reduced knowledge silos – Frequent rotation of the pairs increases everyone’s understanding of the code base.
  • Increased discipline – Pairing partners are more likely to “do the right thing” and are less likely to take long breaks.
  • Less interruptions – It is harder to interrupt two people who are already talking and working and therefore less likely to be interrupted by something unrelated to the task at hand.
  • Resilient flow – Flow is a mental state developers get into when they are “in the zone” and coding. Restoring flow after an interruption is easier when you pair because you have two minds working on the task so it’s easier to remember where you left off.

The Problems

I wholeheartedly agree without hesitation that pair programming can produce all of the benefits mentioned above. The problem is most of those points are an ideal case. They are also tilted in favor of the company. The issues I outline below are very real concerns.

The predominant opinion I get from my fellow developers is pairing is fun and provides all of these great benefits but their indirect actions and behavior suggest otherwise. After a long day of pairing, one person might have a sigh of relief or appear frustrated. The days can appear to be much longer. So why then, do these same developers agree pair programming is so great? Are they truly getting satisfaction on a personal level or is it because of the benefits they have been taught it promises to bring?

I think we can all agree we want to enjoy what we do for a living otherwise companies won’t get the best possible results and employees will feel unsatisfied. Employment relationships are a two way street and respecting the way people learn or work goes a long way to employers getting the best out of their workforce.

I have pair programmed for about 15 months now so I have firsthand experience. The issues below I have personally experienced or observed. I attempt to address these concerns with a potential solution below.

Personality Issues

It’s one thing to attend meetings and address interruptions as they come up. It’s a whole different animal when everything you do has to be funneled through your partner. You also get to know whether they brush their teeth in the morning because you smell their breath. You are likely to get sick when anyone in their family gets sick. If one person approaches things from a different angle and the other disagrees, it is constant friction to get to the end result.

Work Schedules

You come into work at the same time, take lunch at the same time, take breaks at the same time and leave at the same time. Expecting two people to synchronize their working context is asking for tension and stifled innovation as a result. Human beings are unique creatures and placing them on a factory line of row after row of computers is a great way to make everyone feel like they are just a cog in the machinery.

Everyone Only Knows a Little

If your team maintains several projects, rotating developers across all of those projects can give everyone general knowledge. Sometimes I felt like my pair and I were brought in to insert some code for a small new feature or bug fix without understanding the whole system. It felt unsatisfying that we might not be doing things consistently with how the original developers had structured things due to the lack of depth in our knowledge about the code base we were touching. I suppose this has more to do with frequent story rotation than pairing.

Innovation Declines

Pair programming sacrifices innovation for code quality by increasing focus on the task at hand. A large part of software development is a learning process and everyone learns differently. Some people learn best by reading while others learn better by listening. When I come across a problem with an API or a framework I want to be able to read it at my own pace, digest it, and then take action based on that information.

With pairing, if you take too long the other person is likely to jump in with some comment or thought. This is great in the spirit of keeping things moving, but fragments the ability to have deeper thoughts (i.e. architecture/design, alternative solutions etc.) since the other person would be waiting on you to say or do something. This same issue arises when a team supports multiple projects and the pairs are constantly rotated. I never felt like I was able to make meaningful contributions to those projects because I would only work on a user story for a very small portion of a larger system so I lost some context.

Some proponents say pairing helps them stay focused all day instead of checking their personal email or social media. Anyone you ask knows I can come in and work from starting time to quitting time and breaking only for lunch or the restroom without an issue. Why should I be forced to watch someone else do their job when I have no problem focusing on my own work?

Fuzzy Performance Evaluations

So you’re happily rotating pairs and discover that your annual review is coming up. Some will argue the team should get the benefits of knowledge sharing. The company who hires the team might be trying to eliminate knowledge silos but it diminishes the work of the main contributors. It’s a bit like communism, the owners of the society get luxury beach-houses while everyone else is a “team-player”.

I don’t consider myself to be a “cowboy developer” who needs to sweep in and save the day either. I find those types of people just as difficult to work with. However, I do believe you should be compensated based on your contributions without the dilution of others, for better or worse.

Downsizing!

Most companies treat IT like a cost center instead of the business-enabling profit centers they should be in today’s business landscape. When you decide to adopt pair programming you have just decided to help your company make future downsizing decisions much easier.

The folks in HR have the difficult decision of deciding who to cut when business is slow and now they have the perfect target. They see expensive development resources doubled up. Plus everyone on the team knows a little bit about all of the projects so the decision is even easier. Proponents will argue that both people are necessary but when only one developer is touching a keyboard at a time, the balance sheets only see the numbers.

It will be easy to target teams who are pair programming for layoffs but harder to choose which people on the team to let go. Keep in mind everyone has contributed to everything you have worked on. So if performance evaluations are now based on your social skills in pair programming instead of what you actually accomplished, now the company has the chance to shoot itself in the foot by letting the wrong people go – the main contributors.

I personally loved being able to go deep on a single project or code base. While it may not always be the case, most of the time a code base gains consistency when one person is making the architectural decisions. It also makes the decision to cut someone based on their contributions instead of arbitrary equal input harder (see communism in Performance Evaulations).

A Potential Solution: On-Demand Pair Programming

On-demand pair programming is an extreme programming (XP) practice coined by Adam Fisher. At least I have never heard anyone else use it and it sounds cool. So there. It states that:

  • Developers will work alone.
  • Developers will come together and collaborate on issues only when needed.
  • Developers will continue to rotate within a single project to different areas of the code base to reduce knowledge silos while also gaining deeper context of the system they are working on.
  • Code reviews occur for every check-in. Tools like UpSource make this task extremely flexible and distributed. It doesn’t have to be detailed and involved, just ensuring good quality tests and adherence to the code base’s architecture are met.

The biggest benefit proclaimed by pairing is real-time code reviews. Although another person might have to go back and review your code later, you still get the same single set of hands on a keyboard producing code. Chances are good they will take less time to review it and ensure the team’s agreed upon standards are being met instead of sitting by you all day while you do your job.

That’s the critical part though. The team must come to agreed upon criteria for code reviews so they are fast and efficient. Forgot to flow that data call through the business layer? See an alternate solution that would work better from a performance standpoint? It’s a review action item for the developer to fix. If disagreement arises about a review, the team should also have a conflict resolution process similar to how pairs do it on the spot (ex. whole team discusses the review/issue). Why not give this a try?

Conclusions

I believe pair programming has a time and place as an effective tool for problem solving. Pairing 100% of the time is just too much of a good thing. Not everyone enjoys pairing. I want to do satisfying work and also do it efficiently.

If your team is truly flexible and open to trying new ways of work, it might be time to give hybrid approaches to pair programming a try. On-demand pair programming as mentioned above is one such alternative that could be evaluated.

Remember that everyone learns and works a little bit differently.

Leave A Comment

Your email address will not be published. Required fields are marked *