Fog Creek Software
Discussion Board




Pair Programming vs Private Offices

"So now I'm envisioning the ideal development interior plan as one where programmers have private offices but they meet in labs with their buddies to get production programming done. No email, phones, or non-programmers would be allowed in the labs."

Ron Jeffries talks quite a bit about this on xprogramming.com. 

The ideal XP team environment is what we call a "bullpen" office where the really powerful pairing machines are.  They're set up to allow two folks at one machine.  Round the edges of the bullpen are the private spaces.  The C3 (original XP) project tried no personal space and it didn't work.  They just had "cubbies" with a set of drawers, phone etc. 

The other stuff you mention (particularly the design) is actually best handled in the bullpen (most of which is lined with whiteboards).  Since design is so important, we like to do it all the time with all the team available. 

The only thing left for the private office (IMO) is the tetris.  And in an XP team we'd go home for that :-)

A.

Alan Francis
Thursday, May 02, 2002

Has anyone on this discussion site been a participant as a basic programmer on a full blown XP project?  Would you want to do it again?

I tend to think of the experience the same way I think about having a broken leg.  I'll have to admit that the only way to really know what it is like is to do it, but the description makes it sound like an experience I can do without.

mackinac
Friday, May 03, 2002

Yes, we switched to an "XP-based" process last year and we've liked it so much we're still doing it.  In short, we pair program everything then have another step to verify the work when coding for the entire release is pretty much done.

The transition was pretty painless although it did require us (managers) to be pretty hard-assed for the first 6 months ("Hey, who are you working with?").  Now everybody is pretty good at finding people to work.

The biggest problem we had to overcome was our sign-up process.  Basically for each "story" (feature or bug) we have a set of tasks ranging from just Coding/Verifying (bug fixing) to perhaps more for features.  People were being pretty rigid in their thinking that if their pair was working with someone else, they should simply do the work on their own.  Not true; you have the authority find someone ELSE to work with. 

As a manager, I do about 50% coding and since we have an even number of developers and the other managers may be on other projects, occasionally I have to buck the trend and code something myself.  Even though I'm one of the most experienced coders here and could probably "get away" without a pair, I try to get a small part of XP in there by minimally doing a design/code review when someone is free before actually committing the code.  And I always make sure the verify step is performed.

Our office layout is "typical".  Everybody (except for the VP) are in 4 rows of cubicles of just engineers (marketing and accounting make up the remaining rows in the room).  There's no fancy hardware setup, just the person's work machine with a 17" monitor.  When you pair, you decide who should "drive" and go to their cube.

Quite frankly, it's all about the attitude and almost nothing to do with the office.

Chris Blaise
Friday, May 03, 2002

>>>"Yes, we switched to an "XP-based" process last year and we've liked it so much we're still doing it."<<<

OK, good to hear a positive report.

>>>"...The transition was pretty painless although it did require us (managers) to be pretty hard-assed for the first 6 months"<<<

