I've read at several places that pair programming leads to productivity and quality gains. I'm trying to request my manager to introduce pair programming within my group, which currently consists of about 14 developers, 6 of whom I consider very good, 3 good, 4 average, and 1 poor. He likes the idea but his concern is that perhaps if a very good developer is paired with an average or poor developer, it could lead to a waste of time for the very good developer. He thinks that this is a very good technique to use for knowledge transfer and learning for the poor/average developers, but not sure about how much productivity/quality gains we can get from this.
What should be my arguments to try to convince him to atleast give pair programming a shot and see how it works out over the next few months?
- If you have knowledge transfer, then you can turn some of the "average" programmers into "good", "good" into "very good", and yes, even "poor" into "average", faster than it would otherwise have happened. Obviously there are direct productivity/quality gains there.
- Does he like code reviews? With pair programming, every line of code is "pre-reviewed." At least two pairs of eyes have seen all the code before it's checked in. Fewer broken builds, fewer bugs checked in, less downtime, higher productivity.
- Does he like devoting resources to debugging? No manager does. So anything that leads to fewer bugs being checked in is good.
- Does he like developers to spend their time sitting in meetings? No? Then with pair programming, knowledge gets transferred effectively throughout a team without the need for lengthy meetings.
- Does he like it when one of those "star programmers" leaves, and suddenly nobody understands some critical section of code? Well, with pair programming, there are always at least two people -- and generally more if you're doing it right -- who are familiar with every part of the code, so this doesn't happen.
- Does he like it when one of the average or poor guys goes off and does something misguided, and all their work for a day or a week has to be thrown out? No? Good. With pair programming, done correctly, this never happens.
I've observed that more often than not, from my experience working in a pair as an average programmer myself, I would find myself focussing mainly on my part of the code. (I'm talking about situations in which the 2 people involved are working on different machines on the same project and using CVS). So, I wouldn't be the one reviewing the code of the good programmer..so most of the times, i wouldn't even know how he has implemented something. On the other hand, the better developer would always look at the code that i would check in and thus do a code review for me.
So, if this is the case, then the better developer is not only doing his development, but is also having to review my stuff every time i check something in. Is that not a waste of his time? How do we get the average programmer to take out time (and knowledge) to review the better developer's code, when the average one is most likely worried about just getting his things right and working?
If you mix it up so that somethings you are the more senior, not just always the junior, I think the situation would change. It should also change in sections of the code you've been more active in and presumably know at least what you did and why.
If you did reviews for a couple of months and found that you never helped his code, then I suppose yes it would seem like a waste of time (although understanding what each other is up to doesn't seem like a negative). I think more likely you'd each find that you'd spot small problems early while they are still small and low-cost to fix, and you'd probably be more in the habit of bouncing ideas off each other because you know the other person understands the code you are talking about.
The only negative I've ever seen in pair programming is that if you have one really lazy person, and one hard-working person that feels like they can't open their mouth about the problem, then you can end up with an extremely unfair situation; the lazy one hides behind the labour of the other. The team lead or manager might need to keep an eye on that if they don't know the developers all that well (like when first getting thrown at an existing team or project). Probably not much of an issue if you have more than just two people doing this, and the pairs get mixed up periodically. [ March 08, 2006: Message edited by: Reid M. Pinchback ]
Originally posted by Shitij Agarwal: I've observed that more often than not, from my experience working in a pair as an average programmer myself, I would find myself focussing mainly on my part of the code. (I'm talking about situations in which the 2 people involved are working on different machines on the same project and using CVS)
This sounds like more of a situation of working on a team of two than pair programming. When you trade back and forth the keyboard/mouse, you are both working on the same part of the code. This gets both people focused on the task at hand and you can catch a lot of errors before even running the code.
I've been on both ends of the pairing spectrum. I've noticed that even if you pair with a really good developer, there is likely to be something you add that is of value. It may be catching a mistake earlier, knowledge of a topic, a new idea or even the value of hashing out an idea by discussing it.
Originally posted by Shitij Agarwal: (I'm talking about situations in which the 2 people involved are working on different machines on the same project and using CVS)
As Jeanne said, that's not Pair Programming. Pair Programming is two developers sitting on one computer, working on one piece of code together.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Originally posted by Shitij Agarwal: his concern is that perhaps if a very good developer is paired with an average or poor developer, it could lead to a waste of time for the very good developer.
That's a common and understandable concern, but one that in my experience doesn't manifest.
When I'm pairing with a developer who is less skilled, having to explain my thoughts to him already helps me a lot to better understand the problem, and to write better code that not only I can understand.
Joined: Jul 11, 2001
Another thought: if by "poor" programmer you mean that he produces bad code, he likely will also reduce the productivity of the team when working alone.