On Pair Programming: Excuses - Part 1
You definitely should not try pair programming. It’s too hard and there is no way putting two people on the same task is more productive or effective than having everyone work on their own task. Having all of our project tasks in progress means we are getting tons done, right?
Not necessarily. I’ve been pair programming pretty regularly for a little over a year now on a number of different projects and there are definitely a lot of excuses made as to why pair programming does not work. Here is Part 1 of what I’ve heard or read about, and what was contributed from the audience during my talk at Agile Day 2012, along with a few arguments or solutions. Part 1 will be more focused on programmer excuses. Part 2, to follow, will be focused on excuses made outside of the programmer role, from the business perspective.
Programmers are Introverts
Yep, many of us are, myself included. It can make me nervous. With pair programming you build a relationship with your pair partner. You gain each other’s trust. Pair programming is a social skill that needs to be learned. It gets better as you become more comfortable pairing and get to know your partner. You build a relationship and gain each other’s trust. You learn to lean on that safety net and you start taking more calculated risks that build quality in and be innovative early on.
I have a personal “bubble‚ and I don’t want you in it
I suffer from the personal “bubble” myself. I learned early on that if you are set up in a one person cubicle with two people shoved in and one hovering over a shoulder, you are not pairing. It’s also horribly uncomfortable. Set up a pairing station with two chairs, one very large or two decent sized monitors, two keyboards, two mice, all attached to the same computer. At one client, we all were given our own laptops, a keyboard and a mouse, but instead of everyone getting two monitors, there was a large monitor dedicated for each pair. You don’t have to worry about passing the keyboard and mouse back and forth. Just steal it.
You’re going too fast for me to keep up
If your pair partner is going too fast for you to keep up, stop to ask questions. Ask why. Get explanations for certain approaches. Slowing the other person down a little has the added benefits not just of knowledge transfer to you, but also giving you both the opportunity to give a solution some thought. Many times, trying to explain something in words, out loud, you or your pair partner will find something great or not so great about that solution.
You’re going too slow and I’m getting bored
If your pair partner is going too slow for you and you are getting bored, put your teacher/mentor/coach hat on. The pace will increase once the comfort level does. Switch pairs more frequently. And if the comfort level does not improve, it’s possible that this is not a good pairing.
My pair partner is way older/younger than me and our styles/pace/knowledge don’t jive
This is one suggested by the audience at Agile Day 2012 and I thought it was pretty good. There was a decent spread of age in the room, so someone much younger actually spoke up and said that while this can be intimidating it always provides a great learning opportunity. From the other perspective, one way of looking at it would be that it is a mentoring opportunity to share your own knowledge with someone else who doesn’t have the experience you have.
My partner is always multi-tasking on a second computer
Stop. You are not pairing at this point. If someone is multitasking, it’s likely that you both need a break. Or if it’s critical to the task at hand, get both people involved if you are doing a stack overflow search or crafting an email to a client.
My pair is a keyboard hog
A simple and usually effective solution to this one is to use the ping pong pairing approach where one person writes a test, the other implements and then writes the next test and so forth.
My partner is telling me which characters to type!
You aren’t pairing. Find ways to get both of you engaged. Use the ping pong approach. Take a quick break/walk – together or alone – away from the computer. Have open communication. Open your mouth and say something. Have an opinion and voice it. If it is really bad, get up and walk away to make it obvious that there is no pairing happening. If you are being micromanaged, ask for more details beyond what characters to type and reasons why.
My team is distributed and remote pairing is hard
Yep, it is. Here are some tools I’ve found useful:
- gnu screen/vim
- ichat + IDE + headset
- Skype (voice only) + screen sharing tool
- MS Communicator/remote desktop + voice
- Join.me – voice + screen sharing
- Invest in a decent set of headphones and a microphone
- Facetime
- Google Hangout
My team sets their own hours
Set a common hour or two or three per day/week for pairing. You could also pair people who do have the same schedule.
I’m getting sick of my pair partner
Rotate pairs frequently, but beware of the effect of this, which is known as promiscuous pairing, where team members don’t learn enough about the task to be able to support it in the future because pairs switched too frequently. Use the “pair stair” to ensure everyone is pairing with everyone else evenly. You will quickly notice when two people never pair together.
My current team aims to swap pairs every couple days by swapping in a new person to the story once the most recent person has become comfortable enough to carry the story on. This allows you to keep some continuity as well as still build up some knowledge about an area of the system. So far it is working well for us and solved the problem we were having of never swapping pairs and our strong dislike of switching every single day.
My pair partner smells
Basic hygiene, people! Shower, wear deodorant, and brush your teeth. I have enacted Team Gum, a bucket of gum dedicated to the team for after lunch purposes. Also, keep team lysol wipes and hand sanitizer handy – not for showering but for reducing germs, especially during flu season.
Not convinced pair programming is effective?
Tell me why in the comments. I know that pair programming has it’s place, but I am interested in when you use this practice and when you don’t and why.