A short evaluation of the Pair Programming practice, from an academic perspective.

1. An Evaluation of Pair Programming

2. Contents
•Introduction
•Characteristics
•Variants of Pair Programming
•Strengths and Weaknesses
•Defect Prevention by Pair Programming
•Resistance to Pair Programming
•Related Metrics
•Conclusion

3. Pair Programming
•An eXtreme Programming practice
•Software development technique
•A defect prevention method
•Involves two programmers working side-by-side on a
common task
•P1: Driver
•P2: Navigator or Observer
•They switch roles periodically

4. Characteristics
•Two programmers
•Pressure of work is divided between two programmers.
•Partners help each other to concentrate on work.
•Partners brainstorm and distribute cognition while working
•Continuous reviews contribute better defect prevention
•Improves quality with minimum budget and resources

5. Variants of Pair Programming
Remote pair programming
•Also known as distributed pair programming or virtual pair
programming
•Two programmers situated at different locations team up as a pair
to work on same code and design using common shared text
editors and collaboration tools
Ping Pong pair programming
•Programmer 1: Writes a failing unit test (Ping)
•Programmer 2: Makes a test pass by writing necessary
implementation code (Pong)
•Programmer 2: Writes a new failing unit test (Ping)
•Programmer 1: Makes a test pass by writing necessary
implementation code (Pong)
•Go back to Step 1 (Follow this iteration for all pairing session).

6. Variants of Pair Programming (Contd.)
Cross Functional pair programming (CFPP)
•It addresses development of embedded systems.
•CFPP pair consists of a software engineer working together
with a hardware engineer to create a module or an entire
embedded system.
•CFPP usually involves programming, debugging,
simulations, emulations, etc.

7. Strengths of Pair Programming
•"Two persons can think more than one"
•It reduces risk of Repetitive Stress Injury (RSI)
•It helps in improving learning capabilities
•Knowledge passes easily between pair programmers.
•Decreased risk to management
•Improved quality
•Reduced cost of development

8. Weaknesses of Pair Programming
•Some programmers may prefer to work alone
•A programmer might get intimidated by other
•Personal conflicts
•Annoying personal habits
•Decisions like "Whom to pair?" is difficult to decide

9. Defect Prevention
•Pair Programming prevents code and design defects
•It is a type of continuous reviewing of work
•Continuous reviews help in defect prevention and defect
removal

10. Resistance to Pair Programming
•Lack of familiarity and knowledge over the technique
•People are unwilling to take up the new idea of pairing
seriously because many are accustomed to traditional solo
programming
•Many consider pairing as a waste of time, money, and
resources because the team requires time to learn
•It takes time to convince management
•No time for pair programming due to deadline pressure

11. Related Metrics
Productivity of a Single
Person
Number of Lines of Code
produced by a single
programmer during one month
period
Pair Speed Advantage
Ratio between time required by
a single programmer and time
required by pair programmers for
performing some task
Defect Density
The average number of defects
per a unit of LOC.
Pair Defect Advantage
Ratio between defect density of
pair programming and defect
density of traditional software
development
Product Size
Number of Lines of Code or
Function Points

12. Conclusion
•Pair programming is not applicable to every software project
•Success of pair programming depends on coordination and
cooperation between the partners
•Bad pairing may result in lower productivity and quality
•Do not use pair programming while working on complex
problems
•We suggest using pair programming - WHEN -
oTask complexity is low and schedule pressure is high
oTask complexity is high and schedule pressure is low