Pair Programming Pair Programming
I see ... so if you reduce the rate of progress, and if you measure the number of "bugs", they seem to be less !! hmmm I guess at slower speed, we get somewhere "clean".
How do we know that this is an improvement over a lone programmer spending 15% more time to get the code right the first time?
If you look more carefully at the numbers, there is actually a 50% reduction in the number of bugs. (The passed tests went from 70% with solo programming to 85% with pair programming. This is 30% failed tests compared to 15% failed tests, or 1/2 the number of failed tests). It's also conjectured, but not proven, that this reduction in bugs will later gain you back the 15% in "lost" productivity. (warning about comparing percents: you need a 100% gain in your stock portfolio to break even after a 50% loss)
Where are the other studies to back this up? The only one quoted by the Economist (or indeed anyone) is LaurieWilliams' now famous "15%" study.
(And note: From a scientific perspective, the "15% more time" figure is not statistically significant. That is, given the small sample size, there could be no additional cost. Or it could be over 15%. You just don't know.)
It is also a pattern; see PairProgrammingPattern.
Before contributing to this page, please consider if your comments might be better suited to one of the following:
WardAndKent lead a BOF at OOPSLA'97 that included looking for patterns in the code and in the recorded dialog between programmers as they work together. These are the patterns they found ...
Just saw that I had marked (and forgotten) a section in "Constantine on Peopleware" in which he described a visit to Plauger's group, where they were programming in pairs, with the same descriptions as WardAndKent use. Constantine called it "Dynamic Duo" development.
That makes, so far, 3 or 4 separate inventions of this technique that I have encountered, each finding it advantageous. -- AlistairCockburn
See also DijkstraPairProgramming
What programming, especially in pairs, feels like, at least in one case:
http://www.salonmagazine.com/21st/feature/1997/10/cov_09ullman.html
Yuck. I read the article with growing horror. Just another example of pseudo-heroic sloppy cowboy debugging. PairProgramming appears to give back more than it takes - the opposite of what the article illustrates. Having not done PairProgramming (yet!) I can't speak from experience, but I know someone could... -- RodneyRyan?
It's a weird book (CloseToTheMachine). She has a very strange, dark outlook. But much of what she writes expresses a truth that many have lived. -- RonJeffries
I agree. However, I'm asking if people who have practiced PairProgramming view the article as a good example of PairProgramming. Is it a situation that indicates movement in the most effective direction ? -- RodneyRyan?
Ullman got the mind-meld part right. And she understood that pairs didn't have to be equals to be effective. But she couldn't keep the meld up through completion with the first developer and couldn't even start to meld with the second. Amateurs. -- WardCunningham
If you took out all the macho midnight brainburn stuff, the experience isn't atypical. Done calmly and peacefully, however, it's more a gentle flow than this orgasmochistic explosion of sensation.
If both of you have a beer before doing PairProgramming in my experience sometimes seems to help the process! -- DanielPoon
Although we don't practice Pair Programming, we've been using it then trying to find bugs. In this case it seems to be a GoodThing.
However, our team is too small to use it all the time.
-- GeraldoXexeo
Pairing also gets rid of any problems resulting from mediocre programmers writing poor code and documentation, as mentioned above. It seems the dissenting opinions keep forgetting that arguing against one particular aspect of XP won't work because it is the other aspects that balance out most of the possible negative side effects when taken individually.
FYI, I'm speaking from the point of personal experience in that I didn't think PairProgramming was going to help me improve my code and make me faster. So I went in quite skeptical. As you can tell, my views have changed just a bit. -- TomKubit
So what, PairProgramming is a BandAid on bad hiring decisions?
How about, I dunno, ReplaceMediocreProgrammers?. Might be just crazy enough to work.
Arguing against particular negative aspects of XP is good for discerning which parts of XP might hold some value for you, when you're reluctant to just swallow the XpReligion? whole. Take what's useful. Leave the rest.
For some people, it is. For some people, it's perfectly natural.
Granted. I meant that, in testimonials about attempts to implement XP, I read of more resistance to PairProgramming than any other practice. I think.
UnitTests are my reviewer. If the code works according to the UnitTests then why is continuous review necessary?
Who wrote those UnitTests? If it was you, how can you be sure that the UnitTests cover all bases? A continuous human reviewer can catch issues like that, and can also make the development process much faster by suggesting improvements that cut down on development time or potential bug count. -- BrentNewhall
There is also the argument that adding a reviewer reduces quality. Each person tends to rely on the other to find the problems, and neither becomes responsible for discovering problems.
For one, in PairProgramming, you're operating according to a different MentalStateCalledFlow than you are when SoloProgramming. Note that generally PairProgrammingIsDoneByPeers, which goes against the example of programming with someone who doesn't have the same skill. There should be fewer explanations and more collaboration. Also note that PairProgramming is somewhat CounterIntuitive. It works, even though it doesn't necessarily seem like it would work. -- BrentNewhall
I would also like to comment on the above. If you were programming together with somebody else and this was at the university shouldn't you have tried to find another lab partner then? It feels like you just destroyed your friends possibilities to actually learn anything. He doesn't want to ask questions and you just do all the difficult things that he should learn. What's the point with having a partner that isn't as good as you? And about spending time on tests. For really small projects I can agree, but on any medium to large university projects (that means mostly everything after the first year or so) you will actually gain time if you write tests. I have spent many long nights looking for bugs that would have been found immediately if I had written tests in advance. -- DanielLuna?
My answer to this would be to have the less experienced developer drive. The observer should talk him/her through it, incorporating ideas from both. A craving for one's own gratifying MentalStateCalledFlow has to take a back seat to maintaining a common understanding and a productive dialog. It may take a while before the more experienced developer can drive in this situation. If it takes too long, either the more experienced developer isn't doing it right, or the less experienced person is in over their heads. -- ChrisDailey?
I read through all of the above. I feel there are important points missing from this discussion. (Arrogant Bastard that I am).
My Experience with Pair Programming can be summed up as follows. One group I worked with I was the J2EE guru (I was hired for my knowledge of J2EE). We adopted pair programming. I found that not only was I teaching and mentoring the novice J2EE developers, but after a few weeks (even more so after a few months) I was learning a lot from them. J2EE is big (EJB, Custom Tags, JSP, JMS and more). The knowledge of the team increased exponentially. This could not have been accomplished without Pair programming. I have never increased my skill level so much in such a short amount of time.
The amount of experience and knowledge gained by pair programming with ten people for a year is equivalent to working for five years in a shop that does not use pair programming. (This includes domain knowledge transfer.)
Also we started building a reusable framework. I don't think we could have made so much progress without pair programming. Code cannot be reusable if no one knows how to use it. Pair programming grows in value the longer you do it. Not reinventing the wheel means less code in the code base to do the equivalent functionality. Less code is less code to maintain (and learn). The benefit of pair programming is not linear. It grows the more you use it.
What do you do with people who will not try pair programming? Fire them. Just kidding (sort of). I found through experience that the people who have the hardest time with pair programming usually become the biggest pair programming advocates. Here is the recipe. Set a metric that every team member do at least 10% pair programming (4 hours a week in the U.S. .... 3.2 hours in France). Slowly raise this to 50%. I have not had one person who has tried pair programming not prefer it. Believe the 96% people prefer it figure cited earlier. (Our team could only achieve 80% pair programming or so per week as in 32 hours a week. The rest of the time spent in meeting with customer (5%), planning(5%), designing in groups(5%) and working alone (5%).)
Here is a suggestion that is not going to go well with some. A tree grows best if you trim some branches from time to time. Not everyone on the team is going to work out. This gets amplified with pair programming. Unlike environments that do not use pair programming, environments that use pair programming are very sensitive to stinkers and slow pokes. Notice I am not saying novices. There are fast smart novices, and there are hard to work with experienced folk. We have had experience with getting rid of a few people and our project velocity increasing (the people were causing more harm than good). With pair programming, it is easier to identify these issues because everyone works with everyone else (switch partners often facilitates knowledge transfer), and the team knows who is not pulling their weight. In fact when we made adjustments to the team, no one complained.
Pair programming works best with talented, professional folks. Unless you prefer working with talentless, unprofessional folks, pair programming will work like a charm.
Huh? PairPromiscuously.
The most successful use of PairProgramming that I have personally experienced is on my current contract. We are dealing with a legacy database that is "unnormalized to the extreme" and cannot be changed for a variety of reasons. The programmer I am working with has little ObjectOriented experience, and is new to using an OO language, but he is a fast learner and an expert with respect to the data and domain.
He is learning OO techniques, Patterns, divide and conquer and the language issues etc while we are speeding ahead much faster than if I had to take more time to pre-learn everything about the data in the database, much of which is irrelevant to this project. We are experiencing a magnitude increase in productivity over working independently. In addition, our combined understanding of the system is leading to improvements in the design and the maintenance of this system will be greatly simplified as a result.
We got a good laugh over the "mind meld" comment and photo above, as this mirrors how we feel about this experience. I also believe that the personalities of the individuals involved can make or break the PairProgramming experience. So ... it is not for everyone, but when it works it really works well!
-- JudyGreen (Judy N. Green)
If there isn't a Pair Programmers Dating site already there should be.
Have you tried pair programming?
Yes and I wasn't thrilled with the results. But that's not my problem. It's an adoption problem. -- RandyCharlesMorin
I'd think that the grade issues would make pairing difficult in an academic course - if your partner is truly behind the curve, your desire to pass the course would be pressure to take over the development. In a work environment, there is no stigma about heavily coaching your partner, so you can make a difference in how they are. Also, IIRC PairProgramming calls for switching partners fairly often.
You could have made basic notes on ability and personality as part of the assignment marking procedure, then re-paired the students for the next assignment matching like with like. Then you get to focus more resource on helping the slow kids to learn slowly, while the fast ones go ahead with teaching themselves.
Another data point: for several years, I've assigned my freshman programming students to use pair programming, generally telling them to switch partners for each assignment (with 6-10 assignments in a semester, I figure the law of averages allows me to assign reasonable grades). Many of them are reluctant to switch, often claiming that they've found the only student in the class whose weekly schedule is compatible. A previously-unmentioned benefit of pair programming in this environment is that I have half as many assignments to grade, so I can give more and/or quicker feedback. -- SBloch
It would probably be easier to sell if it were de-mystified. We used to call it WorkingTogether. Walk into any engineering shop and you'll find people gathered around white boards and workstations, collaborating on (not reviewing) design decisions. Before screens, it was common practice to desk-check each other's coding sheets. Even after screens, programming where it mattered (ISVs and OEMs) was still collaborative for two reasons: it produces better code and it eliminates the risk of losing the only person who knows how a bunch of the code works. As a manager, I want every line of code to be clearly understood by at least two people - preferably more. This is in and of itself such an important requirement that it renders all other arguments for or against collaboration irrelevant.
[Anecdote: When I was field systems analyst at SDS, anytime a significant piece of software was ready for release a bunch of us would be brought into HQ for "familiarization". That involved the programmers walking us through every line of code and key path diagrams, so that we not only knew what every line of code did, we also got to propose lots of improvements. We all went back to our offices with copies of the source code on mag tape (like a CD but bigger and lower capacity).
Someone could have nuked HQ and SDS could still have gathered a gang from the field to continue work on the product. Oh yeah--the code was in assembler. A lot of lines.]
Pair programming seems novel because for the past decade or two we've been tucking programmers away in cubicles and allowing them to avoid WorkingTogether. Big mistake.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006