• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Pair programming

 
Trailboss
Posts: 23999
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One part of XP that I'm the most skeptical about is pair programming. I can see that pair programming would be better than individual programming without code reviews, but I can't help but wonder if there is a more optimal medium.
In other words, if you have a spectrum where on one side you have pair programming and on the other side you have solo coding, and the middle is different levels of code review ... I wonder if there is a level of code review that produces higher productivity than pair programming.
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you want to get unpopular with a manager, just mention pair programming.
When trying to figure out a good way to get around a design problem, or to implement an architecture change, I think pair 'programming' (or perhaps here it's pair designing) is useful. This is the area where two minds can complement each other and come up with a better design where more of the problems have been anticipated and avoided.
------------------
----
Bryan Welch
[email protected]
 
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
I agree that pair programming is probably the most contentious part of XP, but I think that's often because we can't help envisioning it in a non-XP setting. In a more traditional "waterfall" process, where analysts, then designers do the thinking before giving to programmers to do the actual coding, pair programming seems a complete waste of effort. But XP is not like that.
Paul proposes a spectrum from solo coding to pair programming. May I propose another, in this case from "programmers are just typists" through to "programming involves everything: dealing with customers, testing, design, coding, delivery etc." Where your process is on this scale strongly affects the utility of pair programming. If you doubt this, consider the other functions included at the "everything" end of the spectrun above. Sales, marketing and customer liaison often live in meetings, designers routinely work together. Two designers hunched over one drawing board is almost a visual cliche! If close collaboration is acceptable for these types of jobs, and they are included in the requirements for a "programmer", then pair programming should not seem so odd after all.
The other thing to bear in mind is that many people have had bad experiences with a "watch and learn" (or "how long is it to lunch?") style of pair working. This can be very irritating for both participants. XP strongly advocates that if the pair have differing skill levels in the task under consideration, the less-experienced member of the team be in charge of the keyboard (which helps prevent boredom.) If either member needs to express something complex, rather than the typist taking dictation, the keyboard passes to whoever has the idea.
All of this comes with the caveat that I have done very little pair programming myself, but I know people who have, and some of them are very enthusiatic about it.
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our managers seem to love the idea of Paired Programming. They like knowing that if one person leaves, the other still has the knowledge of that piece of the product.
You guys are right though, most managers think they are paying twice as much for the same thing...
I find two people can tackle a serious issue more then twice as fast as one person. Especially since one person tends to procrastinate. spelling??
------------------
David Roberts, SCJP2
 
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does pair programming go down as far as two programmers coding the actual program together ie. sitting together at a screen one types and the other one passes suggestions / knowladge. Or do they discuss what a program should do and then each one goes and programs his own program with code checking ala nitpicking Cattle Drive style at the end?
Do you already see good pairs staying together ie. hey thats a great pair get them on the project and not just, get that good programmer.

[This message has been edited by Johannes de Jong (edited April 03, 2001).]
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually ignore my previous question reagrding stiiting together at a screen I found the following on the extreme programming site :
The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth.
Now the following question arises. How can pair programning work in our open-plan office environments. Surely these two programmers are going to discuss the program they are busy with whilst they code. This could/will be disruptive to the other people in the office. It is then a requirement that the pair should be put alone in an office?
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As a organisation we have not adopted XP, but by coincidence we have tried pair programming. The results were not encouraging. It was my personal experience that one of the pair seemed to do most of the work and it was necessary to choose up the pairs very carefully due to differing skill levels, personality and experience. On a large existing application it was almost impossible to overcome the code ownership problems. Maybe it would work better on a new project.
 
Bill Prentice
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Roberts:
Our managers seem to love the idea of Paired Programming. They like knowing that if one person leaves, the other still has the knowledge of that piece of the product.
You guys are right though, most managers think they are paying twice as much for the same thing...
I find two people can tackle a serious issue more then twice as fast as one person. Especially since one person tends to procrastinate. spelling??


I think the first point is more applicable to the "Move People" aspect of XP. I have a problem with pairing a seasoned programmer with a novice, this is surely training rather than PP.
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bill Prentice:
It was my personal experience that one of the pair seemed to do most of the work ..


I'd love to meet the guy that thinks he will get away doing nothing while I do all the work
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am new by comparision to others to the programming world but I would like to share my recent experience with pair programming and XP.
Our company took on the task of writing an application for problem, change and inventory management about 1 1/2 years ago. I got involved in the project about 6 months after it started and was introduced to XP. Since I was a relatively inexperienced Java programmer at the time, I looked forward to being able to learn from some of my more experienced Java developers. After reading XP Explained and getting management to buy off on the paradigm, we got down to the task of coding. Things rocked along very well at first. Everyone felt very comfortable in their roles that they had given themselves and our coding efforts as pairs were producing very logical easy to read code, that anyone could have come behind us and understood. I learned alot of new skills and language with the pair programming we were doing and was feeling more and more comfortable with Java. Then our dynamics changed. Our coach got very disgruntled with the project and it started to trickle down through the rest of the group. Pair programming came to a halt and in my opinion, the project started to suffer greatly. We went from alot of discussion/sharing our code to the attitude that I wrote that you can't touch it!
I think that pair programming has merit. It takes your more inexperienced coders and gives them a chance to be better with out the cost of formal training. It also gives your experienced coders an opportunity to share their knowledge and experience. There just seems to be one caveat to me. The coach's role in this process is very very important to the cohesion of the team. The person filling this role needs to be able to put aside any ego issues and really fill the role as coach. In my experience with XP, this is the most singlely important role on the team.
I am happy to report that because of the pair programming that was utilized in the beginning, I am well on my way to finishing not only the application but getting my certification.
 
Author
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Johannes de Jong:
Now the following question arises. How can pair programning work in our open-plan office environments. Surely these two programmers are going to discuss the program they are busy with whilst they code. This could/will be disruptive to the other people in the office. It is then a requirement that the pair should be put alone in an office?


Many XPers prefer the open plan office and pairing works well in that environment. The key is that everybody is working on the same project, so an open plan project gets more informal communication. The conversation leads to a general hum, but I didn't find it disturbing.
Martin
 
martin fowler
Author
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dianne Gibbs:
I think that pair programming has merit. It takes your more inexperienced coders and gives them a chance to be better with out the cost of formal training. It also gives your experienced coders an opportunity to share their knowledge and experience. There just seems to be one caveat to me. The coach's role in this process is very very important to the cohesion of the team. The person filling this role needs to be able to put aside any ego issues and really fill the role as coach. In my experience with XP, this is the most singlely important role on the team.


Pairing with newbies isn't all about mentoring, although certainly that becomes an important part of the exercise. Even pairing with a newbie I'm more effective than when programming on my own. Being forced to explain what I'm doing has an important effect in coming up with better designs and in reducing defects.
Certainly the coach has a big influence, and a bad attitude there can affect the whole team.
Martin
 
Dianne Spillers
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with you Martin, that pair programming isn't all about mentoring. Having a newbie asking you a hundred 'why' questions leads to different new ideas and apporaches to the same methods and forces some more experienced programmer to take a fresher view and what they were convinced was the only way to do things.
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Must say that the mentoring side of pair programming appeals to me. As for the noise I suppose one has to experience it. We however, the dutch, are very load people I think it might get very disturbing.
Martin, thanks for your time by the way, is it your experience that pairs stick together. The old saying goes why break up a good team. I think we might see a new phenomenon a pair buiding a career together as one sees/saw in the entertainment world
[This message has been edited by Johannes de Jong (edited April 03, 2001).]
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would especially agree with the opinions of Martin Fowler and Dianne Gibbs. Although i believe that pair programming may be helpful sometimes, the thing i agree is the idea of the "source safe" coding so that the programmers know the exact coding specifications of the others, so that to establish standard procedures in their coding. I believe that this is helpful not only in pair programming, but from the side of future additions that may need to develop in the program, these procedures save time.
Pair programming, i think is very beneficial especially in large projects where many teams should break apart the project and focus in small aspects of it.
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Confessions of a pair programmer
I have worked as part of a pair in two projects so far, and I place my observations here.
The first thing that arises out of PP is synergy. Within weeks, I found that I was learning more by way of discussion than I would have had I been on my own. Pairing a fresher with an experienced guy sounds ideal, but there is often a "thinking lag" on the part of the fresher, which can be irritating to the pro. What we did was pair freshers, and also get their code reviewed by a more experienced guy. This eases the situation in that the freshers learn from the pro without affecting his productivity.
One more obvious benefit of PP that we found was that we could manage well even if a person was on leave.We did move people around, but that was only on a couple of occasions.
One benefit that I have noticed, years after this activity, is that people who have worked in pairs ( and moving around as well) are capable of taking different points of view when approaching a problem. When pair programmers graduate to pair designers and pair architects, you know you have a good thing going. Pair programmers are more open to criticism, newer ideas, etc.(Look at me )
Of course, I've observed the flip side of it too. Ego clashes, lethargic approach are also part of the game. But these things could exist without PP also; it is upto the more rational people to handle such issues.
Sowmya
[This message has been edited by Sowmya Karmali (edited April 04, 2001).]
 
Bill Prentice
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One more problem that might arise is a clash with the current trend towards working remotely. We allow and facilitate "working from home" on a regular basis which makes pair programming impractical. Pity, the alledged benefits are attractive.
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good one Bill and thanks for sharing Sowmya.
 
martin fowler
Author
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Johannes de Jong:
Martin, thanks for your time by the way, is it your experience that pairs stick together. The old saying goes why break up a good team. I think we might see a new phenomenon a pair buiding a career together as one sees/saw in the entertainment world


In XP it's important to rotate the pairs. Often you might pair with one person in the morning and someone else in the afternoon. This is because different combinations of skills are needed for different tasks, but primarily becuase swapping pairs helps spread knowledge around the team.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This might sound naive, but is part of the stigma associated with "Pair Programming" the concept that all these two people are doing is keying in code? It might help avoid this knee-jerk mental image if it were called something like "Pair Development" instead, as connotes (to me, at least) an image of the truer collaborative process undertaken in successful "Pair Programming"...?
[This message has been edited by Eric Kramer (edited April 04, 2001).]
 
Sheriff
Posts: 17734
302
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
I would say that is a common misconception about PP. One senior developer in my company who is all for RUP but highly skeptical about XP always says this about PP: "You're paying two people to sit at one workstation working on the same thing." This totally misses the point.
J.Lacar

Originally posted by Eric Kramer:
This might sound naive, but is part of the stigma associated with "Pair Programming" the concept that all these two people are doing is keying in code?


 
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
FYI
For more information in order to get the point, see http://www.pairprogramming.com/ and http://c2.com/cgi/wiki?PairProgramming (Wiki editable page)

------------------
Michael Finney
Sun Certified Programmer for the Java 2 Platform
Sun Certified Developer for the Java 2 Platform
 
Author
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all
I have used pair design and pair programming intermitantly for the past couple of years. I really like it.
Some advantages I have seen:
Much higher energy levels - two people can crank through mentally challenging work for a long time, and like it.
Much higher levels of commitment
Much higher overall useful output
Cleaner and more readable design and code
More innovative design and code
Very high quality as an entire class of logic bugs are caught realy early
Great mentoring and learning opportunities
Built in redundancy in case of short or long term loss of a key developer.
I definitely think that side by side, with one mouse, one keyboard, and one monitor is the only way. I have gotten to the point of one person using the mouse while the other types. It sounds strange, but when it works it is really inspiring.
My $0.02
CT

------------------
C.T. Arrington
Author of Enterprise Java with UML
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The managers who feel like they are paying two people for the work of one are thinking what? That the limiting factor on programming productivity is typing speed?? Maybe they should hire touch typists--productivity would go through the ceiling!
I'd like to try some pair programming, but I don't know when I'll get the chance. I can't even seem to convince anybody on my team of the value of unit testing, so we're a very long way from XP. Around here, the half that do the simplest thing that could possibly work are not the same half that believe in refactoring....
Oh well.
 
martin fowler
Author
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've often said that Pair Programming would be stupid if the hardest part of programming is typing....
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for making my job seem important again Martin
By the way CT thanks for your book, I won it 4 weeks ago, havent received it yet, but am looking forward to it
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For those of you who prefer a scientific approach to an otherwise contenious issue, check out the following:
Paired Programming Study
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Laurie Williams has her own site on Pair Programming http://www.pairprogramming.com/
[This message has been edited by Johannes de Jong (edited April 05, 2001).]
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by martin fowler:
In XP it's important to rotate the pairs. Often you might pair with one person in the morning and someone else in the afternoon. This is because different combinations of skills are needed for different tasks, but primarily becuase swapping pairs helps spread knowledge around the team.


I am on a team using PP at the moment. Our project manager and most of the developers are relatively young, and so we have been experimenting with different practices along the way. XP has been by far the most productive approach. And PP the best aspect of it.
There was a bit of resistance from managers at the beginning, but as they pretty much leave us alone, it only trickled in through comments like "What is this, a love in?" and "Did Greg break his hands so he needs you to type for him?"
Recently, we had a major release of our software, and we to the short downtime afterward to go over our practices and decide what worked and what didn't. PP came out on top. Nothing else even approached the productivity of the time we were working that way.
Anyway, the point I'm trying to get to, is that rotation is definitely necessary, but we usually rotated about once every three weeks (occasionally a third person would be called over to explain a particular point, but since the whole project was done in a way that we all understood the whole, it never disturbed the groups much). Every three weeks (give or take -- it was really how long our iteration was) was perfect -- at that point, spending 8 hours a day with the same person is just starting to get on your nerves, and you're ready to move to a new piece of the project (well, every 6 weeks for that part, since you spend two iterations on a particular section), and a new partner.
In a pair, I was more likely to push myself (well, if _he_ doesn't need to take a break, neither do I) rather than slack, and it was always good to be able to pass the keyboard to someone else when your fingers started getting slow, or your eyes blurred.
Also, the novice-mentor thing isn't necessary in my opinion -- it happens for part of the project just because you're in different pairs, and also, I learned plenty from the developers who were less experienced as well. It was fun, and I was more focused than at any other point.
Since I've already rambled this far, I have a completely unrelated note: This is my first post, and I just read, "Disable Smilies in This Post." However, I read it as "Similies", and couldn't figure out for the life of me why you would want to disable similies.
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Greg thanks for sharing your experience. If I may ask, what sort of company do you work for?
And do yourself and your team a favour and complete the survey on
http://www.pairprogramming.com

Original mesg at the start of the survey:
If your testimonial is printed, we would like to offer you a free copy of the book. These testimonials are important to us and we want to thank you if yours is chosen.


[This message has been edited by Johannes de Jong (edited April 05, 2001).]
 
Greg Pfeil
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Johannes de Jong:
Hi Greg thanks for sharing your experience. If I may ask, what sort of company do you work for?
And do yourself and your team a favour and complete the survey on
http://www.pairprogramming.com


The company I work for is XML Global Technologies (http://www.xmlglobal.com/), and the particular project I was talking about was GoXML Search, which is a component of the GoXML Foundation suite.
It's a young company, designing XML-oriented technologies. I enjoy it a lot, and find that I have quite a bit of freedom. Our projects aren't extremely large, mainly because, being techie-driven, we have a lot of modular components we've developed.
That's really one of the benefits of XP, I think -- a lot of people complain that it doesn't work well on projects that are too large for a single person to understand completely, but I don't see how a project should ever reach that size.
As we start seeing pieces grow past what we originally envisioned, they get pulled out and are no longer a part of the project any more than a third-party library we might use.
If you start with XP _before_ the project is too large, it protects you from bloat problems. You see when it gets too big (because every time you start working on a different piece, you have to take some time to recall how that piece fits in), and you make some pruning decisions.
Not only does this help your project, but other projects are always happy to find some reusable components floating around (and hey, aren't components the Next Big Thing?).
 
Greg Pfeil
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One other thing I wanted to talk about was some of the ways we did pair programming.
Most of our developers have two computers -- a desktop and a laptop (some bring a laptop from home, others have one supplied by the company). When we're working in a paired situation, we _usually_ both work on the same box. However, having the second box there is extremely helpful.
Sometimes, questions come up that can't be immediately answered by the pair, or possibly anyone else on the team. It's then that the person who isn't currently coding will grab the other box, load up Netscape, and start looking for an answer, or shoot off an email to a mailing list, or some other such thing.
It allows a bit of multi-tasking without the typist ever having to get his head out of the problem space he's currently working on.
Now, we develop on Linux. For other platforms as well, but we code in Linux. As such, we all have our preferred environments. I'm a hard-core Enlightenment hacker with my own hand-made theme and keymappings for everything, with a preference for gvim. Others use Gnome, or KDE, or almost anything else. Some even have a deep religious attachment to emacs.
While there really hasn't been too much of a problem yet (I rarely work at my own desk, since I don't want to force anyone to deal with my horribly tweaked environment, or my Sun-layout keyboard, or my trackball, or any of my dozens of other oddities), I wonder if it's at all possible to do PP with each of us using his preferred setup.
We're currently evaluating a number of IDEs for potential use (maybe we'll start doing Delphi in Kylix), so that would definitely help to create a homogenous environment, but I'm very much of the opinion that everyone should be allowed to do it their own way. Maybe that just won't work here.
 
Johannes de Jong
tumbleweed
Posts: 5089
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The idea of the one coding whils the other one is sreaching the net for a possible answer to the problem never occured to me as another advantage of PP. Thanks for sharing Greg.
By the way be Bill might be able to use your expertise see http://www.javaranch.com/ubb/Forum19/HTML/000379.html
I surfed to your the site of XML Global. Really looks like a nice company to work for. I've always liked the idea of working for a company whose product is the software they make. I work as a mainframe programmer at a large bank (ING) in the Netherlands by the way.
As a matter of interest you might pass on the following info to the web-designer responsible for you companies site. On http://www.xmlglobal.com/comp/careers_opportunities.jsp its extremly irritating that one only gets told that there are no oppenings after you click on position available you might be interested in.
 
Yeah. What he said. Totally. Wait. What? Sorry, I was looking at this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic