Code Library

Pair programming is the practice of having two developers work together to write code. It originated from the idea that if occasional code inspections are good, constant code inspections are better. Many of the practices just described are made easier through the use of pair programming. Learning how to do test-driven development is made easier when working together. Feelings of collective ownership are created when code is produced in pairs. And having the discipline to leave the code cleaner than you found it comes easier when another developer is sitting beside you.

Clearly, there are some benefits to pair programming. That's why I invented it. OK, I didn't really invent it, but I like to think I did. I did happen across it out of true necessity, which is, after all, the mother of invention. In 1986 I was hired by Andersen Consulting in its Fos Angeles office. On my first day on the job I completed a skills survey. I marked myself as "proficient" with the C programming language, even though I was very much a beginner at the language. But, I reasoned, I'm studying it every night after work, and I will be proficient by the time they read this skills survey. Unfortunately for me, they read the survey the next day. And on the day after that I was on a plane from Fos Angeles to the New York office to a project that desperately needed C programmers.

After arriving in New York, I met another programmer who had also been transferred because he knew C. I knew I couldn't deceive him, so I came clean and confessed my exaggeration on the skills survey. "Ugh," he said, "I lied, too." Our solution was that we would work together—pair programming, although we didn't call it that. We figured that between us we were as good as one "proficient" C programmer. And, we reasoned, if we worked together on everything, they wouldn't know which of us to fire.

It worked like a dream. He and I worked together for much of the next eight years at three different companies, pairing as much as possible, especially on anything difficult. We wrote some amazing and incredibly complex products, always with low defect rates W e also felt that even though there were two heads for every pair of hands on the keyboard, we were highly productive when working this way.

Since those early, positive experiences with pair programming, I've been hooked. I knew it was a good way to write code. On the other hand, many of us in this industry (myself included) were first attracted to this work because we could sit in a cubicle with our Sony Walkman playing (yes, it was that long ago) and not have to talk with anyone all day. Even now, there are days when I enjoy nothing more than listening to some loud music on my headphones while code is flowing from my fingers as fast as I can type. Because I still relish those days, I have a hard time ever mandating to a team that they must do pair programming 100% of the time.

Fortunately, most teams have realized that the vast majority of the benefits of pairing can be achieved even when it is not done all day, every day. So, when coaching teams, I always push them to adopt pair programming on a part-time basis; use it for the riskiest parts of the application. I encourage teams to find the guidelines that help them pair enough, while stressing that enough is somewhere greater than 0%, but also acknowledging that I can understand the reasons they may have for wanting it to be less than 100%.

There are many advantages to pair programming, even for teams who do it less than 100% of the time. Although most studies show a slight increase in the total number of person-hours used when pairing, this is offset by a decrease in the total duration of the effort. That is, while pairing takes more person-hours, fewer hours pass on the clock (Dyba et. al 2007). Although projects are always under financial pressure, the overriding concern is not so much person-hours as time to market. Pair programming has also been shown to improve quality. In a survey of studies, Dyba and colleagues found that each study showed an improvement in quality with pair programming. Additionally, pair programming facilitates knowledge transfer and is an ideal way to bring new developers up to speed on the application. It is also an effective practice for working in uncharted territory or solving difficult problems in known parts of the system.



"It costs more; I don't want to pay two programmers to do the job of one . "

Pair programming will cost more in the short term. However, that additional initial cost may very likely be paid back with shorter schedules and with higher quality, leading to lower maintenance costs down the road. Rather than take industry studies as your proof either way, prove this to yourself. Pair on the most difficult modules and see if they have fewer defects and are easier to maintain later, perhaps in comparison to similar modules from other programs done without pair programming.



" We're in a hurry. We can't have two programmers on one task."

Actually, if you're in a hurry this is the time you need pair programming the most. I've already mentioned that pairing leads to shorter project durations (while increasing overall effort, or person-hours). Additionally, there is even some evidence (Williams, Shukla, and Anton 2004) that pairing is an effective way to counter Brooks' Law ("adding manpower to a late software project makes it later"). In other words, if you have an aggressive deadline or are tempted to add people to a late project, these are ideal times to incorporate pair programming.



" When working on a tough problem , I need some quiet time to think through the problem."

Talk with your pairing partner and agree to separate for an hour or whatever you need to think through the problem. When you resume pairing, start by sharing any insights either of you had.



Thing To Try Now
In your next sprint planning meeting, commit to doing some pairing. Make the commitment explicit by adding tasks to the sprint backlog: " Mike and Bob pair for t w o hours," " Mike and Mehta pair for an afternoon," and so on. This is a good way to at least get comfortable with pairing. It is too easy to put off pairing with a vague commitment to try it sometime in the near future. Having tasks in the sprint backlog, though, acts as a constant nagging reminder, and, as a result, is much more likely to result in action.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010