Effective vs Ineffective Pair Programming(skorks.com)
skorks.com
Effective vs Ineffective Pair Programming
http://www.skorks.com/2009/07/effective-vs-ineffective-pair-programming/
3 comments
To me, your comment spells out quite conclusively that you have not been part of a good pairing environment.
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.
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.
It was a terrible pair programming environment. Pair programming was simply being used to up the average grade of the class (which succeeded).
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.
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.
It makes the assumption that everything that can be known about a system is already known
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.
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.
I used to be a big pair programming zealot, but I've backed off, since I've seen it fail with so many people at so many places. Having said that, the times I've worked in good pair programming environments have been the happiest, most productive times of my life (at work, anyway).
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).
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).
I agree with you, I suppose I tend to take those things for granted, possibly because I've been fortunate enough lately to work in environments where both 1) and 2) are pretty much a given (lucky me).
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.
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.
Your comment is better than the article. Thanks.
I've had some good, some bad experiences with pair programming.
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.
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.
- 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.