• 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

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
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 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!
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
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 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a very interesting past thread on the topic, including some comments from Martin Fowler.
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are trying out Pair Programming, take a look at http://www.xprogramming.com/xpmag/Etudes.htm#N84
 
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 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...
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
May i know that is there any relation between Extreem Programming and Pair Programing?
Regards
Awais bajwa
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pair programming is one of the key practices of Extreme Programming.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

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

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

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
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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-
 
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 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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic