9

I am familiar with Agile and Pair Programming (http://en.wikipedia.org/wiki/Pair_programming). I thought Pair Programming was used if there was a complex requirement i.e. two sets of eyes is better than one.

Is Pair Programming also used to train less experienced developers and bring them up to speed?

Also, how often is it used e.g. all the time i.e. the two developers will work together at one screen permanently or perhaps one day per week? I have read an Agile book, which talks about this concept but it does not mention frequency of use.

gnat
  • 21,442
  • 29
  • 112
  • 288
w0051977
  • 7,031
  • 6
  • 59
  • 87
  • 4
    [This question about pair programming with different skill levels](http://programmers.stackexchange.com/questions/183645/pair-programming-when-driver-and-observer-have-different-skill-level-and-experie?rq=1) may be relevant/related. – Thomas Owens Sep 08 '13 at 23:41
  • When we think of pair programming in the agile sense, there's more to it than just two people at the keyboard and it has little to do with the task complexity. I guess there could be some programming tasks that are so trivial having two sets of eyes is counter-productive, but who does that kind of stuff? – JeffO Sep 09 '13 at 13:17

6 Answers6

14

Pair programming should not be used to train inexperienced or less-skilled developers.

Studies and meta-studies that support pair programming on a general, conceptual level, almost invariably find that the gains in quality and productivity only outweigh the added cost when both programmers are at roughly the same skill level.

In fact, this has pretty much become a "rule" in academic settings. Universities which recommend the practice also state explicitly that students should find a partner with the same skill level. Not better, not worse - the same.

Note that "skill level" here is domain- and task-specific. Pairing a brilliant UI developer with a brilliant algorithm designer or database developer is no better than pairing a brilliant UI developer with a totally green UI developer.

The studies (corroborated by my own personal experience) show that inexperienced developers (in some area) learn faster when paired, and highly-skilled developers can catch serious misunderstandings and design problems much earlier, negating much of the time spent on debugging and rework.

However, there is a gradient of almost 10x the productivity for the least vs. most skilled developers. Pairing someone highly-skilled with someone very green is very much like pairing a driving instructor with a student. You don't have real co-operation, you have a driver and a passenger, a master and an apprentice. If the apprentice "drives" then the master is too busy monitoring and correcting errors to get any work of his own done. On the other hand, if the master "drives" and the apprentice is told to watch and learn, the master is less productive due to the interruptions and the apprentice does not learn very effectively.

This is a no-win situation. If new developers need to be trained, then call a spade a spade and train them. Or apprentice them, have them "shadow" a more experienced developer for a while. But don't call it "pair programming" and expect to get good results. Those only occur when both partners have similar skill sets.

Note: For those who can't view the study, here is another one making similar claims:

Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise.

To quote the abstract:

The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors.

Pairing a senior with a junior negates the time benefit that applies to seniors. There is still an improvement in correctness over what the junior would normally produce, but it is not proven to be better than what the senior would produce on his own.

Keep in mind that this is just a single study, whereas the first study is an actual meta-analysis which incorporates several different studies. It is by far the best resource I've found. Anyone who is truly interested in learning about the actual research should consider getting an ACM membership, because that's where all of these studies are published.

Aaronaught
  • 44,005
  • 10
  • 92
  • 126
  • 1
    +1: I've also found this to be true in practice. I would also add that on straightforward or trivial implementations pairing has provided little to no benefits. – dietbuddha Sep 09 '13 at 02:53
  • 12
    I am under the impression this is getting just play of words - when you bring two devs in front of one screen, call it either "pair programming" when they are both equally skilled, and call it "training" if they are not. Both cases seem to bring benefits. – Doc Brown Sep 09 '13 at 05:34
  • 6
    Not meaning to be pedantic, but how is it a no-win situation if "The studies (corroborated by my own personal experience) show that inexperienced developers (in some area) learn faster when paired, and highly-skilled developers can catch serious misunderstandings and design problems much earlier, negating much of the time spent on debugging and rework." – Bernardo Pires Sep 09 '13 at 08:56
  • There have been a lot of posts with the opinion the "only" benefit to pair programming is in a mentor or training situation, but I think this obscures the true definition. Maybe we shouldn't generalize pair programming to mean two people at the same keyboard? – JeffO Sep 09 '13 at 13:21
  • 4
    I disagree with this answer substantially. Pair programming when done in a cooperative style is very effective in creating a common culture in a team – Michael Shaw Sep 09 '13 at 13:59
  • @DocBrown: Training only brings benefits to the person being trained. It still has to be done, of course, but it's a significant net loss to productivity and should be seen for what it is, as simply a cost of expansion or turnover (and a very good reason for companies to try to minimize turnover and expand gradually). – Aaronaught Sep 09 '13 at 23:16
  • @Clash: It's a no-win situation to pair developers *of unequal skill levels*. It's *not* a no-win situation to practice pair programming in general; that can have wins if done properly. – Aaronaught Sep 09 '13 at 23:17
  • @JeffO: That's almost exactly the *opposite* of what I said. Using pair programming for mentorship/training *negates* the other, considerable benefits of pair programming. As far as not being at the same keyboard, well, if you're not at least in close proximity then it's sort of blurring the line between pair programming and code review. – Aaronaught Sep 09 '13 at 23:20
  • @Ptolemy: You are of course entitled to your opinion, but the plural of anecdote is not data. This has actually been researched in both academic and professional settings and the findings are that pair programming raises overall productivity when developers are at the same skill level and lowers overall productivity when they are not. If you claim to be doing it for other, intangible reasons like "culture" then it's obviously impossible to argue, since no one can measure that. And while we certainly can't expect to measure everything, I prefer to rely on hard evidence where available. – Aaronaught Sep 09 '13 at 23:24
  • 2
    @aaronaught, you say based on research, how did they measure the skill of the participants at pair programming as part of the research? and then did they adjust results to eliminate the skew that may be caused by people with different skill levels of pair programming. – Michael Shaw Sep 10 '13 at 08:29
  • Or did the research actually have people who were skilled at pair programming being more productive, but was not looking to quantify this, and have allowed this to skew their conclusions? – Michael Shaw Sep 10 '13 at 08:31
  • @Ptolemy: What are you talking about? Why would they "adjust results to eliminate the skew that may be caused by people with different skill levels of pair programming"? That's **part of what they were measuring!** Anyone can try to poke holes in methodical research to try to justify their own preconceptions; I'll consider your objections to have merit if you actually read some of the papers/studies and can point out *specific* flaws in their methodology, or better yet, some reliable contradicting study that isn't already in the meta-analysis. – Aaronaught Sep 11 '13 at 00:22
  • Incidentally, nothing I've read or experienced on the subject suggests that there is any such thing as "skill at pair programming". Just skill at the particular task being performed. It's clear from your answer that *you* are firmly invested in this belief, but it has yet to be substantiated by any evidence. In a meta-analysis, you assume that any bias inherit in some studies (such as lack of communication skills for certain people) will average out, so that was likely not a factor. – Aaronaught Sep 11 '13 at 00:23
  • I've found that pairing people of different skills is actually a good thing for mentoring, and also for productivity (if compared to other ways of mentoring). This works if the developers have similar levels of seniority, but different skill sets. – Sklivvz Sep 14 '13 at 21:45
  • Also, I would be grateful if you linked to studies I can actually check (or at least with a decent abstract). The link you gave sends us to a page that does not support your point. – Sklivvz Sep 14 '13 at 21:48
  • @Sklivvz: Fine, I added another section at the end. Like I said in my post, I don't like posting single studies because there are discrepancies between them; meta-analyses aggregate all of the studies and average them out, which tends to produce the most correct data. Unfortunately the vast majority of CS research is published on the ACM, which is behind a paywall; it's hard to have an informed discussion without referencing any of it. – Aaronaught Sep 15 '13 at 17:12
  • Incidentally, this maps almost perfectly to my own experience. When I pair with another experienced developer (which is not part of a process but we sometimes do it voluntarily to solve a specific problem), we benefit from having obvious mistakes or problems pointed out *earlier*, but they are invariably mistakes that would have eventually been caught by a unit test or quick manual test anyway. However, on those rare occasions when I've worked with a junior, I have to slow down significantly otherwise they won't be able to keep up (and therefore won't catch any errors). – Aaronaught Sep 15 '13 at 17:20
8

Strongly disagree with this answer.

I have previously mentored junior developers and new joiners through pair programming. On a review, they found it very useful and they were up to speed much quicker than people who were left on their own.

When I was driving, they saw me use a range of short cuts within IDE which significantly improves my productivity. When they were driving I encouraged them to use the same short cuts - within days they were already more productive.

Unit testing was another area. Many junior developers had no exposure to unit testing. I was able to demonstrate them how we write test, what our naming conventions are and what a good unit test looks like. When I was 'navigating' I was able to advise 'driver' as they were writing tests.

Community
  • 1
CodeART
  • 3,992
  • 1
  • 20
  • 23
5

I disagree with this answer.

I have found that pair programming, whether the same level or different to be very useful for many reasons.

I have definitely seen it used to train less experienced programmers (to directly answer the question).

I think that it works because:

  • passing on program knowledge and what the various parts mean and do is often best done through period of pair programming.

  • there's nearly always differences in skill and experience levels between programmers due to experience, background, etc. So 'at roughly the same level' rarely applies in practice in my experience.

  • good programmers know to both learn from others and also teach and pass on their own knowledge through pairing.

  • good pairing often results in BOTH people spending tie at the keyboard. My favorite person to pair with and I used used to call these the 'ach, I'm stuck (person 1)' paired with 'here, gimme the keyboard let me try, I've got an idea (or the energy to continue!).'

  • even the best programmers need to learn the domain that they are working in and how it is represented by code and data and pair programming is often a great way to do that.

Community
  • 1
Michael Durrant
  • 13,101
  • 5
  • 34
  • 60
2

I use PP in my work in a similar way - with newcomers (not necessarily unexperienced pragrammers). Usually this is one week period. After this all the goals listed below are usually met.

Goals:

  1. Period of familiarization of a newcomer with the code base will be significantly reduced. When you need a man to be involved in your project and to get a result in two weeks this works perfectly.
  2. You as a manager will understand how a man thinks. This will help you to work out an approach to work with him.
  3. Newcomer will have an introduction of a coding culture of the project.
  4. Unexperienced guy will catch how an experienced one works during coding. This will help to understand where to improve.
  5. Experienced guy will teach you a couple of nice how-to's.
Riga
  • 164
  • 4
  • I'm pretty sure that the **interview** is where you are supposed to figure out how someone thinks and introduce them to the culture. – Aaronaught Sep 11 '13 at 00:37
  • 1
    @Aaronaught there is difference between a two hours interview and one week cooperation, isn't it? – Riga Sep 11 '13 at 22:32
  • And there's a difference between one week of buddying up and 6 months of working on the same team. Point is, you should have a pretty good idea of how a person codes and approaches problems before you even hire them in the first place. – Aaronaught Sep 11 '13 at 23:56
  • 3
    @Aaronaught I guess you are arguing for the sake of arguing. As you have stated period of time makes sense. What is the problem then? If you are the guy who knows everything about a person after the interview then wow, you are super cool guy I never met. My experience can't be alienated from me. Interview gives you understanding whether the guy will manage to get things done. Other things is a long story and it is a good idea to start with pair programming. Your "true" understanding can't override this fact. – Riga Sep 12 '13 at 00:15
1

Pair programming is a skill in its self, and the benefits of pair programming can be quite widespread and varied, depending on when and how its used.

I've used it when managing a team of quite inexperienced programmers as an orientation tool when new programmers join the team. (We talk about what I am doing on the first task, as I am doing it, and then we talk about what they are doing on the second task when they are doing it, and on the third task we talk about their intended implementation and the review of their code. - goal: code orientation and setting expectations for their work.

I have also used it as a training technique, where someone is being introduced to a new technique. In this case, they would be introduced to the concept away from the keyboard and then a few hours or a couple of days later, we would pair program the design phase, and they would be the lead programmer doing the implementation, with me providing guidance where needed. - goal: introducing multi threaded code / async callbacks and producing something productive in a shortish period of time.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
1

As with most things Agile, I feel the answer is "It Depends".

Is the less experienced person attempting to learn a new language (or other base skills) or do they already have the requisite skills and just need to learn a new application? If they are attempting to learn a new language or skill, I would argue mentorship may be more appropriate. If you are on-boarding someone new to the team who has the skills, then paired would be the way I go.

I agree with the point regarding not pairing a master with a new green developer, however I disagree that they should be the same skill level. I think the key is pairing people who are close to the same skill level.

As far as frequency of use, I think your team members should be able to help you with that one. Perhaps there is a story that is particularly tricky that the developers will want to pair on, other times there may be a story that is pretty straight forward that someone wants to do on their own to have time to decompress.

One final thought, when pairing, try to have the least experience person on the keyboard. If the more experienced person drives, then there is a tendency for that person to write a whole bunch of code, with the explanation of "I will explain that in a minute, just hang on". If the less experienced person is driving, then the conversation around what to do / how to move the code forward, tends to happen in a more timely manner.

Cheers!

Abstract Class
  • 329
  • 1
  • 3