Last version of my PairProgramming is like sex presentation.
This presentation was first created as a presentation for students. As they loved the title I kept it. As I don’t want to offend people, the second slide of this presentation I ask the people why they think PairProgramming is like sex.
This is what today’s participants came up with:
- It’s more fun with 2 (more people)
- Share feelings warm & cuddle
- Build knowledge really fast
- Can make you sick if not done right
- Discuss what works/what not
- 2 have more idea’s
- Requires mutual consent to do it
One thing I added:
You can’t learn it from a book.
You can read the AHA wall on flickr (check for the tags to read the post it’s)
Questions that came up during the course :
- Can you PP over skype?
- Do we need somebody to ‘supervise’ the way you do PP ? (Esp in the beginning?)
- What if there’s no option posibility to use some OS/Computer
- What to do if there is a conflict between the two, a discussion??
- It can’t work with any type of character, how do you manage?
- What if one uses AZERTY and another one QWERTY keyboard?
- Doesn’t it make it harder to plan a project or
resourcespeople (Yves reframed resources to people) - Can someone do PP with 1 person and PP for something else with another person?
- Can you get into “the zone” when you’re PP-ing?
- Does Promiscuous Pairing kill the flow? (30′ interupts)
- Why not use PP all of the time?
- PP= More talking
=more annoying for other nearby teams? - Do you plan who is going to do what or how do you choose whose turn it is?
- Can you do PP with > 2 people?
- How do you handle the “Don’t care”?
I answered all these questions during the course, I’m interested to hear your answer.
9 comments on “Pair Programming is Like SEX 2.0”
Some answers from my experience. I didn’t answer all the questions, but I hope it will be easy to match the answer with the question. 🙂
1. I pair over Skype/iChat, but more as reviews than for completing programming tasks. It can slow me down, which forces me to think more and type less, and that benefits me.
2. You could use a supervisor, but instead, consider having a facilitator help you build basic rules of conduct for pairing, put them on the wall in very big letters, then supervise each other.
3. I use two rules for settling disputes: (a) no more than 10 minutes without writing code; (b) use the other person’s idea. I didn’t always do this. Now I don’t worry as much about “going the wrong way”, because I feel comfortable in my ability to change direction later.
4. I have only met one person (out of a few hundred) who just can’t work in pairs. It hurts him psychologically. Either I’ve been lucky, or it’s rare. That suggests to me that if we set a plan to pair for 3 months, and all agree to it, then people will either learn to appreciate it, learn to tolerate it, or leave. All three outcomes are manageable.
5. AZERTY v. QWERTY: add a keystroke to change keyboards quickly, or use two physical keyboards. You’ll get used to switching.
6. I find it becomes easier to plan projects, because we make plans based on teams instead of individuals, so that when someone goes on vacation or becomes ill, our plan has a better chance of remaining valid.
7. I get “in the zone” by trusting that my pair partner will help us make fewer mistakes. This trust took time to develop.
8. I find that frequent breaks (pairing, Pomodoro) can interrupt flow, but more often, it interrupts me from going too far in the wrong direction. I guess everyone experiences that differently. I haven’t measured, but I feel like it gives me an overall benefit.
9. I think we can pair on all production work. Why not? If both people want to pair, then let’s pair.
10. When I focus with my pair on a task, I don’t hear the people around me.
11. I have done mob programming (8 people and a projector) to help start a project. I have done triple programming, where I paired with one person while writing code and the other person while testing. We did it for only an hour, but I enjoyed it.
12. When my pair partner doesn’t care, then I don’t get in the zone, because I don’t trust them to help us make fewer mistakes. I won’t pair with that person.
thank you J.B.: these answers are inline with my aswers.
I love your answer to 3. I did not think about that. yes discussions are good but code is better.
8) Good catch.
9 I said because it can be exhausting.
12 was more about a general I don’t care. Were I said that pairing might help them to care. Your answer makes me think. how do you get out of this circle?
* Can you PP over skype?
Yes — or other similar screensharing technologies (iChat) that allow you to switch control. @jbrains and I did pairing for a code retreat a couple of months ago.
* Do we need somebody to ‘supervise’ the way you do PP ? (Esp in the beginning?)
Might not be a bad way to more quickly learn from someone else’s tips and techniques. But even better, just switch up the pairing so that you gain insights/ideas from other people with more experience.
* What if there’s no option possibility to use some OS/Computer
With no computer to program on, you would have to stretch the limits of the definition of pair programming I suppose. Pair Yapping About Programming — P-YAP?
* What to do if there is a conflict between the two, a discussion??
Try and sketch out the competing ideas in code. Unless the argument is about which beer is best… then you need to take it to the bar and do a double-blind taste test.
I also posted these over here: //technicaldebt.com/?p=940
* It can’t work with any type of character, how do you manage?
Pairing should be optional.
* What if one uses AZERTY and another one QWERTY keyboard?
You could solve that with technology.
* Doesn’t it make it harder to plan a project or resources people (Yves re-framed resources to people)
I would suspect the team that pairs is not that much different than a team that doesn’t pair. Both teams are probably lousy at estimating . Instead of guessing at how PP affects your team, just make an initial guess at your estimates and alter the guess after each iteration.
* Can someone do PP with 1 person and PP for something else with another person?
I don’t understand the question.
* Can you get into “the zone” when you’re PP-ing?
Probably.
* Does Promiscuous Pairing kill the flow? (30′ interrupts)
Never tried it. Let the team try it and see what happens.
* Why not use PP all of the time?
Let the team try it and see what happens.
* PP= More talking
=more annoying for other nearby teams?
It is more annoying for people that are bothered by such environments. I suppose some people prefer quiet.
* Do you plan who is going to do what or how do you choose whose turn it is?
Let the team decide.
* Can you do PP with > 2 people?
You can do whatever you like. Just observe if it is effective or not. I suspect you might find diminishing returns.
* How do you handle the “Don’t care”?
What does this have to do with PP? If you have done everything humanly possible to help someone become a productive member of the team and they are intent on being a-holes; and you have warned them of the consequences of being an a-hole to the team; then fire them so that the team morale is not broken by “one bad apple.”
>>* What if there’s no option possibility to use some OS/Computer
This had to do with the fact that people used different OS at this client.
Some people have never worked on a MAC and had a hard time using it (yes they tried during the workshop, I felt they did great but I had the feeling they felt they failed…)
>>* How do you handle the “Don’t care”?
If you look at my slides, you wil see that as part of resistance against PP I mentioned the “I don’t care” mentality.
IFor all the other resistances I had given ways to deal with it. Not for this one, hence the question. .-)
My PhD looked at the psychology of pair programming.
I was interested in the comment that pairing makes for a noisy environment. In fact, overhearing other pairs had some great side effects in the pairs I studied. Often help or advice was gained. Sometimes pairs switched due to the nature of the problem and people’s experience. The whole teammade use of the peripheral awareness of what each pair was doing,
@Sallyann
Thanks. I did mention that during the course (not your phd but my own experience)
I reminds me of the coffeecorner story in Weinbergs “Psychology of computer programming.”
y