Pair Programming: The disadvantages of 100% pairing

I've found that while pairing is sometimes useful, it's often not. People, even good programmers, have different brains that work differently, and that sometimes gets in the way of pairing. You get into stupid arguments about the right order in which to do things, or waste time bikeshedding about variable/function names when really you just want to sketch the whole thing out and clean it up later. And that's assuming no one ever mentally checks out. If everyone pairs 100% of the time and you don't have these problems, what you probably have is a monoculture where no one thinks differently. And if you do have those problems, you probably lose more productivity than you gain from someone saying you forgot a semicolon.

The monoculture point deserves elaboration. The job postings for one particular consultancy that does 100% pairing are pretty explicit about requiring everyone to use the same particular text editor. Think of the five or ten best programmers you know--do they all use the same text editor? People say that their company has a "culture", and if you don't fit in then it doesn't matter how brilliant you are. In other words, they place a higher priority on being just like everyone else than they place on being good at what they do. So already, they're handicapping themselves by not hiring the best people. On top of that, they think they have a recipe for a "company culture", but really what they have is a recipe for groupthink. Real cultures have diversity. Healthy, creative cultures are the most diverse of all. So not only are they not hiring the best people, but they're constructing a social environment among the people they do have that effectively makes them more stupid.

100% pairing is probably one of the worst ways to develop this kind of monoculture, because there's even a brain difference between people who naturally are good at pairing and people who aren't. So not only are you excluding the people who don't share your particular text editor and way of thinking and working, but you're excluding those people within the already exclusive population of developers who can pair effectively. And then you complain that it's hard to hire people.

I went to a conference once where someone gave a talk about how awesome his company culture was because they paired 100% of the time and after work they went out to dinner or the bars together and talked about work and came back to work to work on the ideas they thought about during dinner. Someone asked a very insightful question about whether this culture excluded people who might have had families, and they responded that everyone in their company were young, single men. If I ran a company and I discovered that all of my employees were bachelors with nothing better to do at night than hang out with their coworkers and work some more, I would stay up at night worrying about that. What about my company or my hiring practices is so broken that I only hire people exactly like me?

One thing I've found enlightening to think about is that nearly all formal methodological dogmas are promulgated by people who are selling something. Who's going to make more noise--someone with some altruistic desire to advance the state of software engineering, or salesmen? If you convince everyone "agile" is a good idea, then maybe they'll want an agile consultant. If you're going to sell scrum master training courses and certifications, you have to sell the idea of scrum. If you're trying to sell CASE tools and you're not clever enough to design software that can be adapted to different processes, you need to sell people on using the process you designed the CASE tools around. Likewise, if you're a consultancy trying to differentiate yourself from all the other consultancies, you need to sell people on your process, and pair programming is a process that conveniently allows you to double your billable hours. That allows you to fully utilize all your devs on a smaller number of projects, which reduces the overhead involved in bringing projects onboard.

This pretty much nails it. Pairing is a tool in your toolbox. It's not something you should be doing 100% of the time.

I did take issue with two points:

>I can certainly understand the argument that you should be learning things like that in your own time anyway.

No! If you're using a new tool for work, work-time is when you should be learning it. And learning in a pair can be great. It takes patience though. Research, OTOH is harder. It's a lot like reading a book at the same time. Often a strategy of "split-up and regroup later" works well.

>In my experience house cleaning tasks such as investigating why a test is ‘randomly’ failing on the CI machine are less likely to be looked at if everyone on the team is pairing 100% of the time because it interferes with productivity of a story.

You fix this by making those tasks their own, smaller story and throw a pair on it. This is independent of pairing and is more closely tied to your overall process. A granular system like kanban (which has its own problems) shines here.

I have to agree that PP loses value when you have many senior level programmers on the team. The biggest value in PP, in my personal experience, is transfer of knowledge and experience. This applies mostly to teams with huge gaps in experience (juniors vs. seniors) or new team members that need to be caught up to speed with the codebase.

If the talent level is the same (and by talent I mean having the innate passion and ability to learn, not having actual knowledge) the knowledge of the collective team members will eventually equalize through the initial PP sessions.

Like the author said, the context of the team and the general strategy of the company (i.e. maintaining a project vs developing new features) are the most important signals when determining the programming tactics (i.e. PP and self-learning) to reach those goals.

P.S. The link at the bottom of the article (http://blog.jayfields.com/2011/08/life-after-pair-programmin...), provides two great team contexts for when pair programming succeeds and when it fails. Definitely take a read on that.

> You can’t just sit back and read some code. You can’t just sit and think. I mean, you can, but then your pair is just sitting there.

Or bugging you, breaking your train of thought.