1. Pair Programming

4. Pairing Developer (Driver) Developer (Co-Driver) Business Analyst 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.

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

6. Driver & Strategist Rotate positions Rotate 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).

7. Pairing Concepts While 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.

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

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

14. Pair Programming Misunderstandings

16. Pairing Practices

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

21. Remote Pair Programming

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

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

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

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

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

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

29. 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."

30. References: http://en.wikipedia.org/wiki/Pair_programming http://www.extremeprogramming.org/rules/pair.html http://xprogramming.com/Practices/PracPairs.html http://martinfowler.com/bliki/PairProgrammingMisconceptions.html www.pairprogramming.com http:// c2.com/cgi/wiki? PairProgramming