4 Reasons Pair Programming Should Not Be a Standard Practice

By Joshua Render on June 6, 2019 • ( Leave a comment )

Pair programming is two developers working together on the same code at the same time. One writes the code, the other watches. The theory behind pair programming is that it reduces mistakes and technical debt. It is often associated with Agile software development, although Agile specifically does not require it; it is, however, an Extreme Programming practice.

Its effectiveness and actual value are questionable for several reasons.

1. Cost Vs. the Quality Increase

You are essentially paying two people to write the same code. This could reduce the number of errors, but does it reduce them enough to warrant more than twice the cost of a single developer?

It depends. It can, but not always.

Pair programming might make more sense with a newer more junior developer working with a more experienced senior developer. For two senior developers, the quality increase is not likely substantial enough to warrant the extra cost.

2. Personality Conflicts

Two people do not always get along. Your policy at work might be to tell them to “suck it up” and deal with it (A manager’s job, which for some people Agile means a manager should never be telling them to do this), but that is not terribly practical and can hinder or destroy team cohesiveness. If pair programming is adopted, shoving two people together randomly is not always going to work and may result in the exact opposite of the intent.

3. Teams Are Not Likely to Choose it on Their Own

If we let teams choose the best way to do the work (ie – Agile), how many of them would choose pair programming? I don’t know if there exists data on this, so I only have my experience and my experience says – not many. Not many people enjoy having someone sitting over their shoulder carrying out a conversation all day while trying to write code.

Would you enjoy having me sit behind you while writing an email saying, “You spelled that wrong?” every time you fat fingered the keyboard? I hate when spellcheck does that, constantly judging me with its angry red lines for all the times I stumbled on the keyboard.

Books and Educational Material on Extreme Programming

4. Decrease in Productivity

You can’t multi-task. Not really. And neither can anyone else. (Burkus, 2018)

I am a fan of collaboration. I am not a fan of constant collaboration. It has been proven that people can’t multitask. one of the ideas behind Agile is a reduction of multitasking. Focus on a task, get it done, go to the next task.

During pair programming, the developers are expected to keep up a constant stream of dialogue with each other. They need to discuss the code and how to move forward. This creates a scenario where you are both focused on writing code and discussing it, switching back and forth. If you need that much collaboration, pair programming can be one method of obtaining it, but it is often not needed and falls into the realm of over-collaboration.

Reflection

Benefits of pair programming exist, but only in moderation and proper use. Pair programming is not something that should be used all the time in every/most scenarios. A lot of developers don’t like it and have no interest in doing it, it raises the cost of development work, and reduces the productivity of the developers.

But if you find yourself wanting to get new staff or junior developers trained quickly or find complex areas that need special attention, pair programming can be an excellent tool to help get the job done effectively. It can take someone with knowledge of the code, or specialized knowledge in specific areas and help share that knowledge with those who lack the knowledge. It can be a tool to aid in becoming a learning organization. It should just be used sparingly, and never forced upon people. See the article Flaccid Scrum / Flaccid Agile and Technical Debt for an area in which pair programming can be effective.

Sources

Burkus, D. (2018). Why you can’t multi-task. Retrieved from https://www.psychologytoday.com/us/blog/creative-leadership/201811/why-you-can-t-multi-task