I just did a class project for a databases class with my friend, in a style that would qualify as pair programming. The project was to implement a B+ Tree. We''d take turns writing code, with the other commenting and pointing out bugs/mistakes. At design time we''d both suggest what we thought was good, and choose the best of the two(or compromise). We''re both at similar skill levels, and I must say it worked excellently - we both caught bugs that the other person wrote, and having another perspective on the design side also really helped. We finished the project in record time, and only had one thing to fix(where we didn''t read the spec thoroughly enough). We didn''t have any bugs that weren''t caught very easily with two pairs of eyes.

So that was very much a positive experience.

With my junior project team, we sorta 3-person round-robin pair programmed. It did get boring sometimes, but that''s probably because we stayed up for 14 hours straight once the night before the midterm.

We swapped coder/watcher/thinker every 15 minutes or so... and since everyone knew what code we were working on, there wasn''t really a "what was I working on again?" problem. If someone forgot where a certain line of code was, the other two would be able to tell him.

For most of the independant sections of the project, we worked separately. The part that we XP''d on was the GUI, since it was the merging-point for all of our individual sections.

quote:Original post by antareus
I don''t mean to make this into a bash-pair-programming fest

Well, what you did wrong is epitomised in statements like `You have one person programming and the other just watches''. Obviously, none of the literature describing XP / Pair Programming advocates that, so if it''s what is actually happening, then you are clearly not pair programming.

You should ask questions like...

• how does/should PP work?


• when does/doesn''t PP work?


• how might PP benefit you and your team?

You might conclude that there are benefits to be had from pair programming, but your current team are unable to reap those benefits since they are culturally unsuited to pair programming, for example. That shouldn''t warrant writing off pair programming altogether.

quote:
I''d like to hear positive experiences about it as well. I think the big problems at my current place are:
1. different status in company (intern vs. fulltime employee, a very new one, but still)

There''s still benefit to be had in such a scenario. I''ve pair programmed with junior programmers and it depends on how proactive they are in the role. On the one hand, the junior member might ask `why are you doing it in that way''. Having to externalise the reasons for a decision is good on a couple of counts: i) it means you have to actively reason about your decision, effectively you should be able to justify it; ii) the junior member is learning valuable knowledge, which could form part of a wider `apprenticeship'' type scheme.

Going off on a tangent... I believe organistions need to support their interns and juniors in such a manner, but I don''t see much of that actually happening. What usually happens is they take them in, send them on a crummy several-week course, and then throw them into a project as an `analyst-programmer'' or `software engineer'' with very little support. And industry wonders why there''s such a shortage of good developers!

quote:
2. ego (mine)
3. reluctance to accept pair programming (probably mutual)

Many programmers are reluctant to trust other programmers. You have to do something about that yourself. Your own personal attitude might be caused in part by the general culture of an organisation or a team. There''s often not much you can do about that. Pair programming, and XP in particular, requires that you trust the other members of your team. That might mean the team needs to be hand-picked for the job.

quote:
4. triviality of project (clean others code)

Pair programming doesn''t mean that you spend each and every day sitting in a pair at a terminal. You use it when you can benefit from it. Perhaps you might have an heuristic which says `we always use pair programming when writing production code'', which frees you up to carry out prototyping and experimentation in whatever manner suits you, and then you can bring lots of ideas to a pair programming session. Or maybe you only bother with pair programming for particular sections of a project. Or maybe you use it as a mentoring device, as I suggested above.

quote:
I need to check into the narcolepsy bit though, fairly serious, I just pass out in class sometimes when I''m bored.

Try going to bed earlier!