You want to AdoptPairProgramming
, but there is strong resistance from the CMM and BigDesignUpFront
camps. There is also a wide variety of differing skills at your organization; either differing skill levels, or differing skill areas, or both.
as a training technique. This is a little subversive, but PairProgramming does
work very well as a training technique (This claim has since been refuted by the LetTheJuniorDrive AntiPattern -- TheEditor
). Once the advantages become apparent, suggest to management that PairProgramming
become standard practice (in case they haven't figured it out themselves).
Do not let the atmosphere settle down on the PairProgrammingIsJustTraining
idea. If this ideas settles in, then as soon as training is 'over', the pairs will be split up.
Also, real PairProgramming
involves a relationship of equality, whereas training can often establish an unequal teacher-student relationship. Do not let this relationship become too ingrained and try to make it equal as soon as possible.
Note: Sometimes it is possible to have a training relationship that is more equal than student-teacher.
Extracted and reformatted from XpQuestions
If some of your staff is inexperienced, then sell PairProgramming
as a training technique. (Yes, it's a lot more than that, but PairProgramming
does work very well as a training technique.)
- There is concern on good people versus average people. How does XP work with average people? What if we were bringing in new people or right out of school?
as a training technique. It's the best training approach if you have a mix of people of differing skill levels. Everyone learns.
Actually, pairing improves skills even if everyone is average; every person, bringing a different background of experiences to the table, can contribute knowledge that the other person missed. Even experts can learn from novices, because our field is so diverse and deep with technical detail. -- JeffGrigg
I myself would not present PairProgramming
as training. For one thing there will come a day when it is expected that training is over. At that point it will be expected that you break up the pairs, but also you will be expected to produce twice as much. My experience is that you will produce less.
The second thing is that if you pair experienced with inexperienced right out of the starting gate you will set up teacher-student relationships and those are not pairs. PairProgramming
has a give and take between equals that can be hard to achieve and accept. The best way to start is to have the experienced people working together and the inexperienced people working together. Try to pair people together that will form an equality relationship. A shy experienced developer could work well with a fresh out. If you have a bully on your project you must watch for disruption of the pairing. Once pairs of equals are established then begin to mix them up. If you have advertised PairProgramming
as training you will not be able to pair equals together. -- DonWells
We are - very cautiously and gradually - beginning to give PP a try as a palliative to a low TruckNumber
. This meshes in, to some extent, with the notion of PP as training, with probably the same reservations as are made above - it needs to be installed as a continuing process, unlike training which usually happens once before "normal" activities resume. -- LaurentBossavit
I have been trying to SellPairProgrammingAsTraining
at my organization, and it has been working very very well. I'm working with another programmer who is not very experienced in the BestPractice
side of things. He's very enthusiastic about learning new things and we have developed a fairly equal relationship, so I can see a progression toward full-on PairProgramming
in the future. -- RobHarwood
This was how I learned what programming I know. My father and I were writing a stock exchange simulation, before his computer crashed. I would sit, watch and ask, "did you write a test for that?" Watching is certainly the best way to learn and PairProgramming
is a way to provide an environment where watching isn't quite so passive (besides, it's fun!)
I think this may be a self defeating approach. I am trying to get my development team to use pair programming, and everyone wants to be the mentor and tell the other person the "right" way to do things. Needless to say, the "mentored" partner is not too enthusiastic about the encounter. I am trying to use pair programming to provide focus for my team members and put a check against flights of fancy where the code is far out running the need.
This is really just an adoption pattern, a way to convince management to try pair programming. In other words, the 'sell' in the title means 'sell to management' not 'sell to developers'. You shouldn't actually proceed too far with it. If it's not working for you, stop, go back to normal pair programming immediately.
I would still caution against using this approach. If management is in favor or indifferent to the approach, no sales are needed. If management is opposed, then the expectation is set that training will be completed. I pity poor Johnny at his next review if his boss sees that he has been peer programming, i.e., undergoing training, for the last year.