Pair programming is a great way of increasing developer moral, productivity, skill, and product quality if it is done correctly. I have been lucky enough to have experienced pair or extreme programming for nearly a year, being paired up with several other developers over that time frame. I am practically a veteran given its very small adoption rate as of 6/8/2011 (I have heard estimates as high as 3% of Agile shops) and that those that have adopted it do so only part time on select projects. My experience tells me that the Wikipedia article on the subject is largely correct.
My Experience in Pair Programming
When I was first told we were going to all start pairing exclusively I was both pleased and disappointed. I was pleased because I have been a big proponent of pair programming even before I had read the ground breaking book Extreme Programming Explained (the first edition) more than 10 years ago. The book was more of an Agile manifesto that bucked many of current trends at the time i.e the Waterfall approach (or heavy documentation - Big Design Up Front (BDUF)).
When I brought the concept up to management at another company at that time (over 10 years ago) they were rightfully very apprehensive to have 2 resources working on one computer but the other Agile stuff they liked. After I had left that company they had started XP and kept most of it except the Pairing. But now, this implementation was a complete burn the ship approach, good bye personal space, good bye personal computer, good bye flexible work hours, and good bye personal research/pet projects/skunk works/email privacy/personal growth and so on. Things that make most developers want to develop – gone?
A typical pairing environment is one large monitor connected to a fast CPU with 2 sets of Keyboards and a mouse sitting on top of a desk large enough to comfortably fit 2 people side by side. The best desk that I know of would be the Geek Desk. To avoid confusion one pair will typically be the Navigator (observer) that is reviewing the code that the Driver is writing. The pairs should switch off who is navigating after a few hours.
The Theory of Pairing
The hope is that by having developers work so closely together the following will take place:
1. Improved code readability.
2. Decreases in coding errors for both software construction and requirement adherence.
3. The company’s standards being more closely followed.
4. Reduction in unnecessary or inefficient routines.
5. Adoption of the best traits and knowledge of each developer by all developers.
6. Long term improvements in overall productivity.
7. Higher quality software releases.
8. A more cohesive team.
Eventually, the goal would be to have no one expert on any given application. No one developer would be irreplaceable as all knowledge would be gained by all developers as pairs are constantly reshuffled. The gain in productivity should make up for the 2 for 1 costs coupled with reduced QA, debugging, and maintenance costs. The book "Code Complete", goes over the numbers rather well and offers other types of collaboration techniques that can have even better outcomes.
I have found that pairing is fun for the most part and have learned a good deal about how others work, think, and code. I believe it has also made me a better coder by thinking through more thoroughly what I am about to do with the knowledge on how others will perceive it. The short term productivity is no doubt impacted but in the end the software releases are of better quality with a better adherence to development standards and requirements. The percentage of overall gain would really depend on how the pairing is managed and would need to be balanced with the following in mind:
- When to pair 100% of the time. I believe this should be never.
- Who to pair with: Novice to Novice, Novice to Expert, Expert to Expert. Are the personalities compatible? I believe if you have people that cannot pair together then one or both are not good enough yet for your "A" team.
- What kind of project: Long term project, short term, maintenance, refactoring, new, etc. I believe it can work in all kinds of projects but as always the key is managing it well.
- High Turnover: There are also many people that would just not want to or just not like to be paired. The turnover rate will probably be very high unless those needs of the individual developer are met. But even so, there are people that do not have the maturity, self confidence, or social skills to make it a good experience. It is probably a better idea to get ride of them anyway if they are not willing to adapt. They will just bring down the moral of the team.
- Lone Wolfs: It is a given that there will be those who try to get special privlidges such as not pairing because they need to work on their own for the benefit of the company or who have bad attitudes when interrupted. No matter how good they maybe they will bring down the moral of the rest of the team. If one person gets special treatment then so should everyone else. At any rate it will undermine any pairing efforts.
Pairing is a Road Fraught with Many Perils
Here are some of the challenges of pairing:
- Each pair should agree to start work at the same time and not be late.
- Each pair should not take phone calls, carry on long conversation, or have other distractions while in a pairing session.
- The driver/navigator should only check their emails at the start and end of their session or during lunch.
- Both pairs need to be mature enough to have good hygiene, manners, and be eager to share and learn. I have experienced people that ate at their desk and leave crumbs all over the keyboard, wrappers and other junk all over the desk.
- Falling asleep is a big problem. Without a physical task to do the body slows down considerably, especially after lunch and staying alert takes great consideration, a well-rested body, and healthy eating.
- It is a good practice to use the Geek Desks to work standing up if staying awake becomes a problem.
- If a project is in trouble of making a deadline then both pairs would have to agree to stay later otherwise it would not be fair to the person that does stay late or works from home. The code would then be out of synch from the pairing model.
- No personal development, research, or pet projects. Google for example gives their employees the option of using 20% of their time working on such things.
- How to conduct performance reviews? Managing becomes more difficult to keep it fair. One pair could say bad things about the other just to cover their own weaknesses. When this happens you could get two unhappy developers and end up losing both or end up with just bad developers when the good ones have just had enough and knows their skill can carry them elsewhere better.
- Sickness: Even worse is when your pair has a cold, you are now bound to get it as well. Instead of losing 1 person to a cold you can lose 2.
Management does not get a free ride when using pairing. Developers do not want to have to babysit others no more than a manager does but it is more a manager's job then a developers. There are also other techniques to use such a Collaborative Inspection, code reviews, target defect refactoring (80% of bugs can come from a few problem routines), TDD or Test Driven Development, and lastly pairing on a select bases for a few hours here and there. All these techniques are much better to manage, review, and get immediate results from without losing good developers and paying for high turnover rates.
Using a tennis analogy, a doubles team can easily bet a single player but each player can become better by working alone for part of their time such as in reading books, hitting against a wall and/or a tennis ball machine. It works the same way in programming if not even more so. Pair programming is perhaps the best way to bring a poor performer or C level person up a few grades when paired with a higher rated person but it will take months and discipline to break the bad habits holding back such a person. In the long run it would be easier to replace this person with a better one if found otherwise pairing is a good option.