Fog Creek Software
Discussion Board

Pair Programming Revisited

The previous discussion  (2001-early 2003) was excellent. It presented reactions from the trenches as well as the top. My reading was that the experience was positive for most people, and virtually everyone found the designs were better and there were fewer bugs.

BUT THAT WAS EONS AGO!  "Development" is constantly evolving and reactions both change and mature. Any new reactions?

Joel has commented that his biggest problem in his programming productivity is inertia, just getting started, on some days. Intuitively it would seem PP would be quite useful in overcoming inertia. In other readings (I've been researching this quite a bit in the last two days) it seems common PP observations include stronger focus and fewer breaks, which would seem to support the idea PP might help with inertia problems.

I WAS a coding developer (and boss, trainer, etc.) a thousand years ago (1966-1980). The desk behind glass at the Boston Computer Museum could be mine, even down to the Autocoder coding sheets (for IBM 1460 mainframes that could have up to 16,000 bytes of memory).

Now I am starting a company to create vertical software for big auto repair shops. I am researching the best tools -
...J2EE or .NET?
...MySQL or PostgreSQL or other?

I am researching the best management -
...Steve McConnell's write the user's manual before coding begins OR XP?
...Pair programming or prima donnas?
...Open-book accounting?

PS - Joel, you really are a treasure! Your web site is the best source I have found for pragmatic, detailed, un-varnished suggestions and advice. Bravo! Thank you! 

Doug Hobkirk
Sunday, March 14, 2004

My opinion of pair programming hasn't changed much:

1) It takes more resources than the usual code-test-fix cycle, even if it does reduce initial bugs.
2) It's worth it for emergency code fixes when you simply have to change code running on a live web server at 5:30 PM on a Friday afternoon
3) It does overcome some inertia and force people to code
4) Like marriage, it's only possible if both programmers are compatible in a very deep way; if there is even the slightest social reason two people don't want to pair program together you simply cannot make it work, and this is far more common that it seems. Being able to work together on the same team is very, very different than working shoulder-by-shoulder in vulcan mind meld for hours every day.

Joel Spolsky
Fog Creek Software
Monday, March 15, 2004

When reading discussions about pair programming you have to be careful about coming to the conclusion that "the experience was positive for most people".  A couple of years ago I had a brief discussion about XP with a coworker.  We did not use XP there, but he was quite enthusiastic about the idea of doing pair programming.  After a little discussion with him I realized that for him pair programming just meant having someone down the hall working on the same project so you could go talk over problems once in a while.

The XP web sites that I have read are quite clear that pair programming means two people sitting at the same terminal working on the same source code at the same time.  Some previous discussions here at JoS showed that a lot of people liked their experiences with pair programming, but had quite varied ideas as to what constituted pair programming.

Monday, March 15, 2004

My opinion (and my experience) is that two good programmers working together on a problem can produce more work if they divide the tasks, work out the interfaces, and then do each one his own stuff. Writing code together in the pair programming mode is just unnecessary duplication of the effort. It shouldn't really take more than one person to write the for loops! :)

Basically, what I want to say is that in case when you have competent (i.e. able to produce quality code) developers, "pair design" is good, but pair programming is not so good!

Monday, March 15, 2004

Have you actually tried Pair Programming in earnest, or are you just guessing?

Monday, March 15, 2004

Frankly, I can't work if someone is looking over my shoulder. It truly bothers me. Perhaps I'm just a misanthropic sociopath...

Monday, March 15, 2004

Biggest problem with Pair Programming: you have to spend alot more time each week bathing.

Monday, March 15, 2004

Part of the reason I became a programmer was because I'm an introvert and anti-social.

Now you want me to spend all of my work hours sharing my miniscule cube with someone else?


Monday, March 15, 2004

>>Part of the reason I became a programmer was because I'm an introvert and anti-social.

Now you want me to spend all of my work hours sharing my miniscule cube with someone else?

What little social ability I posessed, and the team-work hammered into me at University, has been obliterated by years of working as the only programmer in various small shops.

I'd have to be immersed in teamwork again before I'd let anyone look at my screen, let alone sit at my desk for days on end :)

[I suppose the upside of pair programming is that collusion aside, it would seriously crimp forum posting on company time.]

Mediocre ASP Monkey
Monday, March 15, 2004

Pair programming runs on the theory you want someone to review the code, so why not skip write to having them review it while you type it (eXtreme reviewing).

It also helps fill in the lack of planning inherent in XP, as 2 brains are more likely to converge on a good idea than 1 brain.

This is probably true if your exploring an idea (such as prototyping), or creating a one-off short-term implementation. 

Otherwise, my preference is to have the folks pair up when figuring out what to do up front, then divide up the tasks and make sure the design and code gets reviewed in the end.  Makes for a more flexible environment, and if you make them write down their design, then the next two guys to maintain the software have some clue why you wrote what you did.

Chris Kessel
Monday, March 15, 2004

