Our resident agile activist, wrote about recent retrospectives and some techniques. We have been pair programming for so long it rarely comes up as a question as to whether we should be pairing or not. However, we constantly ask how can we be more effective/productive in our use of pair programming. So we figured we would share some of our thoughts.
Here are items our team identified as reasons to pair program or factors that helped making pair programming easier to do.
Supporting/Driving
- Instant code review
- Distributed knowledge
- Cross pollination (ideas/skills)
- Higher energy
- Increased accountability
- Better focus (less waste)
- Trust/team building
- Increased code quality
- Improved communication
Here are items the team cited as making it difficult to pair program consistently or as detracting reasons to not pair program.
Inhibiting/Restraining
- Unequally yoked pairs
- Distractions (phones, laptops, noise, environment, etc)
- Watching someone else code (boring)
- High cost to client/lower productivity
- Fear of being vocal (accountable)
- Mis-aligned schedules/routines
- Personality/Hygiene differences
- Odd number of people
- Consensus issues
Out of these factors positive and negative the team agreed on some internal standards regarding pair programming in hopes of tipping the positive factors higher than the negative factors and get the most productivity out of pair programming.
Standards
- Switch pairs regularly
- Switch drivers (minimum every hour)
- Small breaks more frequently
- Identify follow-up information for later study
- Ask why. Don’t assume.
- More distributed skill/experience levels in pair selection
- Identify strengths to pair appropriate to the task at hand
- Identify weaknesses and address via books, groups, brownbags, etc)
- Have empathy for your pair
- Same person should be solo consistently if uneven numbers
- Odd man out should be doing research, simpler tasks, etc
- All unpaired code requires peer review
- You will be shot if you are without a pair for more than 1 hour
Does your company pair program? What are your restraining factors? What are your driving factors? Do you have standards/guidelines (written or informal) on what is expected of programmers pairing?
I've pair programmed before. Specifically on bits that were complicated – SQL cross tabulation queries for example.
Pair programming seems like quite an expensive luxury though. Do you have any ideas on the ROI? Do projects need to be a certain size before pair programming makes sense?
Incidentally, looks like you have a really cool thing going at Integrum. I'm part of a group of six web freelancers who share office space and work. It's so awesome to have geeks to hack with. Looks like you have the same thing going on over there.
I was just commenting today that when I first started hanging around with the Integrum guys I though pair programming was stupid and a waste of one person's time. But I was very wrong. The productivity benefits are so obvious to me now.
First, you have someone for which you are accountable to, so you don't spend three hours surfing, tweeting, and emailing. Second having a second set of eyes keeps you from spinning your wheels on a problem with blinders on. And lastly, because of the first two, your project gets done far more quickly than a singles.
I would estimate that a single programmer will take as many hours to complete the work but take twice as long (from beginning date to end date).