Comments on: How Do You Explain Pair Programming?

By: Randy

Randy — Sat, 07 Jan 2006 07:41:41 +0000

Another good wiki reference:
http://fox.wikis.com/wc.dll?Wiki~PairProgramming~SoftwareEng

By: Dave

Dave — Fri, 29 Apr 2005 00:50:44 +0000

Great ideas and a good comments. My comment on pair programming is that the ability to do accurate, individual evaluations (and raises) is not really a very significant issue. Ask your client who is paying the bill if he really cares how accurate your staff evaluations are OR if he cares if the product comes in better, faster, and on budget. My question is related to pair project managing. Paired PMs is a subject that I have not read or heard much about. There are some obvious advantages- continuity, overlap, division of labor. This applies to an organization with a functional PM structure and the PMs have several projects. Any info?

By: Bernard Notarianni

Bernard Notarianni — Sun, 03 Apr 2005 23:18:49 +0000

I will not go to many detailed argument. Just one idea.
All those process, langages, specifications or user stories, all those meetings and discussions, written documents or phone conversations converge to one thing: humans writing some code.
This is the most important task (all the others are here to support this one) and also the most dangerous.
Personnaly, I prefer to have some mate around rather than taking this journey alone.

By: John Keklak

John Keklak — Fri, 01 Apr 2005 19:07:48 +0000

Hi Joanna,
To convince skeptical managers, that is the question…
First it is important to be clear that pair programming is not a general panacea, but a tool that is particularly effective for certain situations. One type of situation where it works well is in a failing project where two programmers work together over an extended period of time (weeks) bringing it to a healthy completion. Another type of situation is where concepts are initially very vague, and the initial work is to firm up the concepts and develop the “vocabulary” and “rules” of the project. I have personally seen the benefits of pair programming in these situations. There are, no doubt, other situations where pair programming has a powerful impact.
Secondly, (risking sounding cynical) it is necessary to focus on what’s in it for the managers. And what’s in it for the managers is quality software delivered on time, with minimal hassle from subordinates and superiors, and with a good prognosis for easy support and maintenance after release. Now the trick is to connect this objective with pair programming. How do you do this? You could start by polling the managers to find out how many would take debuggers away from their programmers. I doubt there would be anyone, since debuggers vastly increase the effectiveness of developers. Then equate — in the effectiveness factor sense — pair programming with debuggers.
Thirdly, it is important to make it clear that pair programming cannot be mandated. Some kind of “carrot and stick” approach works best, with the vast emphasis on the carrot.
Lastly, the managers need to feel they came up with idea of using pair programming themselves. The minute you start making a direct appeal, you’ve lost them, so circling around the issue until some of the attendees start making positive-sounding noises that include the term “pairing up programmers” will probably work best.
Good luck!
John

By: Dave C

Dave C — Thu, 31 Mar 2005 02:59:43 +0000

I think the most effective way to handle performance evaluations is to do a 360 degree evaluation where a selection of peers and the manager evaluate an individual.
So the effect would be that someone who adds value to every pair he works with would get a high evaluation, while someone who alwyas drags down his pair would get a low one.
Turns out this works for normal teams as well

By: Rachel Davies

Rachel Davies — Wed, 30 Mar 2005 19:07:39 +0000

I agree with Alan F. Performance reviews tend to be on the same basis as non-pair programming teams. I do think it’s important to discuss with programmers new to pairing how they will be evaluated and that being a collaborative team player is valued in addition to technical proficiency.
I have an upcoming article the April issue of Better Software magazine that gives a managers intro to pair programming - I will email you a copy when I get home.
Rachel

By: Karen Hoofnagle

Karen Hoofnagle — Tue, 29 Mar 2005 00:55:10 +0000

My company attempts to use peer review and most of the time right now (since we don’t pair), peers don’t pay as much close attention to the programming skills and insights of their teammates as I wish they would.
Pair programming, in my experience, makes peer review suddenly more nuanced and useful because your team KNOWS from daily experience what each member can do well and needs to work on. So-and-so is a lousy or great communicator? Someone else is really incisive and helps you move faster than you ever could yourself? Another person is *great* at working through threading issues?
When pair programming, as in all coding, I don’t think anyone ever really gets usefully graded on “productivity” (not that managers won’t try).
So, we (whether we admit it or not) grade on qualitative rather than quantitative measures. That makes the manager’s job to give some quantitative weight to the importance of each quality in the overall composition of your team. Do you give the biggest raise to the guy who communicates best or to the one that seems to have the most arcane grasp of coding lore? They’re both important. But your organization may need the communicator more than the lore-monger. Or the other way around. I think that’s how raises are usually given out no matter *what* people give lip service to.
Anyhow, I would explain pair programming to those who’ve never tried it (and I miss it myself) as the deepest, most difficult, exhausting and satisfying peer-to-peer mentoring on earth.
Karen

By: keith ray

keith ray — Mon, 28 Mar 2005 18:51:41 +0000

Ron Jeffries used to say that 90 percent of programmers think they won’t like pair programming, and that 90 percent of those who try it long enough to learn how to do it well do come to like it.
I didn’t think I’d like it, but I did. (It does take two to tango - pairing with someone who refuses to talk at all doesn’t work.)

By: Jared Richardson

Jared Richardson — Mon, 28 Mar 2005 17:58:38 +0000

First, Pair Programming teams aren’t permanent. I know of at least one shop that rotates team members in the morning and again at lunch! If you are swapping out who you partner with, there will be no trouble spotting the Good Developers.
Second, to introduce the concept of Pair Programming, introduce the idea and let a few team members try out pairing for specific projects. I’ve found Pair Programming to be a great way (from time to time) to bring a very concentrated focus to a tough problem. This lets people try out the practice and see how it works in their shop.

By: Robert Watkins

Robert Watkins — Mon, 28 Mar 2005 16:24:50 +0000

Over any reasonable time period, pairs in a team will rotate so that every member has had a chance to work with everyone else.
If management is using some form of “micro-credit” system to build up the performance review (e.g. keeping track of each task, and adding up the total at the end of the year), then simply apply the points to each person in the pair - people who do well will still get more, people who don’t will still get less.
I’d flip around the question: how do the managers take into account team work in a performance review now? Why can’t they just do more of that?