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.
- 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.
- 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.
- 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?