Skip to content

XP Practice: Pair programming

April 18, 2008 by Artem Marchenko

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

In my own practice I found that besides leading to better quality because of continuous code review, pair programming is a very efficient tool for rapid competence transfer and for synchronizing the people views on both the tasks and the solutions. Even if the team is not regularly doing par programming, pairing for some time in the beginning of the project or after the major decisions, helps aligning the team members understanding. Also being paired with the more experienced developer, typing under his governance and seeing which low level tricks he uses is a very efficient way to learn and align the team standards for coding.

Further links

This page is a part of the Extreme Programming overview

About the Author: As the Editor-in-Chief for AgileSoftwareDevelopment.com, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem

Comments

Pair Programming Everywhere?

April 20, 2008 by Isaac Sacolick (not verified), 1 year 47 weeks ago
Comment id: 1513

Still looking for some good guidelines or better yet, metrics on when to apply pair programming. I have an approach published at CtoToDevelopers

Dear Artem, I agree with

August 8, 2008 by Rajagopal Yendluri (not verified), 1 year 31 weeks ago
Comment id: 1748

Dear Artem,

I agree with your post, but while paring instead of paring the "Valuable Engineers" / Most Experience engineers, i think it's better if we pair a "Entry Level Engineer" with "Experience Engineer" the result is good in a way that the Junior Engineer will learn lot of things like best practices, etc., from the Sr Engineer.

Paring 2 Sr Engineers will help when one is stuggling to solve the probelm, so that the other one will look the problem in a different perspective.

Any Comments !!!!

Regards,
Rajagopal Yendluri(Raj)

Indeed, pair programming is

August 9, 2008 by Artem, 1 year 31 weeks ago
Comment id: 1753

Indeed, pair programming is an efficient knowledge transfer tool and can accelerate learning much irregardless of whether you teach a junior person or senior person who is just new to the domain and the team.

Agree with you.. what's

August 14, 2008 by Rajagopal Yendluri (not verified), 1 year 31 weeks ago
Comment id: 1763

Agree with you.. what's about the Less Exp and More Exp Pairing.. i am more interested to know on this..

I tried pairing More Exp with Less Exp .. succeeded some entend..

I Strongly believe that in terms of writing the good code(bug free / performance / standards) and improving the analytical skills for Less exp it helps alot

Would like to know your views on this..

Regards,
Rajagopal Yendluri(Raj)

Analytical skills help often

August 14, 2008 by Artem, 1 year 31 weeks ago
Comment id: 1764

Well, analytical skills are helpful for programmers in general ;) Pairing is quite an efficient learning tool in general, but of course some people are just "chemically incompatible" and can hardly be paired.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com