Pragmatic Pair Programming

Slide 1

Slide 1 text

Pragmatic Pair Programming Agile IT! Experience Matthew Bass [email protected] http://matthewbass.com

Slide 2

Slide 2 text

Ground Floor What is pair programming?

Slide 3

Slide 3 text

Agile Manifesto Individuals and interactions... ...over process and tools

Slide 4

Slide 4 text

The Black Sheep of Agility Why does pairing get a bad rap?

Slide 5

Slide 5 text

[LITT]

Slide 6

Slide 6 text

Dogmatism

Slide 7

Slide 7 text

“So I’m getting half the code for twice the money?”

Slide 8

Slide 8 text

Managers say... It’s unproductive It’s slow It’s wasteful It drives developers away It’s unproven

Slide 9

Slide 9 text

Developers say... It’s frustrating It’s difficult It’s uncomfortable It’s tiring I don’t need to do it

Slide 10

Slide 10 text

Why do initial attempts at pairing fail? No preparation?

Slide 11

Slide 11 text

Is pairing for everyone? Nope!

Slide 12

Slide 12 text

Pragmatic Pair Programming

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Navigator vs. driver Tie breaking Ping ponging Own the code Be patient (but not forever) Pairing pragmatically

Slide 15

Slide 15 text

Navigator vs. driver Driver Controls the mouse / keyboard Down in the details Navigator Thinks higher level Watches for typos, logic errors, etc. Switch off?

Slide 16

Slide 16 text

Tie breaking When a disagreement occurs... Rank importance (1 to 3) Count down, then reveal Involve a third party when necessary Tweak as needed

Slide 17

Slide 17 text

Ping ponging Makes the most sense with TDD One person writes tests... The other fixes them Swap? Turns coding into a game!

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Be patient ...but not forever Antonyms: hasty impetuous Very important when mentoring

Slide 20

Slide 20 text

So what?

Slide 21

Slide 21 text

Benefits Reduced development time Better code quality

Slide 22

Slide 22 text

Cost to correct a defect 0 25 50 75 100 Requirements Design Code Test Operation [BOEH] “Software Defect Reduction Top 10 List”

Slide 23

Slide 23 text

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]

Slide 24

Slide 24 text

Benefits Reduced development time Better code quality Better design Built-in code reviews Built-in cross-training Bad programming habits get squashed

Slide 25

Slide 25 text

Benefits Increases truck number Mandates undivided attention Improves communication Produces “flow”

Slide 26

Slide 26 text

“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”

Slide 27

Slide 27 text

Benefits Increases truck number Mandates undivided attention Improves communication Produces “flow” Tips and tricks More fun!

Slide 28

Slide 28 text

Another benefit Mentoring! Master / apprentice model Productivity moves up in increments Earlier tangible contributions Hiring / auditioning

Slide 29

Slide 29 text

Metrics How does pairing stack up? Economics Satisfaction Design quality University of Utah study

Slide 30

Slide 30 text

Relative time 0 37.5 75.0 112.5 150.0 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators

Slide 31

Slide 31 text

Defect count 0 22.5 45.0 67.5 90.0 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators

Slide 32

Slide 32 text

Lines of code 0 25 50 75 100 Iteration 1 Iteration 2 Iteration 3 [ACLW] One Individual Two Collaborators

Slide 33

Slide 33 text

Enjoyed pairing? 0 25 50 75 100 PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3 [ACLW] Agree Disagree

Slide 34

Slide 34 text

A few suggestions...

Slide 35

Slide 35 text

Hardware Dual monitors w/splitter Dual keyboards and mice Don’t skimp on desk and chairs Snacks and drinks

Slide 36

Slide 36 text

Software IDE vs. text editor? Test-first development Teleport for Mac / screen sharing Story database (Mingle, JIRA, etc)

Slide 37

Slide 37 text

Remote pairing? Screen sharing Audio (Skype, phone, etc) IM (screen captures, audio) SubEthaEdit NetBeans Collaboration Module [NB]

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Anti-patterns

Slide 40

Slide 40 text

Anti-patterns Being disrespectful Bad manners / hygiene One-sided decision making Slacking off Negativity Not switching pairs

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Introducing Pairing If you’re a developer... It’s hard Do it gradually Don’t pester Push through the ravine

Slide 43

Slide 43 text

“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]

Slide 44

Slide 44 text

Introducing Pairing If you’re a manager... “You have the power!” Don’t scare the developers Don’t make it mandatory Pick a champion

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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