File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Pair Programming Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Pair Programming" Watch "Pair Programming" New topic
Author

Pair Programming

Shitij Agarwal
Greenhorn

Joined: Dec 09, 2004
Posts: 21
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.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

- 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...


[Jess in Action][AskingGoodQuestions]
Shitij Agarwal
Greenhorn

Joined: Dec 09, 2004
Posts: 21
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?
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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 ]

Reid - SCJP2 (April 2002)
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29247
    
139

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Ernest, I found "Does he like ..." pretty profound and very nicely done. I'll copy those bullets to the team. Thanks!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Instead of asking your manager for permission, why don't you just start doing it? What's stopping you?

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Shitij Agarwal
Greenhorn

Joined: Dec 09, 2004
Posts: 21
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pair Programming
 
Similar Threads
making the mathematical case for pair programming
Question on pair programming to the authors
JPA Caching for Performance
Pair programming sucks
Quartet Programming