Effective vs Ineffective Pair Programming
skorks.com
skorks.com
- Both partners must be fairly versed in the language and methodology of the programming. I think its fairly explanatory, but there is a definite limit to how much of a knowledge gap there can be between the experienced and un-experienced programmers. If that gap is too big the only result will be slower coding, written at about the same quality as the more experienced programmer would write on their own, but with considerably more frustration on both programmers' parts.
- Do not do a "test trial" of pair programming, working on simple projects. From what I has read about research into pair programming, the only gains come from working on complex problems which would be difficult to conceptualize entirely in one person's head. If work is only done on small projects, pair programming will look like a complete waste, since non-pair programming would have similar results considerably faster.
- Pair programming has a sort of half-life in terms of knowledge. The lower-skilled of the pair will learn half the gap in knowledge at aproximately the same rate. While that rate will be different between people, from my experience with pair programming, the lower-skilled partner will learn half the knowledge gap in 3-4 days. This will repeat, and the gap is halved every 3-4 days of working together.
On top of that, it seems to me that Pair Programming is not a good fit for long term programming. It seems best suited when there is an individual who needs to learn about a specific system, and that using it long term lessens the effectiveness it has. Once the transfer of knowledge has slowed down, and both individuals know aproximately the same ammount about the system, it seems to be much less effective. However, since their (should be) a constant learning about the system, occasional pair programming sessions would be advantageous after this point.
If I were to engage in pair programming, this is roughly how I would set it up:
Assuming that there a 5, 8-hour work days, divided into 2 4-hour programming sessions (for a total of 10 sessions a week), when a new individual is introduced they should spend the majority of their time pair programming with the more advanced individuals. While I am just pulling this number out of thin air, I would think 8 sessions of pair programming the first 1-2 weeks, with 2 sessions programming alone. As time progresses, I would shift to steadily less pair programming, with a minimum of 2-3 sessions per week.
This is largely because I am not convinced Pair Programming leads to better coding. I have not seen any real evidence to support that, in fact, from what I have seen it tends to slightly more convoluted and difficult to debug code (although pair-debugging seems to be incredibly effective). I have, however, seen how useful pair programming is in teaching a person. The ammount a person can learn in a short time, while working in a pair is incredible, and can be simply astounding.
It is good that you see the knowledge transfer benefits, but I much prefer thinking of it as knowledge distribution rather than transfer. By this I mean that your setup creates continual knowledge gaps and then fills them in the pairing session. That seems much less valuable than actually distributing the knowledge throughout the team by pairing all of the time.
I recommend you keep an open mind about the other major benefits of pairing and that you actively seek good pairing opportunities. It is worth it and you will know it when you experience good pairing.
I disagree with saying that constantly distributing knowledge by always pairing is a better situation. It makes the assumption that everything that can be known about a system is already known, which doesn't often (ever?) hold true. By separating out, you can cover far more area and find more of those unknowns, while coming together for regular pair sessions helps spread that newly discovered information around.
No, it does not. I'm not sure where you extracted that from in my comment.
Also, if you are aware that your environment was terrible, it seems presumptuous to assess the benefits of pairing in a good environment. I assure you there is more than teaching at play.
So then, what constitutes "good"? This article seems to focus on the code, which I think can matter, but I believe is much less important than the people having the ability to pair effectively, which in my experience consists of two things: (1) the ability to clearly articulate what one is thinking, in real-time, and (2) the ability to allow your partner's ideas to be better than your own. It also helps if you don't get annoyed by someone asking you questions while you code, but that's less important, because you'll get over that if you and your coding partner have (1) and (2).
Pair programming is an agile practice and in my experience it is a LOT easier to do agile when you have good people on your team, not just good developers, but good human beings.
The best experiences were when both of us were learning a new API and type of program. That's the sort of thing where you are likely to make lots of small mistakes, and it's a lot less frustrating when you have someone else to help catch them.
The worst experiences were when the programs were relatively easy, and there was just a lot of stuff to be done. The person watching gets bored, and the person coding gets distracted.
I feel like if one person is confident they can bang something out, just do that. If it's the sort of annoying programming neither of you want to do, it helps to pair. Hard to have general rules though for such a personality-dependent activity.