As of 2016, I have worked in an scrum based agile environment for over five years for a Fortune 100 company. This comprehensive guide was created as a part of mentoring new resources or new scrum teams to make them aware of pair programming and analyze the benefits and techniques so as to meaningfully use the concept and not just do pairing for pairing sake. Here is a summary of what you can expect to learn from this article.
- What is wikipedia definition of Pair Programming?
- What are the benefits of pair programming?
- What negative things people think about pair programming?
- What problems may arise in a pair programming environment?
- What are some of the good practices of pair programming?
- What are some of the popular pairing models?
- What are some of the situation to pair on?
- What are some of the situations where pair programming might not be beneficial?
- How to detect pairing smells?
- What are some popular pairing techniques (compare with pairing models)?
- When it is not a true pairing?
- How my current team pairs?
- Miscellaneous thoughts and suggestions around pair programming
Definition of Pair Programming:
According to Wikipedia,
- Pair programming is an agile software development technique in which two programmers work together at one workstation.
- One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in.
- The two programmers switch roles frequently
What are the benefits of Pair Programming?
- More time spent upfront but less defects
- Less Defects go into production
- Defects caught early are less expensive
- Improved Quality of Design and Software
- Different background of developers
- Different skill set
- Different Thoughts
- Negotiation during conflict
- Multiple points of view
- Confidence
- Team Building and Communication
- Working as a team towards the same goal
- Continuous informal review of code
- Saves you from separate code review
- More than one person knows what is being implemented
- Better diffusion of knowledge and transfer of skills
- New team members get to learn
- Old team members get to be mentors, coach
- Continuous feedback and development opportunity
- More economical
- Co-ordination between developers is simplified
- No need to setup extra meetings
- More focus and engagement
- Pairs stay focused longer than individuals
- Less Multitasking
- You are less likely to multitask when you are a pair
- Can solve problems faster
- Fewer blockage
- One person’s blind spot might not be a problem to the other guy
- Vacation or emergency situations
- Less dependence on one person
- Work ownership
- Better adherence to organization’s coding standards
- Better design
- Share responsibility and pressure
- Reduced Training Cost
What people also think about pair programming (Myths)?
- Waste of time and resource:
- Two people working on one item while they could be working on two separate works
- Less work will get done
- Cost will double
- Not everyone is equal – new and less experienced resources will slow down the experienced ones
These myth’s are either untrue or partially true on a short term. If you look at the larger picture, you will definitely find these myths incorrect.
What problems may arise in a pair programming environment?
- Conflicts of ideas
- Conflicts of schedules
- Partner not available
- Going over the speed limit
- False sense of confidence
- Not ideal in every situations
- Some research work
- Both pairs don’t know how to implement
- Partners hate each other
- Odd number of developers
- Work is trivial
Good Practices of pair programming:
The following are some of the good practices to keep your pairing healthy, mutual and productive.
- Think out loud
- Switch Pairs
- Switch Roles
- Between story cards?
- Time Sliced?
- Half hour?
- Before lunch / after lunch?
- Between Coding / Unit Testing
- Be a good listener
- Get away from your phones
- Be a good observer
- Do a team work
- Communicate well
- Follow the convention
- Ask Question
- Negotiate
- Accept other people’s ideas if they are better
- Suggest Re-factoring
- Everybody owns the code
Pairing Model:
So, how do you pair? Or how are pairs formed? Based on the knowledge and skills of individuals, there are three possible pairing combinations.
- Expert and Expert Pairing
- Highest productivity
- Greatest results
- Complex solution
- Quick Turnaround
- Expert and Novice Pairing
- Ideal
- Leads to learning and mentoring
- New solutions and ideas
- Novice and Novice Pairing
- Least Optimal
- Still better than two new people working alone
What are some of the situations where pairing is helpful?
The following are some of the examples when the pairing is beneficial. Mind that these are only “some of the” example. There could
- Production defect fix
- New Story Cards
- Complex problems
- Unit Testing
- Code and Database Design
In what situations pairing is not very useful?
- Someone asks you to download logs for them
- A work has trivial or pre-defined solutions:
- Field name changes on an html component
- Creating branches from svn
- Doing builds by pushing a button
- Research work
What are some of the popular pairing techniques?
- Ping Pong Pairing
- Mostly meaningful if you are doing TDD
- If Brad and George are pairing,
- Brad writes a new failing test
- George implements just enough code to pass the test
- George then writes a test that will fail
- Brad implements the code needed to pass the test
- Refactoring is done whenever need arises by whoever is driving.
- Cross-Functional Pairing
- E.g. Testers pairing with Developers
- Or, Testers pairing with Analysts
- Distributed Pairing
- Solves problem of geographically distributed pair
- Developers work via a collaborative real time editor, shared desktop or Cloud Development Environments
How my current team pairs?
- Pairs are decided at the beginning of Iteration
- Pairs Take a story card:
- If a card is 1 or 2 points:
- Pairing is optional, code review is mandatory
- If a card is 3 points
- Person A writes and completes code
- Person B writes unit Tests in addition to consistently being a navigator
- If a card is 5 points,
- Person A writes code until he is tired
- Person B writes code from where person A left
- Repeat this until code and tests are complete.
- If a pair is not found, Tech Key will pair.
When is it not pairing?
- You identify yourselves as pairs but you sit at two different terminals
- One person does work, the other one sit behind playing on the phone or with no interaction
- You split the work and work individually
Pairing Smells:
Not all the pairing might go as expected, or might deteriorate after sometime. These are some of the things to watch for to detect if a pairing has rotten and has start smelling.
- Pair Marriages – You always prefer to work with same person for a long time
- Disengagement – worker /rester pairing
- You agree to whatever the driver does, or the navigator tells you
- Debates lasting longer than 10 minutes with no new code.
- Unequal access to keyboard
- Driver does not explain what he is doing
- Silence – The pairs are not talking
Other thoughts and suggestions around pair programming:
- Determine your pair at the beginning of your iteration.
- Generally done by Scum Master / Iteration Master or Technical Key
- Until pairing goes normal, talk about how pairing is going at the daily scrum.
- It’s a pain, but it works.
- Look for visual indicators such as story cards having only one avatar.
- Ideally, every story card should have two avatars.
- Include pair programming as a part of Definition of Done.
- If you didn’t pair under normal circumstances, your card is not done.
- Have a conversation with Tech Key on why you didn’t pair.
- Get a pair and walk your code with your pair before marking the card as done.
- If you couldn’t pair for some reason, get your code reviewed
- Pull an expert from another team if they have time
- Review does not mean it needs to be done by Tech Key or Tech lead.
- Pull another developer, or even another pair