Extreme Programming n Extreme programming is a lightweight

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

Extreme Programming (what is it? ) n XP takes commonsense principles and practices to extreme levels u u u u 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)

Flexibility, Involvement, and "The Practices" n n n 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

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

Pair programming n n n 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.

This Is Pair Programming

This is NOT Pair Programming

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

Findings #1 - Quality

Findings #2 - Time

Findings #3 and #4 – Enjoyment and Confidence

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

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

Issues: Workplace Layout Bad Better Best

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

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

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