Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Are there specific things that you look out for before getting the team into pair programming? Obviously pairing someone who's great with C++ with another who knows ASP.NET best won't get me far, but how about someone who's great with C++ with another who knows Java best but can pick up C++ quick enough?
What else? Experience levels? Character traits?
At my last job we did a lot of pair programming. We found it was not a good method for teaching/learning. When we tried to use it for teaching often the pair would lag, one would get frustrated.
The best performance was usually from 2 people of similar skill level with sightly differing strengths, approaches and ideas. People would develop a sense for the others strengths and weakness and would be an effective complement as a result.
We also found pairing to not be very effective for simple bugfixes, features. Areas where the work was straightforward and simple.
Then again that's just my experience in one development team.
I've found pair programming very useful for learning/teaching. But don't put a guru with a newbie, the newbie will be overwhelmed and the guru annoyed. You should have one person who knows a bit more than the other, or two persons that know different things. In that case pair programming is a very efficient way of transferring the skill set.
It is IMO least useful when two programmers have worked so much together that they would solve a problem in exactly the same way if they did it separately. Then you are wasting one persons time.
Heh, since my experience on the subject is merely theoretical and I haven't actually got any first-hand experience of any agile development methods, I'll still throw my thoughts to the mill. I would believe that the best outcome from pair programming would be in such situations where the two programmers have a slight difference in their experience and skill levels and have been working in slightly different areas. The "writer" should have less experience than the "reader" to utilize the teamwork the best way. The reason is that the "writer" gets to learn and become much more confident with his/her code and the "reader" gets to share his/her experience to benefit the team and the project. At no point should they feel unequal though; I would imagine that if the "reader" feels less experienced and somewhat lost, then his/her efforts won't be used to their full potential. Active switching of roles, both being able to give and acquire constructive feedback is the key; it's useless to try to pair persons who can't get along that well.
You shouldn't look at pair programming in what language one knows better than the other, I believe if you want a program to be done in C++ pick 2 people that are good at that, or a fast learner, the same goes to any other language/technology.
Try looking at other assets that the two might have, they should have always different approaches, if they fight over ideas that's a good thing because from 2 good ideas a great one might be found, unless it gets ugly.
Also a pair should always be of people with similar skills otherwise one will be doing all the work and the other trying to catch up, worst case scenario it will take double, or more, of the time as if the best person would be doing it all alone, as he will always be explaining what he does.
This is from my experience at university as we always do works in teams, working with people that have similar skills, to me, has always proved to be more rewarding.
There is a book called Pair programming illuminated (ISBN 9780201745764) which describes several aspects of pair programming, among other things teaming up persons with different experience. One of the chapters is named "My Partner Is a Total Loser" and Other Excess Ego Problems.
