1. Extreme Programming
Extreme programming is "a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements"

2. Extreme Programming (what is it?)
XP takes commonsense principles and practices to extreme levels
if code reviews are good, review code all the time (pairs)
if testing is good, test all the time (JUnit)
if design is good, everybody do it all the time (refactoring)
if simplicity is good, design with the simplest design that supports its current functionality
if architecture is important, everybody works on defining and refining the architecture all the time
if integration testing is important, integrate and test several times a day
if short iterations are good, make the iterations really, really short (minutes and hours, not weeks and months)

3. Flexibility, Involvement, and "The Practices"
The planning game (quickly determine the scope of the next release). As reality overtakes the plan, update it.
Small releases – simple system into production quickly
Metaphor – simple shared story of how the system works
Simple design – design simply, remove complexity
Testing – by developers and customers
Refactoring
Pair programming
Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards – communication through code

4. What Is Pair Programming?
"Pair programming is a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. It allows two people to produce a higher quality of code than that produced by the summation of their solitary efforts."

5. Pair programming
In XP, programmers work in pairs, sitting together to develop code.
This helps develop common ownership of code and spreads knowledge across the team.
It serves as an informal review process as each line of code is looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from this.
Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

6. This Is Pair Programming

7. This is NOT Pair Programming

8. Does Pair Programming Really Work?
Empirical study by Laurie Williams at the university of Utah
Practice: Summer 1999
20 students (sophomore/junior)
All worked collaboratively
Generated more anecdotal/qualitative evidence
Solo vs. pair: Fall 1999
41 students (junior/senior)
28 worked collaboratively
13 worked individually
Quantitative: time, quality, enjoyment, confidence

9. Findings #1 - Quality

10. Findings #2 - Time

11. Findings #3 and #4 – Enjoyment and Confidence

12. How Does This Work? Pair-Pressure Pair-Think Pair-Relaying
Keep each other on task and focused
Don’t want to let partner down
“Embarrassed” to not follow the prescribed process
Pair-Think
Distributed cognition: “searching through larger spaces of alternatives”
Have shared goals and plans
Bring different prior experiences to the task
Different access to task relevant information
Must negotiate a common shared of action
Pair-Relaying
Each, in turn, contributes to the best of their knowledge and ability
Then, sit back and think while their partner fights on

13. How Does This Work (Part Two)?
Pair-Reviews
Continuous design and code reviews
Ultimate in defect removal efficiency
Removes programmers distaste for reviews
80% of all (solo) programmers don’t do them regularly or at all
Pair-Learning
Continuous reviews  learn from partners techniques, knowledge of language, domain, etc.
“Between the two of us, we knew it or could figure it out”
Apprenticeship
Defect prevention always more efficient than defect removal

14. Issues: Workplace Layout
Bad
Better
Best

15. Issues: Partner Picking Principles
Expert paired with an Expert
Expert paired with a Novice
Novices paired together
Professional Driver Problem
Culture

16. Issues: Pair Rotation Ease staff training and transition
Knowledge management/Reduced product risk
Enhanced team building

17. Pairing Difficulties Inability to schedule enough time together.
Unreliability of a partner.
Friction caused by different experience levels and/or rates of learning.
Unwillingness to raise these issues in a timely fashion.