Pair Programming Testimonials

If you would like to share your pairing experiences or read about other people's, this is the place. Describe the good and bad of your experiences pairing to help others in a similar situation - just a paragraph or two would be great . . . what worked well, what didn't work so well, what kinds of things did you 'attack' together, tips and tricks, etc. A great example of a testimonial is by Ron Jeffries in the July/August 2000 IEEE Software page 25 (http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.pdf). BrokenLink 20050628

Sign your testimonial if you want credit for it in publications. Thanks! -- LaurieWilliams

I work for a company producing automotive software in Java. I worked on a model of vehicle electronics in Java paired with one of our "vehicle experts". I was the Java/OO/Patterns expert - he was a C++(converting to Java)/Vehicle hardware expert. The model we produced reflected these differing skill sets and improved our respective understandings of the others disciplines. The code produced was some of the best I have ever seen in the company - very clear, simple and logical. Now we have two people totally bought into the design to "sell" the package to other technical teams - each portraying the benefits from their particular area of specialization....

We will never know how long it would have taken to write in isolation. Probably a similar amount of time. But we are certain it would not be of as high quality. Lesson: Pair programming works!

Chris Senior - Teradyne (http://www.teradyne-ds.com/)

I worked at Nortel Networks on a scriptable client simulation project in Java. The clients were to run in a single process and to connect to corba middleware. Three programmers worked on the project, with one being remote and the other two in the same location who did some pair programming.

The two in the pair worked quite well together, but worked together only occasionally (a few couple hour sessions a week). These sessions were very productive, more so than with both working separately. The two complemented each other very well. One with graduate work in mathematics and the other an undergraduate code warrior.

One big benefit was that when working together the work flow was more consistent: nobody would drop by and bother us, one could look up API syntax and semantics, one was focused on the details of the moment where the other was looking at the bigger picture.

You can't just throw people into a situation like pair programming, dream teams should be built and evolve over time.

-- Jeff Dever

I work at EXFO <http://www.exfo.com>, as a technical leader on the Architectures team. We do pair programming very often as some kind of subtle coaching. So, I've worked in pair with several people to "coach" them, and I've ended learning a lot and having a lot of fun. Pair programming helps the teamwork and contributes to develop a strong synergy amongst developers. In consequence, productivity is boosted. And well... thanks a lot too for giving a "somewhat official" character to so many pragmatic practices: that's also a way to fight against the bureaucratic tendencies so common in big organizations. �- Ionel Munoz

While working in Switzerland, I commonly paired with people from three or four national cultures in a day. I was often uncomfortable until I became aware of the differences in personal space and physical contact that tended to go with culture. DanesSitAtLeastTwoFeetAway? (further than I am comfortable with). Scooting closer just drives them away. Italians sit closer than I am comfortable with (if I'm not aware of it) and touch often. Once I realized what was going on, I took a moment before I sat down to draw what I expected my partners personal space to be. After that I could pair much more comfortably. -- KentBeck

When introducing programmers to PairProgramming I'm very concerned about the setting. Disregarding their PersonalSpace, I insist that they start like this: sitting upright and parallel (instead of one sitting behind or skewed), shoulders in one line almost touching, monitor centered. Start with some trial moves of the keyboard. (I do this in the sense of ShuHaRi.) -- DierkKoenig

I am a third year undergraduate computer science student, and am just getting into serious object-oriented Java code in class, S390 BAL, PERL, and on some personal projects. I had more trouble in my introductory classes simply because I was a LoneRanger. Now, I work with a team of fellow students of varying skill levels on most of these projects together. I have less difficulty with OOP concepts, but tend to make syntax errors. So, I usually devote time to keeping the BigPicture in mind, finding ways to Refactor, etc. and we ProgramInPairs? on the code, usually with me typing to comments already written, and a fellow team member calling out actual code. PairProgramming really made CS enjoyable, and much easier, and I think we have all learned more as a result. Our grades (on exams, not just assignments) I think reflect that.

-- Austin Lorenzen CulturalChallengesOfPairProgramming

I've been experimenting with this at my current position. I am fortunate to be working next to a programmer that I mesh with very well, and who is crazy enough to let me talk him into trying some XP practices. We've been spending about 50% of our time pair programming, and the results have been very encouraging. My observations are:

It's somewhat harder work, because my partner requires me to justify everything that is unclear or disagreeable.
It doesn't seem to me like we're being more productive at the time - time does not go faster when you are always communicating, especially during vigorous arguments. But when we get done, we find that we've written a great deal of code that we both understand and like.
Sometimes we both want to drive. We haven't had to flip quarters yet to decide, so I guess it hasn't been a problem.
The shotgun partner can handle interruptions while the driver keeps coding. This is a big productivity gain.
When I win an argument, it feels merely ok. When I lose one because my idea was not the best, it feels great, because I know my partner just saved us from writing the worser code.
Our team lead noticed us working as a pair, and officially paired us for the next project. I couldn't have hoped for better - now we have to work as a pair (shucky darn).
Sometimes we like to fork, with one going off to do a web search or write a quick test program, but we usually join before too long. Neither of us wants to let the other one get away with any unchallenged code!

-- WayneConrad

Update: No longer pairing much at work. My partner moved to a different group, and while this group is incorporating some partnering and finding it enjoyable and productive, it has not chosen to make it a full-time practice. I'm not sure why, but without express permission from management it may seem like too big a risk to most developers. -- WayneConrad

I had thought I never did any Pair Programming, but then I remember one instance, where a large body of code required emergency rewrites. Our group was split into pairs and basically each pair worked together about 12 hours a day to get the work done. It was exhausting but very effective. Of course we were all full of adrenaline. Perhaps the PointyHairedBoss realized intuitively that this was a way to get high quality work quickly. If so, it was because he too was under incredible pressure, and had to abandon GamesPeoplePlay. -- RobertField

JonHylands and I pair programmed TopLink version 2.0. We had a blast. For the record, we locked ourselves in a room with no phone and no web access for about 4 weeks (until it was finished). Also for the record, I've never been able to program as well with anybody else, either before or since. I think success is overwhelmingly influenced by how strong a mental connection you can make with the person you're working with. -- AnthonyLander

I whole-heartedly concur. I've had the pleasure to experience such a successful partnership when my co-programmer and I have been on the same wavelength and communicating very well. However, I've also experienced the other end of the spectrum where my co-programmer has been a silent partner. PairProgramming doesn't work for me unless both programmers are making the effort to communicate. -- KeithPitty

We've been PairProgramming on our current project for a couple of months now and the experience has been mixed. First, I'm an experienced developer working with three greenhorns, so when I pair with somebody there is a real imbalance. Pairing the inexperienced people with one another is of course preferred, but unfortunately, one person doesn't really work well with others due to personality problems and another works from home half the week. As a result, only about 50% of the programming time is in pairs.

However, it's still better for me to pair with an inexperienced person than programming solo because when pairing I need to make things clear to the partner, so we end up with much clearer, simpler code than if I went hogwild (as I am prone to do). And, when possible logistically and personality-wise, I think the other programmers do better work when paired. So I think there is a net benefit even in this rather limited application. -- JamesWilson

Not quite PairProgramming, but I had to bring someone up to speed on code that was being transferred to a different department. I fixed about 10 bugs, he looked over my shoulder. By the end of the week, he was making suggestions and was spotting errors in my typing and even in logic. This was in C, and my "partner" had almost no experience with C except a course. I was amazed how much we got done and how much he learned.

My bad experience with PairProgramming: I lost all the fun that I used to have - programming - on my own. -- DierkKoenig

Why did this happen?

I don't know (thanks, you care). Just the last days I recognized that when I had the time to enhance my pet project a little, I anticipated how it will be doing this on my own. Then I remembered how much fun the last pairing session was. I suddenly lost all the drive for the solitaire session. Wouldn't you like to come over?

My first experience with PairProgramming unfortunately ruined me for life. I was a happy, contented C++ programmer, blissful in my ignorance. Then I was dragged kicking and screaming into a SmalltalkApprenticeProgram. I was forced to PairProgram with CharleneBenson by SamAdams. Then BillFelton split us up and would PairProgram with each of us. It was horrible. I found out I really didn't understand objects as well as I had thought. I found out that debuggers are your friend, not your enemy. I started writing tests before I wrote code. I started EXPECTING the code to work by the time you had finished typing it in because your partner wouldn't let you leave in stupid stuff. By the end, I found I would never fit into the corporate culture of CowboyCoding again... :) Oh yeah, and did I mention that we managed to develop a window-builder tool, a prototype touch-screen cash-register system and a framework for building retail applications during those six weeks? Weird. I wonder where that all came from... -- KyleBrown

My senior Computer Science project ended up taking about two weeks of serious Pair Programming coding. The COCOMO model demanded that it would take years for two programmers to accomplish what had been produced. -- Sam

When I was at General Electric's R&D center we didn't know about Pair Programming. But Betsy Dixon and I had "play dates" in the lab putting together the software running our prototype digital x-ray machine.We were regularly in flow and were able to track down woogy bugs in great gobs of legacy code far quicker than anyone expected us to.-- DaveVanBuren

I think that Pair Programming is not for everybody. Very often it happens that stronger programmer, being able to do a great work himself, gets resentful of weaker co-programmers. And thus either he has to do all the "team" work himself of just get an unfair mark or whatever. I had that dreadful experience of pair programming. And was unable to do all the work, that several people were supposed to do, myself.

As a Java instructor, I often encourage students to work together in pairs for the exercises, and experience suggests that they learn more out of working in pairs than when they are on their own; they certainly talk less when working on their own.

One memorable course had an odd number of students, including the PointyHairedBoss (also a developer). He opted to go it on his own whilst the rest of his team pair programmed.

He was the only one who didn't finish the exercises in the week. -- Alex Blewitt..

See: PairProgrammingPingPongPattern.

This week I have been teaching an EJB course to a large number (16) of students that had had varying degrees of exposure to EJBs, from only hearing about them to actually having written a few in a project setting. The mix of students with experience in the class was somewhere less than half. At the beginning of the first lab, I proposed to the students that they pair together (the students with experience working with those who had none) for the first exercise and see whether the experience was something that they liked and wanted to continue. I told them as well that if after the first exercise anyone wanted to get out of pairing and work on their own, they were free to do so. None of the students in the class had any pair programming experience. Before beginning the exercise I gave a few tips for pairing: the two people sit together at one machine with one person typing and the other watching and thinking ahead, the two should discuss what is about to be done before getting started so that not only agreement can reached about an approach to the goal but also that both will be aware of the path that will be taken to get there.

Here is what I observed: After the first exercise, everyone reported a positive experience with pairing. The first lab was a very simple one and most of the students were done with the exercise fairly quickly. I noticed nearly but not all of the pairs talking with each other about the exercise. For this exercise most of the pairs had the person who was watching stretching their neck to be able to see what the person with the keyboard was doing. I encouraged the students to move the monitors to the middle of the desks so that they were watching a monitor that was in between them.

The second exercise was more involved than the first. All of the pairs reformed for this one and they switched who was typing and who was watching. Again I noticed communication going on between the pairs. In this exercise, some of the pairs finished early and some weren't able to finish until the very end of the time allotment, though all eventually did finish.

In the third exercise (which happened at the start of the second day), some of the students (two of the pairs) broke out of their pairs, but most remained working together. Again a few of the pairs finished early and some didn't finish until the end. Of the pairs that broke up, the person from the pair that had experience with EJBs was finished before or at the end of the time allotment, while the person without experience wasn't able to finish until the very end of the time allotment.

By the end of the exercises, only one more pair had broken up.

All of the pairs that stayed together finished the exercises early or by the end of the time allotment. Of the pairs that had broken up, the students who did not have EJB experience of any kind tended to be the stragglers, either not finishing until the end of the time or not being able to complete the exercises until they had free time in the breaks. It was with these students that most of my time during the exercises was spent. One advantage that the students pairing had for me as an instructor was that there were half as many exercises needing my attention as would have been the case if everyone was working on their own. The pairing didn't come at the cost of leaving some students behind (not giving them a change to learn through experience) because the pairs were required to switch responsibilities on each exercise. One thing that I didn't try but that I probably should have done was changing the pairs after every second exercise (there are 6 in the course). The discourse that went on between the students gave them a chance to reach agreement on how to solve the problems in the course as well as share knowledge about EJBs and the rules they must follow. I think it is unlikely that each student was able to absorb all of the points made during the lectures, but having the pairs working problems out together increased the likelihood that cumulatively they remembered enough of the points to be able to complete the exercises together.

Overall, I was encouraged by the what I observed pairing students together for lab exercises and I expect to propose pairing to students in future classes that I teach. I don't know if any of the other instructors have tried this in a class setting yet, but I want to share my experiences in case no one has.

Mario Aquino (mario@ociweb.com) Object Computing, Inc. http://www.ociweb.com

CategoryPairProgramming