Pair Programming - Do you do it, and who chooses the pairs?

Question

Pair programming appears to be a bit of a marmite topic. Personally I think it can be be a huge benefit if done correctly; but plenty of people, management especially, seem to see it as "wasting" a developer.

A good pairing could give you a good productivity boost (more than the two individuals could produce working alone), and provide a level of "training" for both developers involved. Or you could pair badly and end up with 2 developers doing the work of one, reinforcing the negative opinions some people have of the practice.

So, do you actively use pair programming in work? And if so, who "picks" the pairs? Developers themselves? Technical Lead? Management?

Edit: this is a good blog post on why pair programming can work, for those that are intested: http://cafe.elharo.com/programming/why-pair-programming-works/

I've marked this as a community wiki as there's no real "correct" answer, it's just a topic I'm interested in other people's opinions on.

Answer 1

My team has just started doing this in small increments. We actually started using a version of this when my group was forced to take on supporting SAP ABAP skillsets. My senior developer decided to do a little pair programming with the ABAP contractor. This exercise seems to work for this situation but they may not follow the "pair programming 101" manual or anything.

I've offered my team my support in using pair programming and I'll leave it to them to choose their partners. I won't force it b/c I don't think it fits every situation, particularly some line of business projects with limited developers. However, if they want to try it out, I'm a big believer in developer growth and this fits in that category.

I will agree with you that management, particularly in business driven team, will see this exercise as a waste for the most part, especially during cutbacks and the so called "recession". One thing you can sell them on is that if you participate in this exercise, you will have more code coverage so if there are cutbacks, it will not hurt the team so much.

I'm interested in other peoples experience in this as well, particularly in LOB teams.

Answer 2

I actively engage in pair programming whenever someone needs my help (or, less frequently, when I need someone else's). I think it's great for productivity.

I think it should be done for problem-solving, though, and not just for the sake of pair programming. The goal should be to ensure that no developers are "stuck" at any time and are always moving forward with their assignments.

At my job, developers pick their own pairs based on whoever they work best with and whoever is more likely to be able to help solve their problem quickest. The result is that we all learn from each other and share solutions to problems, thus leading to less necessity for pairing in the future for similar assignments and more productivity for all.

Answer 3

We pair program all the time at my job. When initially introduced, every dev picked a partner every morning (and optionally, again in the afternoon) - the only real rule was you couldn't pair with someone you worked with yesterday.

It led to a great spreading of knowledge and a lot of people got up to speed quite quickly. Now things have loosened up somewhat and we've been slightly balkanized, so I tend to pair with the same guy all the time, but we work very well together. We still grab other members of the team to look over things, or to bounce ideas off of. Even though it's not the same level of pair programming when we all mixed it up all the time, it still feels far more productive than when I sat by myself.

I guess that since management split us off into our specialty area, they chose that the two of us would work together, but it makes sense, as we're good friends and worked on a lot of the same small projects together even before we started pairing. I think the choice was made within technical management, not PHB-level management. The core team of developers still picks partners every morning.

I wish I could remember who pointed out to me that the bottleneck in pair programming isn't the typing, but the thinking - the thinking happens so much faster when you have a person to bounce the ideas off of. The proof for management came when they saw how much the actual quality improved (although I think they still fight against the idea of it, even though they've seen the results).

Answer 4

We used to use pair programming in my previous job. We chose who to pair with ourselves. The benefits we got out of it wasn't quite what you listed. You don't, in my experience, get the kind of productivity boost you are talking about. Two developers working together doesn't produce more than two individuals. They might produce more than 1 individual, however, but the other benefits are:

• Often fewer bugs / better design / better adherence to standards: because the code is peer-reviewed as it is written. It's harder to take shortcuts and employ hacks when someone is looking at you, so you tend to write less "dirty" code.
• Knowledge sharing: two people now know this area of code. (Good if one leaves, for example.)
• Great way to bring "the new guy" up to speed on the code.

It's quite a strain on developers to do pair programming effectively, especially with strong-minded individuals, so we used to let people "rest" and work alone as well.

Answer 5

You are all using pair programming in wrong way, the best way is to have whole team in front of one computer all the time. its 6(if team has 6 people) time more productive and since everybody loves to work without any breaks its helps morale too.

Answer 6

The link provided gives "reasons" that pair programming is like magic. After reading some of those it is clear to me that what the author cites as benefits or magic is really just hiding other problems...

Specifically the headings:

"Mask out distractions" and "Guaranteed Focus" cite reasons to do pair programming, but i would argue that pair programming in those cases just hides the problem(s). Rather than fixing the deepr organizational problems and work habits, you put two people together and call it "fixed"? Nope - that won't fly with me.

Answer 7

An excellent blogpost by Misko Hevery on what Pair Programming is not here.

Answer 8

We do pair programming where I work most of the time. The team itself picks the pairs as sometimes it is a question of who has bandwidth, who hasn't paired recently, or some other factor that drives when some should get together.

It is useful in a couple of ways to my mind:

• Discourages individual code ownership as it is a pair writing the code usually. The team's code base is kind of encouraged as different pairs refactor the code base to be somewhat homogenous. This is a rather important item that I'm not sure how well management and others would see this.
• Knowledge is spread to multiple individuals when a task or story is done. This prevents there from being specialists as it isn't just one person that works on something generally.