Pair Programming
31
Pair Programming
-
Upload
siriwat-jithunsa -
Category
Technology
-
view
2.426 -
download
2
Transcript of Pair Programming
Pair Programming
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.
The Mechanics Of Pairing•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 Mechanics Of Pairing•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 Code1. If the junior can't understand some bits of the
code2. And then asks on it3. The expert notices that he failed to make the
code clear at every point4. 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 more5. 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•Web Sites:
▫Pair Programming▫I Love Pair-Programming▫Pair Programming vs. Code Reviews▫Pair programming. What researches say on
the costs and benefits of the practice.•Book
▫Pair Programming Illuminated
Thank You•& Special Thanks to my team for real-
world input, experience, and support
Discussion / Q&A
