aspose 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

Payam Fard
Ranch Hand

Joined: Jan 31, 2003
Posts: 73
Hi all,
How does pair-programming work? Does it really make sense to have two developers' time on every single line of code? I agree that the code would be reviewed by two developers at the development time and also the developed code would include the thought process of two developers, but they could be producing twice the code if they code separately given well-designed system!
Any thoughts on this?
Thanks,
Payam.
George Harris
Ranch Hand

Joined: May 05, 2003
Posts: 84
My experience with pair programming has been quite successful when the programming task is reasonably complicated. Often a single programmer can start to 'garden path', slowing down the development process because the solutions are incorrect or improper. However when this same programmer works as part of a a pair, incorrect assumptions can be quickly corrected and the 'best' solution can be agreed upon through mutual agreement. This said, I found partner pairing a terrible mistake when the task is easier. It turns into a nagging session with one of the programmers insisting that the other type faster. Like all processes, there is a time and a place for pair programming. There are no perfect processes.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by George Harris:
I found partner pairing a terrible mistake when the task is easier. It turns into a nagging session with one of the programmers insisting that the other type faster.

That's interesting - my experience is quite different. To me it seems as if even the simplest taks can benefit from someone taking an eye on the bigger picture, on opportunities to remove duplication and to automate.
I wonder what might be the difference in our observations - can you please give an example of a task you don't think would benefit from pair programming? Thanks!


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
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Good points George. For those who have not tried it but are curious, I recommend trying it on small issues. For instanbce, maybe there's a new function you need to implement that's looking like it'll take about an hour or two. Grab your coworker and try it together. One to two hours is about right to do some serious coding, but not too big that is daunting and the complexities of the problem might effect your introduction to pair programming. Repeat as necessary to gain more experience.
--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Payam Fard:
How does pair-programming work?

Quite well, once you attuned to it...
Does it really make sense to have two developers' time on every single line of code? I agree that the code would be reviewed by two developers at the development time and also the developed code would include the thought process of two developers, but they could be producing twice the code if they code separately given well-designed system!