I was pretty specific about asking for opinions from the programmers.  (Not that a manager shouldn't comment).  I expected managers to be more favorable.


>>>"occasionally I have to buck the trend and code something myself. Even though I'm one of the most experienced coders here and could probably "get away" without a pair,"<<<

Interesting.  Being the manager you can bypass rules that you impose on the workers.  And explain about "get[ting] away" without a pair.  What does experience have to do with it?  I'm not expert on XP, but didn't think the pair programming process was there to make up for inexperience.


>>>"And I always make sure the verify step is performed."<<<

Some parts of XP, such as unit testing, aren't unique to XP, but common practice.  Well, OK, it should be common practice.


>>>"Quite frankly, it's all about the attitude and almost nothing to do with the office."<<<

What was the previous attitude?

I really did not ask my question well.  Here is another attempt at it:  How does the experience of working on an XP based project compare to a well done project of the more traditional processes, that is, using the processes out of McConnell's "Rapid Development" or most software engineering books in a Peopleware compliant environment?  I expect many, if not most, development environment are so far into the Dilbert zone that any change is bound to be an improvement.

mackinac
Friday, May 03, 2002

Well, I somewhat play the manager roles, but am primarily a programmer (Hence the job title of lead programmer).  I am currently doing a pseudo XP setup, and would go complete XP if I could get the higher up support.

One thing I have noticed is that when I pair program with any of my team, they have a real tendency to sit back and let me take over.  I'll admit I am quite into what I do, but it limits the amount of productiveness.  However, when they pair program with each other ,the results are better.

I can't get any of the business owners to sign off on the acceptance testing idea.  Thus the lunchpin of XP (validation centric) is missing.

Probably the point where we've been most successful is in the unit testing arena.  As our project matures, we can continue to refactor becasue we have a decent set of unit tests.

Adam
Friday, May 03, 2002

>>>"when I pair program with any of my team, they have a real tendency to sit back and let me take over."<<<

This is the sort of thing I'd be concerned about.  How difficult is it to pair people up so they are at least twice as productive as an individual programmer.

>>>"I can't get any of the business owners to sign off on the acceptance testing idea. Thus the lunchpin of XP (validation centric) is missing."<<<

I took a look at the description of acceptance testing on the xprogramming web site and don't see anything special about the XP approach to it.  It is just standard software development practice.  Which makes it even stranger that your management won't accept it.

mackinac
Friday, May 03, 2002

Are we seeing the effect of a change in improving productivity? I do not remember the study, I think it was quoted in PeopleWare. They turn up the lights, more productivity for awhile, then back to normal. They turn down the lights, same thing. It is the change that causes the effect, not what was changed.
Has anyone done many XP projects? Once people are used to it, do they fall back to old, less productive habits?
I realize that is a very difficult question.

Doug Withau
Friday, May 03, 2002

_Peopleware_, pg 119

"In the spring of 1932, efficiency experts ran a series of tests at the Hawthorne Western Electric Company to determine the effects of various environmental parameters on productivity.  They tried raising the light level, and they noted that productivity went up.  Then they tried lowering the light level, and the noted that productivity went up higher still.  They speculated that turning the lights off entirely might send productivity through the roof.  What seemed to be happening was that the change itself wasn't as important as the act of changing.  People were charmed by differentness, they liked the attention, they were intrigued by the novelty.  This has come to be called the Hawthorne Effect.  Loosely stated, it says that people perform better when they're trying something new."

Alyosha`
Friday, May 03, 2002

>>>One thing I have noticed is that when I pair program with any of my team, they have a real tendency to sit back and let me take over.<<<

Have you tried letting them drive? Are you impatient if they do?

Do you have a full time customer? What do you do for planning? Continuous integration?

Daniel Berlinger
Friday, May 03, 2002

I hope that all my competitors use pair-programming. Preferably on DVORAK keyboards! >:)

b
Saturday, May 04, 2002

From Martin Fowler:

"In fact, one of the key precepts of the Agile Manifesto  is that individuals' interactions are more important than processes and tools. The team of people and how they work together is a bigger factor in your project's success than the choice of the process you follow or the tools that you use."

This is sort of the elastic clause built into LWP (light weight process), of which XP is a subset/implementation.  Take what you need, if it works, great. If not, modify it, toss it, etc.  The fact that XP self describes its implementation as peice wise and incremental should set the overall tenor for the process in general.

How do LWP/XP help, if they are not doctrine?  First they can be used as a  defense strategy against sliding into Dilbert zone.  Its written down, its credible, it holds persuasive common sense arguments.  It empowers enineers by giving them first hand knowledge of the customer, biz plan, schedule, and other front line assets.

What to beware of, IMO?  LWP/XP which is treated as doctrine.  One of the chapters in Ken Becks book mentions that programmers sign up for responsibility and they write the schedule for acquired tasks themselves.  Tasks are not assigned in a manager/employee fashion.

This should be true for methodologies also (here, I'd guess Beck would not agree).  Engineers should sign up for process.  In other words, if an engineer doesn't want to pair program, then don't make them.  (Coding style of all things should never be dictated.)  Make judgements based on quantifiable results.  If quantifiable metrics for code production are not avaiable, then deal with that first rather than setting heavy wieght policy.  If you can measure a productivity increase with pair programming, then you could use these results as encouragement for pairs to form up.

IMO, Pair Programming, and collective code ownership ignore the principle of division of labor.  Very few people can keep pace with all aspects of software engineering.  I think it is futile to maintain a team of generalists.  You also deprive people of secondary objectives: career development and professional expertise.

Anyhow...

Nat Ersoz
Saturday, May 04, 2002

"One thing I have noticed is that when I pair program with any of my team, they have a real tendency to sit back and let me take over."

Pair programming works best when the pair is of roughly equivalent ability. Otherwise, the more competent programmer spends most of his or her time dictating code to the less competent programmer, and does not get the benefit of the informed, critical feedback which is really what makes pair programming work.

I've been involved in a project that "almost" did XP - we got most of the practices working, but the whole thing fell apart because we didn't get sufficient buy-in from the customer. However, the experience with pair-programming in a bullpen environment was very positive.

The project started with everyone programming in isolated environments, until two or three of us claimed a corner of the office, moved all the furniture around, put desks against the walls, and invited anyone who wanted to to join us in "the pit". Then we started working in it, and invited others to join us. Invited, not mandated. We wanted to be sure everyone who was there, wanted to be there. Slowly but surely, the whole team ended up sitting together in a space where we could all overhear each other.

We found we worked better, because one of the problems with XP (lack of formal design documentation) is overcome by the fact that you're working in earshot of other pairs. It's like the Cocktail Party Effect, where an otherwise occupied individual can hear their own name across a room. In the bull-pen, you could hear when someone was stuck on a piece of code you understand, and offer them a helping hand if need be. You also absorb random knowledge about the code-base almost through osmosis.

Some people found this was bad for concentration. I found that sometimes when I was working on a particularly hairy problem, I'd get out of the pit and work on it alone, because I felt I had more freedom to explore when I wasn't explaining every move I made to someone else. We quickly instituted a rule that if you felt that what you were doing wasn't amenable to pairing, you could opt not to pair on it.

It's also a great way to foster a team spirit, and come up with a series of more and more ridiculous in-jokes about dinosaurs.

Charles Miller
Saturday, May 04, 2002

I have been over at the xprogramming.com and extremeprogramming.org web sites trying to figure out what makes XP different from traditional methods.  Here is what I have come up with.

Pair programming - This seems to be the most distinctive feature, the one truly unique characteristic.

Collective code ownership - Unusual, but not unique.  My current project has this, along with some of the problems you might expect.

User stories - This apparently eliminates a comprehensive requirements document.  Maybe this is the sort of thing that makes XP a light weight process.  This seems to me to be just a variation on traditional methods.

Taking things to extremes - Most everything else seems to be characteristics of traditional development, but perhaps taken to extremes.  (So, that is a good name for the process).  The differences from traditional development seem mostly quantitative rather than qualitative.

Any more stories of real life experiences out there? 

mackinac
Saturday, May 04, 2002

mackinac, this all would be obvious if you went to the bookstore and looked at the book "Extreme Programming Explained."  It's much more nuanced and even-handed than people think.
http://www.amazon.com/exec/obidos/ASIN/0201616416/qid=1020557605/sr=8-1/ref=sr_8_71_1/103-0872034-8257459

Y.H.
Saturday, May 04, 2002

>>>'mackinac, this all would be obvious if you went to the bookstore and looked at the book "Extreme Programming Explained." '<<<

I may do that, although the in queue of books to read here is quite long.  It would be nice to have some indication that it would be worth the time.  It turns out I have a PDF of "Extreme Programming Installed", so I'll try that one first.

Nevertheless, this discussion board should be able to provide comments from actual users with real life experiences that wouldn't be available in the books.  The comments so far have been quite interesting but equivocal:

- A manager who thinks it's great, but exempts himself from pair programming [imposing rules you aren't willing to follow indicates some problem with them].

- Someone, on another thread, who thinks pair programming was the best thing he learned from XP and does it a couple of hours a week [in XP it is all the time].

- Someone who does all the programming while his pair partner sits back and watches.

- Someone who "found that sometimes when I was working on a particularly hairy problem, I'd get out of the pit and work on it alone, because I felt I had more freedom to explore when I wasn't explaining every move I made to someone else."  [Does pair programming stifle creativity?  Why use it if it doesn't work on the hard problems?]

- Business owners who won't sign off on the idea of acceptance testing.

All of these problems are the sort of thing one might expect, except that last one and it's not a distinctively XP one.  Acceptance testing has been part of most projects I have worked on since long before I heard of XP.  I wonder what kind of environment doesn't use them.

mackinac
Saturday, May 04, 2002

I am leafing through the purple book, the one you have a PDF of.  It has the mechanics with no context.  Same with extremeprogramming.org. 

I am insistent because the white book ("XP Explained") is the one that tells you, "That's what this book is about -- deciding when to use XP and when not to use XP." 

More Wisdom?  In ch.19, it explains the way to adopt XP.  Just take your worst problem, solve it the XP way, and repeat.  "If you don't have a problem, you won't even consider solving it the XP way."  XP doesn't have to be one-size-fits-all.

I will say that if you haven't read the white book, you likely don't understand the point of XP.  I don't mean that to put down anyone.  I just mean that you'll waste a lot of time on the forums without the right context.  Anyway, Ch. 5 and the two-page Ch. 19 are all you need to read.

Y.H.
Sunday, May 05, 2002

> How difficult is it to pair people up so they are at least
> twice as productive as an individual programmer.

"Take a bite out of debugging.  Decrease time it later takes to explain code to others.  Reduces schedule damage if one coder killed by secretary's Spouse."

These proclaimed benefits take a long view of software dev, and pair programming may only fully pay off during software maintenance.  So if you can't cut features but need to capture the market yesterday, maybe you must make the decision to use solo programming.  (xp explained, p. 229)

Sammy
Sunday, May 05, 2002

Mackinac,

When you say:

- A manager who thinks it's great, but exempts himself from pair programming [imposing rules you aren't willing to follow indicates some problem with them].

You're not reading what I wrote. 

I said that where we use XP that we "occasionally" break the pair programming rule if there is nobody available to pair with.  For our department, pairing is the preferred method, but if nobody is available, it's not acceptable to not do any work. 

My point was that even though the issue sometimes occurs for some or most of a feature or bug development session, we always get someone to peer review the work before commiting to get at least some of that "pairing" in there.

Chris

Chris Blaise
Sunday, May 05, 2002

(sorry, my cite was "(xp explained, p. 229)" but should be "(xp EXAMINED, p. 229)."  The blue one.  Confusing.)

Sammy
Sunday, May 05, 2002

I think it is unfortunate that so much of XP is associated with pair programming.  There are other aspects of XP which can be ver helpful.  (It is unlikely that I'll ever be a fan of collectivism in programming: lumping pair programming, code style, collective ownership and homogenous programmers all together into the bag of XP I don't like).

What is there to like?  I like the planning game. 
. Customer "intimacy".
. Deconstructing features (stories) into tasks.
. Limiting scope, prioritizing features.
. Project velocity estimation (what is the implementation pace and how can you measure it?)

Of all aspects of XP, I like this best - and for purely selfish reasons:  It empowers engineers.  I'm not saying that these project management aspects are unique to XP.  But, from what I've read, XP takes the time to write it down and quantify it.  And so does Joel, see "Painless Software Schedules" out there in the archive.

I find that Joel's schedule spreadsheet fits right into an XP project plan and we use it in exatly this way.  He mentions Feature/Tasks and that's precisely the XP way.  XP mentions that you should track estmiates vs. reality - so does Joel.  So what do you get for $50 worth of XP books (XP explained, Planning XP)?  Mmmm, a good pep talk.

I'd like to try out XPlanner (an opensource thing) but don't know jack about MySQL and haven't the time right now to muck with it.  So for now, we use gnumeric spreadsheets in version control.  Also, excel (and gnumeric - its an excellent ripoff) has very cute date/day features which can help extend Joel's spreadsheet to be calendar friendly for those with Gant-chart-itis (aka program manager syndrome).

OK, but that only covers the task/schedule/velocity part of XP.  There is this whole transparency with customers, feature bounding/deconstruction section that bears mentioning - and why engineers should love it.  Because it gives you power.

Not having a marketeer playing middle man between customers and engineers not only builds better products but fosters a much closer bond with the customer.  It also allows engineers to showcase their technical skills and just how well they understand what the customer needs.  You can more quickly get to the heart of the customer's desires, rather than having them jumbled up in some metaphysical construct.  And when, at the end of the day, the customer is satisfied, who's da man?  You are...

I remember reading an op-ed piece in EE Times about why MBA's are compensated more than engineers.  The answer was because engineers aren't responsible for multimillion dollar contracts, accounts and assets.  The planning game, and customer intimacy is leverage to fix that, as can any strategy which pushes responsibility and authority into your domain.

Nat Ersoz
Monday, May 06, 2002

>>>"You're not reading what I wrote.

I said that where we use XP that we "occasionally" break the pair programming rule..."<<<

Chris: thanks for taking the time to reply.  I went back and reread your original posting. The way it was written ("occasionally I have to...") does make it sound like you are the only one exempted from pair programming, but the frequency with which that happens was a misunderstanding on my part.


>>>"My point was that even though the issue sometimes occurs for some or most of a feature or bug development session, we always get someone to peer review the work before commiting to get at least some of that "pairing" in there."<<<

But code reviews are a component of traditional software development methods and I have been trying to get a better understanding of XP.  I believe code reviews are a great way of finding problems.  But pair programming is what happens when the code is being created.

mackinac
Monday, May 06, 2002

>>>"I am insistent because the white book ("XP Explained") is the one that tells you, "That's what this book is about -- deciding when to use XP and when not to use XP." <<<

Y.H., thanks for the book review.  I'll check in to getting that one.  (Then try to find time to read it).

mackinac
Monday, May 06, 2002

>>>What is there to like? I like the planning game.
. Customer "intimacy".
. Deconstructing features (stories) into tasks.
. Limiting scope, prioritizing features.
. Project velocity estimation (what is the implementation pace and how can you measure it?)

Of all aspects of XP, I like this best - and for purely selfish reasons: It empowers engineers.<<<

Nat, Your comments are particularly interesting. I think you have the same attitude that I do, but come up with a different interpretation of XP.

My general uneasiness about XP is that it seems to dis-empower the engineer, mostly because of the factors that you dislike.

But to me, those factors, particularly pair programming, are the ones that make XP distincive.

mackinac
Monday, May 06, 2002

Macinak (are you a Michigander?)

Well, I do see the XP cup as being 1/2 full.  It has been an interesting 4 years for me out here in the greater Seattle area.  From what I've seen, many companies have been operating well into the Dilbert Zone for some time.  This at least partially catalyzed by the dot-com mania.

I found the XP info, and generally LWP discussion, to be a breath of fresh air in the Seattle software smog.  So many people writing software, so little unit testing...  It explains alot.

Also, XP can be a source of ammo.  Sometimes all that matters in life is that you show up.  When the PHB shows up with a heavyweight glob (here, I love the IBM commercial: 2 years of pure strategic thinking - can we implement it?) and I show up with my lightweight glob, I can easily win.  If I show up with nothing but cirticism of the PHB powerpoint show, I come off as whining.    Nobody likes whining.

Boards love "stuff".  They like books and names and reputations.  Of course they adore results - but in the beginning, you only have good and bad ideas - and a hope that good wins out in the end.

Nat Ersoz
Monday, May 06, 2002

You might be from[1] Michigan if:
-
- You know how to pronouce "Mackinac".
-...

[1] From - as in came from there, not there now.

mackinac
Monday, May 06, 2002

mackinac said:
What is there to like? I like the planning game.
Customer "intimacy".

my question:
I am a former software engineer and former IS manager, and have no direct experience with XP. But when I read this the first thing that occurred to me was: What if the customer doesn't want to spend their bandwidth being an intimate part of the development process? Have any XP-veterans encountered the attitude that making it work is the engineer's problem, and shouldn't take up large amounts of time on the part of the customer? After all, the customer doubtless has other concerns and demands on their time. This would certainly be consonant with some of my experiences, particularly in IS.

S Ryan
Tuesday, May 07, 2002

>>>What if the customer doesn't want to spend their bandwidth being an intimate part of the development process?<<<

Then they deserve whatever fetid pile the developers eventually hand over to them.  =-)

Programmers aren't very good mindreaders.  If you don't tell them what you want, you probably won't get it in the final product.

Alyosha`
Wednesday, May 08, 2002

S Ryan writes:

>>>"mackinac said:
What is there to like? I like the planning game.
Customer "intimacy"."<<<

Nat Ersoz gets credit for that statement.  I was just quoting him.

mackinac
Wednesday, May 08, 2002

Oh, hey, that's me...

XP calls for the customer, or user in some sort, to be on-site (though I don't recall what the duty cycle of on-siteness is - is the customer there all the time, one day per week, etc. -- what is the minimum on-siteness and still be called XP, I'm not sure and the books are at home).

XP makes the argument that the customer has every interest in being on site, or having a sufficiently empowered representative.  The representative should have the authority to deal with schedules and features without having to phone home at every decision.

Does the customer have better things to do?  XP makes that argument that they probably do not if the software project is of sufficient importance.

The underlying premise is that the customer understand the software development process, that features take time, that changes are acceptable, that releases will be frequent (and if you're onsite, you can see features as they are developed, and even make corrections before the test process is complete).

The idea of a copperative customer who understands the development process, and a development group which is fully transparent, promotes an ideal environment.  I completely agree.

Nat Ersoz
Thursday, May 09, 2002

*  Recent Topics

*  Fog Creek Home