Pair Programming

About me

ศิริวัฑฒ์ จิตต์หรรษา

Siriwat Jithunsa

siriwatj@gmail.com

Thomson Reuters

Objective

To give an overview about Pair Programming and its benefits which could make you curious and may want to try in your team.

To share and discuss about challenges and tips on doing pair programming.

Agenda

History

The Mechanics of Pairing

Some researches

Benefits

Why it works?

Pair Programming Patterns

Challenges

Tips

Discussion / Q&A

Xtreme Programming advocates pair programming on all production code .

Pair Programming History

Larry Constantine (1995) -

Called it " Dynamic Duo " development

Nissim Hadar (1996) -

I was leading a team of 4 programmers working on a flight simulator in 1996. Each programmer was assigned a separate aircraft system.

The programmers came to me and told me that, as they were always helping each other (this was FORTRAN on a weird system...), they wanted to work in pairs on each system.

This seemed inefficient to me at the beginning, but the big improvement came when the weaker programmers improved within a short time and there were fewer bugs in the fixed time we had for the project.

The Mechanics Of Pairing

Pair Programming Chair No, Thanks.

Two developers work on the same machine. Both have keyboard and mouse.

At any given time one is driver and the other navigator.

The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. Real-time peer review.

The roles switch either every hour, or whenever really.

~ 4-6 hours a day

Effects of pair programming at the development team level: an experiment

Had 29% lower project productivity for the first three or four use cases.

The inefficiency was probably caused by:

the learning time

involved in getting familiar with new people and the pair programming practice.

Later teams spent 5% less effort than the Solo Programming teams for implementing the use cases.

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1541842

Effects of pair programming at the development team level: an experiment

Code contained 8% less defects per use case

In the end of the project they delivered systems with a lower number of defects per use case.

Had slightly better design quality based on the method size and complexity metric

Martin Fowler said …

When people say that Pair Programming reduces productivity, I answer " that would be true if the most time consuming part of programming was typing "

Benefits

Good for learning and training

Deeper understanding of why , how and what was done

Better Quality

Fewer bugs

Instant validation of ideas

Adherence to team conventions

Increased productivity

Fewer interruptions - better focus

pushing each other and motivating to achieve best results

Less procrastination and wasting of time

Improved morale

Greater confidence that their work is correct.

Better discipline and time management

Less likely to skip writing unit tests, spend time web-surfing or on personal email

Industry Metrics

Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs (N.B.: The original study showed that 'error-free' code went from 70 % to 85 %; it may be more intuitive to call this a 50 % decrease of errors, from 30 % to 15 % ). Since testing and debugging are often many times more costly than initial programming, this is an impressive result.

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Why it works?

Two people have differing specialities, these skills are transferred.

“ everybody has some expertise, some knowledge or ideas that are worth sharing .”

Ad-hoc training occurs as one person shows the other some tricks and techniques, nice workarounds, etc.

Both developers are fully aware of the code, how it works, and why it was done that way.

Why it works?

It's less likely to contain bugs and hacks and things that cause maintenance problems later.

Chances are the code is better than one developer working alone, as there was somebody watching.

It is impossible to ignore the reviewer when he or she is sitting right next to you.

Why it works?

It gets developers talking and communicating ideas in the common language of code.

The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.

Continuous Code Review

Pair Programming Patterns

Driver-Navigator

Mouse-Keyboard

Ping-pong

Driver-Navigator

Driver

Is the person typing the code

Navigator

Reviews what the driver is writing

Roles should switch frequently

~1 hour at a time in each role

Mouse-Keyboard

Driver:

Uses keyboard

Navigator:

Uses mouse

Benefits:

Makes sure everybody is contributing/engaged

Ping-pong

Driver:

Writes code

Navigator:

Writes tests

Benefits:

Another developer evaluates functionality

Challenges

To get the buy-in on doing pair programming from Management

Understand the benefits and cost

Everyone has to WANT to pair.

they all at least need to be curious enough about it to give it a genuine shot - attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work.

Environment

The developers need to be side by side, the same distance from the monitor (which needs to be large).

You might need more chairs.

Personal Preferences

Hygiene can be a serious problem.

Timing

Tips

Agree on one tiny goal at a time

Using Unit Tests

Sync up frequently (Communicate, Ask & Listen, Compromise or take your stand)

Make sure you both know what the other one is working on and thinking

Switch roles often (at least once an hour)

If you’re stuck or frustrated, try switching roles

Tips

TDD - Write a unit test first. This will help you and your partner to agree on the goals.

Switch partners when you start a new iteration

Schedule breaks if necessary

Decide to take a 5 minute coffee break if things are getting tense or you need a second to think

Take a moment to celebrate

Getting feedbacks from your team

Q: Expert & Junior

Possible Issues:

A boring lecture

A one-man show game - the expert monopolizes the keyboard and never let the other drive it.

Solutions:

Communicate.

Junior should ask wisely and Expert should answer wisely.

Record Your Communication In The Code

Record Your Communication In The Code

If the junior can't understand some bits of the code

And then asks on it

The expert notices that he failed to make the code clear at every point

The pair tries "together" to refactor the bits into a new method with an explanatory name

remember that when you use comments as the last resort, the code quality will improve much more

So that next time other pairs see the bits, there be no need to ask/explain/explore whatever but to learn fast.

Jeff Atwood – Coding Horror “ When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. ”

Resources