Pragmatic Pair Programming

Pair programming isn’t inherently evil. It has many tangible, measurable benefits when done pragmatically.

Transcript

1. Pragmatic Pair Programming Agile IT! Experience Matthew Bass pelargir@gmail.com http://matthewbass.com
2. Ground Floor What is pair programming?
3. Agile Manifesto Individuals and interactions... ...over process and tools
4. The Black Sheep of Agility Why does pairing get a bad rap?
5. [LITT]
6. Dogmatism
7. “So I’m getting half the code for twice the money?”
8. Managers say... It’s unproductive It’s slow It’s wasteful It drives developers away It’s unproven
9. Developers say... It’s frustrating It’s difficult It’s uncomfortable It’s tiring I don’t need to do it
10. Why do initial attempts at pairing fail? No preparation?
11. Is pairing for everyone? Nope!
12. Pragmatic Pair Programming
13. Throw out what doesn’t work Keep what works Be willing to adapt Communicate frequently Don’t be dogmatic* * Don’t do something for its own sake Pairing pragmatically
14. Navigator vs. driver Tie breaking Ping ponging Own the code Be patient (but not forever) Pairing pragmatically
15. Navigator vs. driver Driver Controls the mouse / keyboard Down in the details Navigator Thinks higher level Watches for typos, logic errors, etc. Switch off?
16. Tie breaking When a disagreement occurs... Rank importance (1 to 3) Count down, then reveal Involve a third party when necessary Tweak as needed
17. Ping ponging Makes the most sense with TDD One person writes tests... The other fixes them Swap? Turns coding into a game!
18. Own the code Anyone can change anything Anyone can wave a red flag Code you just wrote is fair game! No bouncing back and forth
19. Be patient ...but not forever Antonyms: hasty impetuous Very important when mentoring
20. So what?
21. Benefits Reduced development time Better code quality
22. Cost to correct a defect 0 25 50 75 100 Requirements Design Code Test Operation [BOEH] “Software Defect Reduction Top 10 List”
23. Code quality On a typical project: 40-50% of effort is avoidable rework Peer review catches 60% of defects Disciplined personal practices reduce defect introduction by 75% [BOEH]
24. Benefits Reduced development time Better code quality Better design Built-in code reviews Built-in cross-training Bad programming habits get squashed
25. Benefits Increases truck number Mandates undivided attention Improves communication Produces “flow”
26. “Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time.” -- Tom DeMarco [DEMA] “Peopleware: Productive Projects and Teams”
27. Benefits Increases truck number Mandates undivided attention Improves communication Produces “flow” Tips and tricks More fun!
28. Another benefit Mentoring! Master / apprentice model Productivity moves up in increments Earlier tangible contributions Hiring / auditioning
29. Metrics How does pairing stack up? Economics Satisfaction Design quality University of Utah study
30. Relative time 0 37.5 75.0 112.5 150.0 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators
31. Defect count 0 22.5 45.0 67.5 90.0 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators
32. Lines of code 0 25 50 75 100 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators
33. Enjoyed pairing? 0 25 50 75 100 PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3 [ACLW] Agree Disagree
34. A few suggestions...
35. Hardware Dual monitors w/splitter Dual keyboards and mice Don’t skimp on desk and chairs Snacks and drinks
36. Software IDE vs. text editor? Test-first development Teleport for Mac / screen sharing Story database (Mingle, JIRA, etc)
37. Remote pairing? Screen sharing Audio (Skype, phone, etc) IM (screen captures, audio) SubEthaEdit NetBeans Collaboration Module [NB]
38. Comfort zones We prefer the status quo Stretch to grow Muscles... get bigger when they hurt atrophy when they don’t hurt Comfort vs. adaptation
39. Anti-patterns
40. Anti-patterns Being disrespectful Bad manners / hygiene One-sided decision making Slacking off Negativity Not switching pairs
41. Does personality matter? Developers aren’t plug-n-play Some pairs won’t “mesh” What’s at stake? Managers: be aware Developers: voice your concerns
42. Introducing Pairing If you’re a developer... It’s hard Do it gradually Don’t pester Push through the ravine
43. “Ravines are a common part of improvement and if you want to make any real progress in anything, you have to work your way through a few of them.” -- Martin Fowler [FOW]
44. Introducing Pairing If you’re a manager... “You have the power!” Don’t scare the developers Don’t make it mandatory Pick a champion
45. How to seduce... Setup a pairing station Semi-public area With the latest hardware Pleasant environment Snacks readily available Seed the station with your champion
46. Where to go from here... Try pairing for an hour Okay, a half hour 15 minutes? Or just do a peer code review Take gradual steps Do your research
47. Resources “The Cost and Benefits of Pair Programming” (Alistair Cockburn, Laurie Williams) http://tinyurl.com/z19i “Pair Programming Illuminated” (Robert Kessler) http://tinyurl.com/4ezmms “Fearless Change: Patterns for Introducing New Ideas” (Mary Lynn Manns) http://tinyurl.com/5bngkh
48. References • [LITT] Todd Little. (http://alistair.cockburn.us/index.php/Image:XScreamProgramming.gif). • [BOEH] "Software Defect Reduction Top 10 List," by Barry Boehm and Victor R. Basili, IEEE Computer, January 2001. (http://www.cebase.org/www/resources/reports/usc/usccse2001-515.pdf). • [DEMA] “Peopleware: Productive Projects and Teams,” by Tom DeMarco and Timothy Lister, Dorset House Publishing Company, February, 1999. (http://www.amazon.com/Peopleware-Productive-Projects- Teams-Second/dp/0932633439). • [ACLW] “Costs and Benefits of Pair Programming,” by Alistair Cockburn and Laurie Williams, January, 2000. (http://alistair.cockburn.us/index.php/Costs_and_benefits_of_pair_programming). • [NB] NetBeans Collaboration Module. (http://www.netbeans.org/kb/articles/quickstart-collaboration.html). • [FOW] “The Improvement Ravine,” by Martin Fowler, October, 2006. (http://www.martinfowler.com/bliki/ ImprovementRavine.html).
49. Thanks! Matthew Bass pelargir@gmail.com http://matthewbass.com © 2008 Adeptware, Inc.