PAIR PROGRAMMING
WHAT IS PAIR PROGRAMMING ?
Pair programming is an Agile technique
originating from XP in which
two developers team together
and work on one computer.
WHY PAIR PROGRAMMING ?
+15% time
-15% errors
---------------
= $ $ $
WHY PAIR PROGRAMMING ?
+ Design Quality
+ Satisfaction
+ Learning
+ Team Building and communication
-----------------------------------------------
= :) :) :)
HOW TO DO PAIR PROGRAMMING ?
Start with:
Driver / Navigator
Expand to:
TDD Ping Pong
Driver / Navigator
"the driver"
types at the keyboard.
"the navigator"
reviews each line of code as it is typed,
checking for errors
and
thinking about the overall design.
Switch roles at set intervals !
TDD STEPS
1: Write a failing test case
2: Make the test pass
3: Refactor the code or the test
Repeat until satisfaction !
TDD Ping Pong
Fail------------->
<------------Pass
Refactor------>
<-------------Fail
Pass------------>
<------Refactor
Fail------------->
<------------Pass
Refactor------>
...
SO, lets start driving/navigating.
Exactly how do we do that ?
1. Define a task
Something that brings value (a "story")
Something that takes a reasonable time (1-3 hrs)
Ex. "Write a script that compresses a set of files and moves the archive to a shared disk"
2. Break it down
Something that fulfills some small function (is "testable")
Something that can be done within "a few" minutes
Ex. "Write the file finder function"
3. StART
Driver:
Try to complete the current task as
quickly and correctly as possible.
Trust your navigator to be your safety-net.
Navigator:
Bring up errors and code that you find unreadable right away. Wait until the current tiny goal is done to bring up larger issues and ideas for design improvement.
4. SWITCH
Set a timer on the agreed time,
switch when the timer goes off,
no debate !
30 minutes is a good start, but experiment to fine-tune.
5. CELEBRATE
A high five is never wrong.
A demo of a complete and working 'thing' is even better.
fin
Questions ?
GUIDELINES
Share everything.
All contributions,
whether great results or errors,
are “ours”, not “yours” or “mine”.
Play fair.
One person “drives”
(has control of the keyboard or is recording design ideas)
while the other is continuously
reviewing the work and planning ahead.
Stay fairly close to 50-50 on driving.
Let the less experienced partner start
and maybe drive a little more.
Don’t hit your partner.
But do make sure your partner stays
focused and on-task.
Put things where they belong.
Put negative judgments in the trash:
Be positive about you and your partner.
For both, this is an opportunity to improve.
Don’t take things too seriously.
If your partner picks out a bunch of errors as you type,
be glad. But do not always agree.
Have healthy disagreement/debate.
Finding the fine balance takes adjustment.
DON'T BE IKEA.
Sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and mouse.
Slide the keyboard -- don't move the chairs.
Wash your hands of skepticism.
Being skeptical can be a self-fulfilling prophesy.
Buying in and “jelling” can lead to
a whole that is greater than the sum of the parts.
Flush.
If you work on some parts independently:
either discard them (flush) and start over together
or
have the partner very carefully review the work with you before continuing together.
cookies and milk are good for you.
Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming.
Beware the power of two brains.
Together, a pair will come up with
more than twice as many possible solutions
than the two would have working alone.
They will then proceed to more quickly
narrow in on the “best” solution and will
implement it more quickly and with better quality.
PAIR PROGRAMMING
By maderskog
PAIR PROGRAMMING
- 299