My experience with pair programming, gathered over the last two years is that it works well for some things and not so well for others, even when your pair-mate is your best friend.  We have done quite well when laying down some exploratory code, but we've both agreed that pairing while doing finely detailed work is annoying and distracting.  Having someone talking to me while I'm trying to do certain kinds of work that require a lot of concentration, for example, is not something I am interested in pairing on anymore.

Monday, March 15, 2004

"It also helps fill in the lack of planning inherent in XP, as 2 brains are more likely to converge on a good idea than 1 brain."

Not necessarily true. I've seen plenty of cases where adding heads didn't make better design/code.

My 2 cents on pair programming: I've never done coding in a pair, but find the idea rather uncomfortable. Working that closely with someone all day long just wouldn't work for me. Also, doesn't pair programming imply that the pair would have to be at work during the same hours of the day ? I often work odd hours, sometimes from home. I've worked on one project where my partner used to come to work around 6 pm, work through the night, leave early in the morning. I'd get in about 9 and leave at 6.

I find pair debugging much easier to deal with - in fact I enjoy it. Somehow the process of debugging in a pair seems more productive (and more fun) than coding. Does anyone else feel the same way ?

Another reason pair programming wouldn't work for me is that I tend to work in short bursts, with breaks for all kinds of stuff - reading my mail, browsing a couple of web pages, and so on. sometimes I read a book for a few pages. Every half-hour or so I get up and walk up and down for a minute or two. I have a feeling that kind of thing would be quite annoying to many people if they were in the same cubicle as me trying to get work done.

Arnab Bhaduri
Monday, March 15, 2004

"...Steve McConnell's write the user's manual before coding begins "

Does McConnell really advocate this?

I've normally got a lot of respect for his views, but the above makes very little sense to me.  Software development occurs best in interations where you build-show customer-get feedback-repeat.

Mr. Analogy  (formerly The real Entrepreneur)
Monday, March 15, 2004

"I find pair debugging much easier to deal with - in fact I enjoy it."

Not me.  When I debug, I usually form a hypothesis of what is happening, based on the symptoms.  I then make tests to try to invalidate my hypothesis, in which case I revise my hypothesis based on the new information and repeat.  This usually means I have to have a lot of information in the forefront of my consciousness while I do this (i.e. all the symptoms, what deductions I have made, etc).  The last thing I need is someone looking over my shoulder yelling, "Hey!  Put a printf in there!!  Comment out that line!!!" and so on.

I do, however, find it challenging to "compete" when tracking down a bug.  Let them form their own hypotheses and test them and see who gets the little bugger first ;)

Monday, March 15, 2004

I don't know if McConnel advocates it, but I do the write-the-manual-first method pretty often. Customer feedback is part of that process. The customer reads teh manual, which includes mock ups of the screens.

Dennis Atkins
Tuesday, March 16, 2004

The closest I've been to "pair programming" was working on a module with a guy two cubicles down.  He stayed in his cubicle, I stayed in mine, and we'd work on different pieces and them merge them together every day.  Also, if I found a mistake in something he did, I'd correct it and vice versa.

It worked well in that manner.  However, I would find sharing a cubicle and keyboard for hours a day to be extremely annoying.  Unless I was sharing it with a hot chick - in which case I'd enjoy it but I wouldn't get any work done!

T. Norman
Tuesday, March 16, 2004

When it comes to programming I work in a very non-linear fashion. Not only do I share another of the respondents for wandering off and doing non-related things for a while (like now, it helps me think about the problem, honestly), but even when I have the code in front of me, I tend to jump around a bit. To someone of a more linear mentaility it would drive them insane, and conversely someone of a more conventional mentality would make me bored or worse uninterested which would remove any advantages the pair-programming offers.

I am about to start a new job in a few weeks and they are looking at pair-programming so I may be able to report from experience soon. The only problem is that currently I only have one shower a year, whether I need it or not, I suppose that'll have to change.

Tuesday, March 16, 2004

I've found pair programming with smart developers who have reasonable social skills is a tremendous timesaver.  We were able to work very quickly and transfer a lot of knowledge easily.  (In one case I was introducing someone to Cocoa and the system we were developing for at the same time we were writing code.)

And we saved a whole mess of time in debugging - we had almost no bugs, between our unit testing and pair programming.  We caught potential bugs as we were typing, and we were able to write more and better unit tests by putting two brains on the problem.

Chris Hanson
Tuesday, March 16, 2004

I don't like people looking over my shoulder or telling me what to type either.  Luckily, that's not pair programming.  Pairing is the essence of teamwork.  The driver should focus on the little stuff, while the other person thinks big picture -- not obsessing on typos and whether a variable has the perfect name.  It takes a willingness to adapt, patience, practice, similar mindsets and abilities.  Managers:  pairing is not for everyone.  Some people work best alone, don’t force it on people.  I *highly* agree with Chris Hanson’s comments above, and I'd like to add job satisfaction as another advantage.  The times I've paired with a compatible developer have been the most fulfilling of my career.  Disclosure -- I was skeptical of pairing until I tried it.  I've paired on multiple XP projects, but I'm currently coding alone, and can't wait to pair again...

Tim Rapp
Tuesday, March 16, 2004

