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.
Made with Slides.com