• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Pair Programming

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

Thanks.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
- 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.

There are more...
 
Shitij Agarwal
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ernest, I found "Does he like ..." pretty profound and very nicely done. I'll copy those bullets to the team. Thanks!
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Instead of asking your manager for permission, why don't you just start doing it? What's stopping you?

- Scott
 
Shitij Agarwal
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you so much guys for your responses. Very helpful. I most certainly was confusing two people working together on a project with pair programming.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic