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.

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 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 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

Pair Programming

More Related Content

What's hot

Viewers also liked

Similar to Pair Programming

Recently uploaded

In this document

Pair Programming