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

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20271
    ∞

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.

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Bryan Welch
Ranch Hand

Joined: Jan 13, 2000
Posts: 32
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
bwelch@abcv.com


----<br />Bryan Welch<br />bwelch42@yahoo.com
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
David Roberts
Ranch Hand

Joined: Nov 03, 2000
Posts: 142
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


David Roberts - SCJP2,MCP
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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?
Bill Prentice
Greenhorn

Joined: Mar 06, 2001
Posts: 26
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

Joined: Mar 06, 2001
Posts: 26
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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
Dianne Spillers
Greenhorn

Joined: Mar 05, 2001
Posts: 9
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.
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
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

author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
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

Joined: Mar 05, 2001
Posts: 9
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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).]
Kostas Perrikos
Greenhorn

Joined: Mar 01, 2001
Posts: 3
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.
Sowmya Karmali
Greenhorn

Joined: Mar 30, 2001
Posts: 10
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

Joined: Mar 06, 2001
Posts: 26
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
Good one Bill and thanks for sharing Sowmya.
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
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.
Eric Kramer
Greenhorn

Joined: Apr 04, 2001
Posts: 1
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).]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

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?


Junilu - [How to Ask Questions] [How to Answer Questions]
Michael Finney
Ranch Hand

Joined: Jan 25, 1999
Posts: 508
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


Michael Finney - "Always Striving To Serve You Better Every Day"
http://www.smilingsoftwaresolutions.com/
Ct Arrington
Author
Greenhorn

Joined: Jan 17, 2001
Posts: 27
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


Blog | Getting Started in Software Development
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
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.


<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>"Those who cast the votes decide nothing. Those who count the<BR>votes decide<BR>everything." <BR> -Joseph Stalin<HR></BLOCKQUOTE>
martin fowler
Author
Ranch Hand

Joined: Dec 11, 2000
Posts: 53
I've often said that Pair Programming would be stupid if the hardest part of programming is typing....
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
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
Tim Grandison
Greenhorn

Joined: Mar 09, 2000
Posts: 6
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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).]
Greg Pfeil
Greenhorn

Joined: Apr 05, 2001
Posts: 11
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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

Joined: Apr 05, 2001
Posts: 11
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

Joined: Apr 05, 2001
Posts: 11
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
Bartender

Joined: Jan 27, 2001
Posts: 5089
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pair programming
 
Similar Threads
Quartet Programming
Pair programming
Question on pair programming to the authors
Some developers hate XP - do they???
TDD/XP - sharing thoughts