When in college a friend and myself worked on a pdp-11 simulator. We finished this student project over a couple of nights doing everything from research (we didn't know the pdp-11 assembly language), design, coding and testing while sitting together and bouncing off thoughts with each other. We used a single terminal.

We were doing pair programming without realising it.

What I liked most (and remember the best about what we did specially in comparison to what happens in my work environment today) is that we quickly focused on the core of what the project was all about, getting that up and working fast and later adding the fluff that made the project look good to a reviewer.

Now however in my work environment, I find pair programming difficult and unrewarding mostly due to personality issues (either mine or the other persons). It's easier, like someone said in this forum, to do pair design and then work on your parts separately coming back together for a review or debugging sessions. At work I find that when I pair program, I only work with half my brain! Also we tend to spend too much time on unrelated matters.

Tuesday, March 16, 2004

I seem to be the resident pair debugger. When people are truly stuck they come over and ask me to have a look. This happens even for tech I know nothing about.
I basically step them through the problem in a logical way, putting up a hypotesis and then devising a test for checking the hypothesis, rinse and repeat. Works every time.
People know that that is the way to go about it, but they just seem reluctant to do it without someone riding shotgun.

Just me (Sir to you)
Tuesday, March 16, 2004

"...Steve McConnell's write the user's manual before coding begins "

He advocagtes it explicitly in his "Software Project Survival Guide" (1997). I didn't find sufficient reasons to buy "Code Complete" or "Rapid Development" so maybe he has changed this specific suggestion.

There are two reasons:

1) Limit "feature creep" from killing the project deadline.
2) Make the next stage (coding) easier to sell

At least that was the way I read it...

Doug Hobkirk
Tuesday, March 16, 2004

We use a modified pair programming approach. Pair programming is always optional. Programmers are assigned their own tasks, but can choose to work together if they feel like doing that. Several times a day, I hear someone say to someone else, "Hey! You wanns pair program for a couple hours?" Sometimes the answer is "yeh!" and sometimes it's "not now!"

One thing that makes it work is that we have offices for our programmers, so pair programming can take place behind closed doors and not disturb anyone else. Another thing that makes it work is that it is OPTIONAL.

Not all pair programming pairs work, and we have had to gently discourage certain pairings. I'm always happy to see certain pairs sitting down together -- we're gonna get something good from them.

Names are for wimps
Wednesday, March 17, 2004

I've been going through Code Coimplete II and don't see the suggestion write the user manual first.

It is however good shorthand for what both McConnll and Cooper recommend as design decisions. In "The Lunatics are running the asylum" Cooper outlines his consultancies policy, which is that the team should draw up profiles of up to three or four imaginary users of the apps, right down to imagining hobbies and children for them and giving them a photograph and sticking the profile all over the developers' cubicles, BEFORE ONE SINGLE LINE OF CODE IS WRITTEN.

Mcconnel talking about requirements insists that they should be described completely in user speak. "user needs to add another worker to a specific office" is a requirement. "Table with look up fields for office number and worker" is a specification and thus an implementation detail not sufficiently abstract to be a requirement.

More importantly when talking in Chapter 6 about ADTs (Abstract Data Types) he insists that they should be as close to the real world model as possible. Thus an abstact data type "Office" will have members such as "Office.addworker" "Office.deleteworker" "Office.addtelephone". Any mention of arrays, stacks, pointers or tables (except wooden or metal ones with four legs) is an implementation detail and not abstract enough for an ADT. That is to say that your highest level of abstraction should be the same as the users lowest levels of detail.

Stephen Jones
Thursday, March 18, 2004

Just reading "Rapid Development" right now and he discusses writing the user's manual before coding as a technique to do minimal requirements specifications. ie write the user's manuals instead of doing a formal requirements document.

Doug Hobkirk mentions some of the benefits. Another benefit is that in whatever approach you choose, you have to write the user's manual at the end so by doing it instead of doing requirements, you kill two birds with one stone.

Note that he also mentions that this approach might not apply to all types of projects.

Tuesday, March 23, 2004

I first came across paired programming in the early 80s. In general I find it works really well when I want to do some rapid prototyping, or am on a small project that doesnt have much overhead.  You can just brainstorm and code.

However, after doing a few very very large software projects I discovered that it wasnt so very usefull.  Maybe now I may just call someone over for 10 mins to work thru the odd idea, or we might go to a whiteboard for a bit and bandy some ideas around.

It really doesnt apply itself to a well defined software process.

Andy Watson
Thursday, April 8, 2004

I spent an hour and a half today introducing XP (pairing, TDD, and as much more as I dared) and its benefits to my team of five developers. Met with mild skepticism and whatever-you-say-boss faint smiles and nods. So much for an enthusiastic welcome ... I may not know enough about it to have sold it properly, but now I'm wondering how much I should impose -- and then deal with enforcing. Seems rather counter to the philosophy. Sigh.

Steve at Japanese-company-that-ends-in-oshiba
Wednesday, May 19, 2004

*  Recent Topics

*  Fog Creek Home