1. Pair Programming Collaboration in Software Development Process

2. Introduction Two programmers working side by side as stated by Kent Beck in Extreme Programming (XP) in 1996. Objective is to improve software Quality and reduce Time-to-Market. Pairs enjoy problem-solving process and outperform individual programmers. They have greater confidence in their solutions.

3. Pair Jelling Two programmers jointly produce one artifact. One partner is the driver and has control of the pencil/mouse/keyboard and is writing the design or code. The other person continuously and actively observes the work of the driver (watching for defects, thinking alternatives, looking up resources, and considering strategic implications of the work at hand).

4. Pair analysis and Pair design It is important for the pair to collectively agree on the development direction and strategy outlined during these stages. “Two brains are better than one” when performing analysis and design. Significantly decreases the probability of proceeding with a bad design. Other partner can think more strategically about implications of the design. Avoid “design tunnel vision”.

5. Pair implementation One programmer types into the computer while the other is actively engaged in observing, performing a continuous code review. Efficient form of defect removal: removed right from the start. Drawback: most programmers prefer to do a thorough review of their individual work and incorporate it into the project.

6. Pair Testing Is the least critical part of the development cycle, as long as the pair develops the test cases together. Testing discovers new bugs. Pair testing allows for different points of view on how to test an application, hence finding even more bugs.

7. Good Practices for Pair Programming Don’t hit your partner: make sure your partner stays focused and on- task. Put things back where they belong: have confidence but not too much confidence. Clean up your mess: The “watch over the shoulder” technique epitomizes defect prevention and efficient defect removal.

8. Good Practices for Pair Programming Don’t take things too seriously: “Ego-less programming” Say you’re sorry when you hurt somebody while moving furniture: Appropriate workspace layout is critical to the pair success. Wash your hands of skepticism before you start: develop an expectation of success and greet your collaborative partner.

9. Good Practices for Pair Programming Flush: Pair programmers will work on something independently, when rejoining your partner review your work done separately. When you go out into the world, watch out for traffic, hold hands and stick together: your work is done together, do not leave your partner apart. Be aware of the power of two brains: You remember better, more knowledge and skills.

10. Good Practices for Pair Programming Take a break from working together every afternoon: experiment new prototypes, deep-concentration, logical thinking is preferred to do it alone. Live a balanced life – learn some and think some and draw and paint and sing and dance and work every day some.

11. Issues in Pair Programming How do you create a good pair?  One personality might consume the other. Or two clashing personalities might not get work done. Programmers tend to split work for more rote, routine and simple coding of a project. Design review might be best in larger numbers (Design Review Boards). But Design alone is better in small numbers.

12. Issues in Pair Programming What is a conducive workplace?  Offices and cubicles are regular settings for offices that hinder pair programming.  “Like many kings, some managers use divide-and-conquer tactics to rule their subjects, but programmers need contact with other programmers.” (Weinberg 1998).

13. Issues in Pair Programming How much time should it occupy in a work day?  Many programmers do not agree how much time they should give for pair programming.  From all-day extreme, to few minutes a day. Alternative Solutions: “Distributed pair programming” (Baheti, Gehringer, Stotts).

14. Interviews and Results An experiment in Temple University showed that pair programmers produced 40% more quickly and effectively. Contrary to the notion of managers that believe that it would mean a 100% increase of production time. 96% stated that they enjoyed their job more than when they programmed alone.

15. Interviews and Results Design is good in pairs, even better in 3-5 members. But more than that it hinders (never reach to an agreement). Pair programmers is a positive form of peer pressure. Simple tasks should be done alone, but by pair design you can identify which tasks need to be done in pairs. Pairs enjoy their work more because they are more confident in their results.

16. Interviews and Results Good way to bounce new ideas off. You can spend more time doing challenging design and less time doing annoying debugging (due to better quality of product). “We nailed that one” feeling. People who are forced to pair-program despite their resistance might not do well.