This document discusses pair programming, where two programmers work together at one workstation on the same development task. One programmer acts as the "driver" who types code while the other, the "navigator", reviews each line of code as it is typed and assists in design and debugging. Regularly swapping driver and navigator roles improves collaboration, knowledge sharing and code quality. Studies have found that pair programming leads to higher quality code with fewer defects, while only increasing costs by around 15%. It works best for some personality types and teams, and allows for knowledge transfer between more and less experienced programmers.

1. Pair
Programming

2. Who
am
I?
@_pedro_torres
|
pedrogustavotorres.com
Pedro
Gustavo
Torres

3. An
Agile
Geek!
2014

6. A
li@le
bit
of
background

7. What
is
Pair
Programming?
• code
is
produced
by
two
people
programming:
– on
one
task
– on
one
workstaFon
• Two
keyboards
(opFonal)
• Two
mice
(opFonal)
• Two
monitors
mirroring
(ideally)

8. Driver…

9. …navigator

10. Change
roles
mulFple
Fmes
a
day

11. Change
roles
mulFple
Fmes
a
day

12. Change
roles
mulFple
Fmes
a
day

13. ¡Quiz
Fme!
In
which
scenarios
are
the
developers
properly
pairing?
A
B
C
D

15. Setup
#1

16. Setup
#2

17. Setup
#3

18. Setup
#4

20. All
the
Fmes
in
front
of…

21. …except
in…

22. …and
in!

24. Task
C
Task
B
Task
A
Task
A
RotaFon
between
pairs
Monday
Wednesday

25. Pair
rotaFon
lader
Rachel
Davies,
Agile
Coaching

27. CollecFve
code
ownership…

28. …bus
factor…

29. …beginners
mind

31. Engagement
/
Commitment…

32. …valuable
stand-­‐ups…

33. …be@er
integraFon
of
new
team
members…

34. …limit
WIP…

35. …
to
skip
code
reviews?

37. Less
bugs…

38. …more
fun…

39. …less
distracFons…

40. …less
interrupFons…

41. …less
slacking…

42. …and
comfort
zone
wise…

43. …bigger
comfort
zone!

44. Two
heads
think
be@er
than
one

46. Back
in
2000
Cockburn
and
Williams…
• for
a
development-­‐Fme
cost
of
about
15%
• Pair
programming:
– Improves
design
quality;
– Reduces
defects;
– Reduces
staffing
risk;
– Enhances
technical
skills;
– Improves
team
communicaFon;
– It’s
more
enjoyable.
Cockburn,
Alistair
and
Williams,
Laurie.
The
Costs
and
Benefits
of
Pair
Programming

47. In
2008
Begel
and
Nagappan…
• 64,4%
believed
that
pair
programming
worked
well
for
them
• 65,4%
felt
that
pair
programming
produced
higher
quality
code
• 25,4%
believed
that
it’s
not
slower
than
solo
programming
Begel,
Andrew
and
Nagappan,
Nachiappan.
Pair
Programming:
What’s
in
it
for
Me?

49. “Common”
habits…

50. …no
music
/
social
“stuff”

51. So
is
Pair
Programming
for
everyone?

52. It
should
not
be
imposed

54. Some
personaliFes
are
exquisite…
soul
mates
cvdd
senior
newbie
junior

55. …others
are
very
very
exquisite
grumpy
rock
star
badass
arch
enemy

57. Remotely
works?

58. Are
esFmaFons
affected?

59. What
about
size
or
length
of
tasks?

60. Is
it
€xp£n$ive?

61. Is
it
only
for
mature
teams?

62. Does
it
scale?

63. Companies
that
use
it?

64. Scholars
and
hands-­‐on
fans?

66. Maybe
slow…

67. …or
all
in!

68. Thank
you
J
The
whole
is
greater
than
the
sums
of
its
parts
Aristotle