Only if the critical work of a programmer was typing. Where I work, it isn't.
For me, the critical part is the thinking - and it seems as if a pair is much better here than a solo programmer.
Did you ever ask a coworker to sit by your side and take a look at a bug you were hunting for hours - only to find the bug a minute later simply by explaining the code to him? Well, with pair programming you probably wouldn't even have introduced the bug because of the same effect.
Two academical experiments, as well as anecdotal evidence from teams all over the world, suggest that programming pairs only need a short amount of more time for a programming task than two solo programmers, producing less code (for the same functionality!) und introducing much less bugs.
[ May 13, 2003: Message edited by: Ilja Preuss ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
There is a very interesting past thread on the topic, including some comments from Martin Fowler.
lechon manok
Greenhorn

Joined: Nov 12, 2002
Posts: 7
I agree with Ilja, the thinking part is critical - two heads are definitely better than one. This to me is the most important benefit of pair programing.
It would also be interesting to know if any social or personality issues come into play. How well does a developer with a "lone wolf" personality adapt to pair programming? What if contrasting personalities make it very difficult to work together?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
If you are trying out Pair Programming, take a look at http://www.xprogramming.com/xpmag/Etudes.htm#N84
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by lechon manok:
I agree with Ilja, the thinking part is critical - two heads are definitely better than one. This to me is the most important benefit of pair programing.

I just remembered another benefit - I am more disciplined when PPing: I am more likely to write tests first, to refactor appropriately (remember, a second person will have to understand the code) etc.
It would also be interesting to know if any social or personality issues come into play. How well does a developer with a "lone wolf" personality adapt to pair programming?

In my experience, even those can learn to PP and start to like it more. They will probably need some additional "safety nets" at first, though.
There are certainly those who just won't collaborate with someone else. I wouldn't know what to do with them in a team context anyway, though...
What if contrasting personalities make it very difficult to work together?

Well, it *can* be very interesting and productive. If it isn't, they probably find other coworkers to pair with. Again, it seems to be a broader team issue to me, needing to be resolved anyway...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ilja in another thread:
Well, *there are* crossplatform solutions for this - for example there is an eclipse plugin for pair programming: http://sangam.sourceforge.net

Is someone using this (personal experiments excluded)?
My initial feeling about this "distributed pair programming" is, as usual, sceptical. Don't you lose a lot of the precious communication by putting an extra layer of keyboards and displays between the pair?
[ May 14, 2003: Message edited by: Lasse Koskela ]

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Awais Bajwa
Ranch Hand

Joined: Jan 16, 2001
Posts: 191
May i know that is there any relation between Extreem Programming and Pair Programing?
Regards
Awais bajwa
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Pair programming is one of the key practices of Extreme Programming.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Awais Bajwa:
May i know that is there any relation between Extreem Programming and Pair Programing?

Pair Programming is one of Extreme Programming's practices. In other words, PP is a part of XP.
randal alan
Greenhorn

Joined: Jun 14, 2002
Posts: 9
My experience with XP was by happenstance. It occurred at a customer site where a myself and a coworker from IBM Taiwan were required to gather requirements, help design and implement a solution within a weeks time. At the time, it appeared that the only way to accomplish the work within the allotted time was to split the work load, and constantly check that each other was headed in the right direction. What we noticed was that the more we "checked each other" the more we were able to flush out flaws and bugs effortlessly. By the end of the first day, we quickly decided that we would make better progress if we worked on the same thing together checking each other, instead of going opposite directions. We finished our project one day ahead of schedule and learned something about XP without even knowing it.
randala@us.ibm.com
L Duperval
Ranch Hand

Joined: May 14, 2003
Posts: 63
Originally posted by Ilja Preuss:

Well, it *can* be very interesting and productive. If it isn't, they probably find other coworkers to pair with. Again, it seems to be a broader team issue to me, needing to be resolved anyway...

My experience has been that very seasoned developers and very green developers make for difficult pairings. The ideal pairings I have foudn are senior-senior, senior-intermediate and intermediate-junior. senior-junior pairings tend to intimidate the junior and tend to frustrate the senior. intermediate-intermediate may lead to slower learning. But that last one, I'm not sure about.


Live Free, Live Happy
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Laurent Duperval:
My experience has been that very seasoned developers and very green developers make for difficult pairings. The ideal pairings I have foudn are senior-senior, senior-intermediate and intermediate-junior. senior-junior pairings tend to intimidate the junior and tend to frustrate the senior. intermediate-intermediate may lead to slower learning. But that last one, I'm not sure about.

The "seniority" needs to match (to some degree) on technical skill but also on the "methodology skill." However, the line is very difficult to draw. I'd even say it's impossible. How do you even define the difference between senior and intermediate? Notches on the keyboard?
The suitable pairs will form themselves. I hope.
John Mathew
Greenhorn

Joined: Jun 06, 2002
Posts: 8
My experience has been that very seasoned developers and very green developers make for difficult pairings. The ideal pairings I have foudn are senior-senior, senior-intermediate and intermediate-junior. senior-junior pairings tend to intimidate the junior and tend to frustrate the senior. intermediate-intermediate may lead to slower learning. But that last one, I'm not sure about.

In XP the pairing has nothing to do with seniority. Pair programming in XP works only if Personal Egos do not interfere woth work. I have found lot more egos in Software engineering than any other field. As for pairing senior- junior, it is mostly done to get the junior on speed with the practices followed in the organization and also is the best way to lear OOP
My Experience has found pair programming as defined in XP very unproductive on everyday programming. What I found working is code review with a peer and also on bug tracking. It does help in designing too. Coding ???, just my experience / opinion
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4757
    
    7

Originally posted by Rajeev:

Pair programming in XP works only if Personal Egos do not interfere woth work. I have found lot more egos in Software engineering than any other field. [..] My Experience has found pair programming as defined in XP very unproductive on everyday programming. What I found working is code review with a peer and also on bug tracking.

Seems to me you have the wrong understanding of the mechanics of pair programming. Using the car analogy, there's only one steering wheel (the keyboard). The two people take turns driving but only one person, the driver, has control of the car at any given time. The person not driving takes care of navigation: reading the map, looking out for obstacles, planning the route, etc. The point is, the two are not performing the same tasks. One is operating on the code level while the other operates on a higher level, thinking ahead and doing planning, making sure that they are not losing sight of the "bigger picture."
As Ilja mentioned before, there have been studies that showed that pair programming actually results in an overall increase in productivity because of the higher quality of code that is produced. The less time you spend debugging your code, the more time you have to do more productive things.
So instead of saying that pair programming is not productive, you should probably ask why your attempts at it were not as productive as you expected it to be.


Junilu - [How to Ask Questions] [How to Answer Questions]
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
some random thoughts...
Assertions that pairing costs twice as much do not take into consideration the reduced number of defects, the reduced debugging time, and the reduced amount of time to review/correct/understand poorer code (produced by single developers). They also don't take into account the fact that developers working alone in cubes tend not to be as disciplined about actually working all day long.
---
Seasoned and green developer pairings are difficult, indeed. The theory, though, is that all developers on a team come up to a minimum level of capability, and far more quickly than if everyone was working alone. A novice in a cube will remain a novice for a long time. A novice paired with an intermediate or senior developer will ramp up very quickly.
Pre-XP, I've been on projects where we depended on a supposedly mid-level developer to get his work done. He was late and the code he produced stunk, to put it nicely. The whole team suffered because this guy was off in a corner producing junk, and no one was aware of the problem until it was too late.
I consider myself a senior developer, yet I always get value out of having a second developer work with me, even if they are completely green. The design is improved, code quality is improved, and (as another poster mentioned) disciplines are adhered to.
With this in mind, I'm far more willing to be patient as a "senior" developer. I would rather know early on in the effort than late in the game that some developers on the team aren't going to be able to produce. Either the novices come up to speed quickly, or they don't, in which case it's an issue that can be immediately raised to management for resolution.
With pairing, all developers quickly know at least something about all pieces of the system. Benefit to the company: no "hit by a bus" syndrome, ability to quickly move developers in and out of efforts, lower cost to ramp up developers, higher quality system. Benefit to the developers: resume building.
I enjoy pairing: I know that I don't have all the answers, so pairing provides a significant source of stress relief--I know that there is someone else on the team that will be able to help me when I need it.
-Jeff-


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeff Langr:
I enjoy pairing: I know that I don't have all the answers

Yeah, and even for those I have, it seems much easier to work them out if I have to explain them to someone else. And at times they really sound stupid that way...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I frequently stand up just to make a U-turn half-way to a colleagues (semi)cubicle because I realize what I'm missing while formulating the question... If nothing else, it makes a little contribution to my health
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pair programming