Pair Programming

Topics:

• Pair Programming• Pairing Analogy • Scientific Studies• Pair Programming Misunderstandings• Ping pong pair programming• Remote Pair Programming• Benefits• Drawbacks• Conclusion

Pair Programming

• ALL code written in pairs at a single workstationo Pairs work together for a day or lesso Developers take turns driving

• Reduces Risko Knowledge shared by rotating pairs frequently

• Constant QA

• Very efficiento second person prevents drift o X hours longer vs. 15X hours bug fixing

(source: http://www.pairprogramming.com)

Pairing

Developer (Driver)Developer

(Co-Driver)

BusinessAnalyst

The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.

is an agile software development technique in which two programmers work together at one work station.

Driver & StrategistRotate positionsRotate pairs

Pairing Concepts

One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently (possibly every 30 minutes or less).

Pairing ConceptsWhile reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

Pairing Analogy

OF WHETHER IT IS BETTER TO DRAW WITH COMPANIONS OR NOT.

I say and insist that drawing in company is much better than alone, for many reasons.

The first is that you would be ashamed to be seen behindhand among the students, and such shame will lead you to careful study.

Secondly, a wholesome emulation will stimulate you to be among those who are more praised than yourself, and this praise of others will spur you on.

Another is that you can learn from the drawings of others who do better than yourself; and if you are better than they, you can profit by your contempt for their defects, while the praise of others will incite you to farther merits.

According to The Economist,"Laurie Williams of the University of Utah in Salt Lake City has shown that paired

programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. (N.B.: The original study showed that 'error-free' code went from 70% to 85%; it may be more intuitive to call this a

50% decrease of errors, from 30% to 15%.) Since testing and debugging are often many times more costly than initial programming, this is an impressive result.“ The

Williams et al. 2000 study showed an improvement in correctness of around 15% and 20 to 40% decrease in time, but between a 15 and 60% increase in effort. Williams et al. 2000 also cites an earlier study (Nosek 1998) which also had a 40%

decrease in time for a 60% increase in effort.A study (Lui 2006) presents a rigorous scientific experiment in which novice–novice pairs against novice solos experience significantly greater productivity gains than

expert–expert pairs against expert solos.A larger recent study (Arisholm et al. 2007) had 48% increase in correctness for complex systems, but no significant difference in time, whilst simple systems had 20% decrease in time, but no significant difference in correctness. Overall there was no general reduction in time or increase in correctness, but an overall

84% increase in effort.Lui, Chan, and Nosek (2008) shows that pair programming outperforms for design

tasks.

Scientific studies

Pair Programming Misunderstandings

• Pairing cuts productivity in half: The more senior the developers, the less proportion of hours they will spend typing during software development. Most productive work happens during their thought processes and communication, which are enhanced by the benefits mentioned.

• Mixing senior and junior developers is ineffective: Even a senior developer can benefit from the benefits of pairing. And the junior developer can definitely benefits and grow much faster. This will be beneficial for the company in the mid to long run. Ideally, the pair should consist of developers with similar or complementary skill level, but it also depends on the tasks involved.

• You have to do pair programming if you're doing an agile process: This is utterly false. 'Agile' is a very broad term defined only in terms of values and principles, most notably in the Manifesto for Agile Software Development. The manifesto doesn't mention pair programming and most agile methods don't make it part of their approach.Since pair programming is a practice of XP it's had a lot of influence in the agile community. As a result it's often mentioned as an agile practice - meaning a practice that's commonly used by people on agile projects. But that's an observation not a prescription.

Pair Programming Misunderstandings

• XP forces you to do Pair-Programming: This is much more nuanced issue. Pair-Programming is one of the practices of XP and has been since its inception. The nuance here is whether XP practices are mandatory for a team that claims to be doing XP. This is actually a much more tricky question than it may seem at first sight. XP, like any agile method, expects a team to choose its own process. In Extreme Programming Explained Kent says that practices are "the kind of things you'll see XP teams doing day -to-day". I would say that pair-programming is usual for XP teams. I wouldn't say that a team that doesn't do pair-programming thus cannot call itself an XP team. I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective. The closest I'd get to forcing pair programming would be to say that if you want to learn how to do XP you should try pair-programming and see if it works for you.

Pair Programming Misunderstandings

• I don't need to try pairing because I know I won't like it: The problem with this statement is that many people have been surprised by pair programming. They gave it a try, expecting to hate it, and found they really liked it. This is further complicated by many people trying out pairing badly - which can give a false impression. Hours passively staring over someone's shoulder in a corner cube isn't pair programming. Make sure you have someone who really knows how coach you, so you can be sure you're evaluating the real thing.

Pair Programming Misunderstandings

• Pair-Programming halves the productivity of developers: My flippant answer to this one is: "that would be true if the hardest part of programming was typing".Advocates of pair-programming are advocates because they believe that a pair is actually more productive that two separate developers. This is due to the continuous discussion and review that pairing introduces. You come up with better designs, make less mistakes, and make more people familiar with the code. All of these things offset having less people typing. Of course, since we cannot measure productivity we can't know for sure. My view is that you should try it and the team should reflect on whether they feel they are more effective with pairing that without. As with any new practice make sure you allow enough time so you have a good chance of crossing the improvement ravine.

Pair Programming Misunderstandings

Pairing Practices     

 

Ping pong pair programming

the observer writes a failing unit test, the driver modifies the code to pass the unit test(s), the observer writes a new unit test, and so on. This loop continues as long as the observer is able to write failing unit tests. The technique can result in the driver role switching as often as a few minutes or less.

Chess Clock Pair Programming

(Kitchen Clock)Pros:

•  Assure everybody gets the keyboard 

Cons: 

• It can be inconvenient to pass the keyboard in the middle of a method

     

10-second rule

The navigator should wait 10 seconds before pointing out a typo. Generally that’s long enough for the driver to correct a typo that’s already noticed. Excessive interruptions are distracting.

Think Out Loud

The driver “thinks out loud” as he/she’s coding. This helps keep the navigator in the loop, and communicates the intent better. It’s certainly not a technique that most people practice without suggestion, however.

Remote Pair Programming

Remote pair programming, also known as virtual pair programming or distributed pair programming, is the practice of pair programming where the two

programmers comprising the pair are in different locations, working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE

plugin.

Remote pair programming might be useful to do pair programming with offshore teams or in open source projects with distributed contributors.

Some teams have tried VNC and RealVNC with each programmer using their own computer. Others use the multi-display mode (-x) of the text-based GNU screen.

Apple Inc. OSX has a built-in Screen Sharing application.

Also of notice, IDEs like Eclipse (Eclipse Communication Framework comes with the Cola plugin, another option is Saros) and NetBeans (NetBeans Collaboration

Project) offer their own solutions. Other alternatives for product such as Visual Studio are wave-vs.net commercial or free Version Add-In, able to enable Pair Programming for Visual Studio, (internally relays on Google Wave Federation

Protocol to enable collaborative editing), or beWeeVee for Visual Studio, still in concept phase.

Remote Pair Programming

• Teamwork• Accept other ideas• Cooperation• Communication • Be a good listener• Name and layout conventions• Respect the 10 seconds rule

Skills to be successfully while Pair Programming

Design quality: Shorter programs, better designs, fewer bugs. Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.

Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they're caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.

Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work. New hires quickly pick up the practices of the team through pairing.

Overcoming difficult problems: Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible, to solve when they work together.

Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.

Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.

Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.

Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email, or other violations of discipline, when they are working with a pair partner. The pair partner "keeps them honest".

Resilient flow: Pairing leads to a different kind of flow than programming alone, but it does lead to flow.Pairing flow happens more quickly: one programmer asks the other, "What were we working on?" Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.

Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.

Drawbacks of pair programming

Work preference: Some developers prefer to work alone.

Intimidation: A less experienced or less confident developer may feel intimidated when pairing with a more experienced developer and participate less as a result.

Egos and potential conflict: Personality conflicts can result in one or both developers feeling awkward or uncomfortable. Differences in coding style may result in conflict.

Drawbacks of pair programming

Cost: There are varying opinions as to whether two developers can be as productive when working together as when working separately (see "Scientific Studies" below).

Tutoring cost: Experienced developers may find it tedious to tutor a less experienced developer. Experienced developers working alone may be capable of producing code that is clean and accurate at the outset, and the benefits of pairing might not be worth the cost of an additional developer in some situations. This may apply more especially when producing more trivial parts of the system.

Conclusion:

The benefits of pairing far outweigh the drawback of having one developer typing at the keyboard in pairing, because the latter only constitutes a small proportion of time

in a seasoned developer’s day. 

Pair programming is not is mentoring   

Pair programming is a social skill that takes time to learn  

The best pair programmers know when to say "let's try your idea first." 

References:

http://en.wikipedia.org/wiki/Pair_programminghttp://www.extremeprogramming.org/rules/pair.htmlhttp://xprogramming.com/Practices/PracPairs.html

http://martinfowler.com/bliki/PairProgrammingMisconceptions.htmlwww.pairprogramming.com

http://c2.com/cgi/wiki?PairProgramming