Pair programming sucks

[Josh Brown]

Despite all the reasons I've read that pair programming is less distracting, I tend to think it would be much much more distracting for me. While I've never done it, I have occasionally sat next to someone to help them debug their code. When I'm watching/working with/pairing with another, it's very easy for me to get distracted by the way they do things. Little things bother me, like someone not using keyboard shortcuts, typing slowly, or spelling things incorrectly. It's frustrating for me to watch someone else use the keyboard to type, then have to grab the mouse every time they want to save or build or switch to another window. Maybe Ctrl+S doesn't save (pun not intended, but acknowledged) that much time, but it's a lot easier, in my opinion. I'm a keyboard shortcut guy. Mouse people frustrate me...

How do you (pair programmers) deal with issues like these?

[Lasse Koskela]

Originally posted by Josh Brown:
When I'm watching/working with/pairing with another, it's very easy for me to get distracted by the way they do things. Little things bother me, like someone not using keyboard shortcuts, typing slowly, or spelling things incorrectly. [...] How do you (pair programmers) deal with issues like these?

Being patient and respecting the individual seems to do the trick for me. Also, it helps when you help. Show the other guy handy shortcuts, better ways of doing things. You might not want to do that every time but persistently reminding him about those shortcuts will eventually have an effect. Furthermore, you could change the frequency and duration of your pair programming sessions. For example, just having some time alone, the individual might feel secure enough to experiment with what you had just mentioned 15 minutes earlier.

[Ilja Preuss]

Josh, I know what you are talking about. I had that problem when pairing with my best friend. It took her years to accept that learning shortcuts is a good idea.

On the other hand, I also learned a lot from her while pairing, so the patience definitely has paid back.

[Jeff Langr]

Originally posted by Dario Laverde:

In fact of you pair two senior level (seasoned gurus) together, you'll get less productivity than if they were to work separately.

In fact, I've paired with other senior developers and have been considerably more productive.

Many developers who initially resist pairing learn to enjoy it and benefit significantly from it, if it's applied well.

Obviously, pair programming isn't for everyone. However, nor is isolation-based programming.

Jeff

[Jeff Langr]

Originally posted by Josh Brown:
I tend to think it would be much much more distracting for me. While I've never done it, ...

You should, and then return here to post some additional comments.


When I'm watching/working with/pairing with another, it's very easy for me to get distracted by the way they do things...

There are indeed individuals who go far too slowly for my tastes. I'm sometimes mildly offended by the typing skills of people who profess to code for a living. I'm also mildly offended by people who have worked in an environment for 10+ years, such as vi, yet know so little of their preferred tools (or even their chosen language). I have patience--but only so much.

We discuss these things as we develop, and they pick up new techniques. Often, it's only a matter of a couple 90-minute sessions before they're showing marked improvement. Often, they end up showing me something new in short order, so both of us benefit. It's not hard to take a relative novice, or anyone with an open mind, and double their productivity in many areas. How much is that worth to the team? It's worth a lot to me--it's nice knowing how much I can depend upon my team members in crunch time.

Sometimes, they remain slow. I don't expect everyone to be a speed demon at the keyboard, but I do expect them to learn how and attempt to be more effective. Over time, the underperformers fall by the wayside, or move off to other projects. OK by me.

Jeff

[Jeanne Boyarsky]

The typing speed concept is interesting. While I'm a keyboard person, I don't care whether someone uses the keyboard or the mouse to do things. I do comment periodically to remind people about IDE tools. For example, renaming a variable using Eclipse's refactoring menu vs changing them all by hand.

I have noticed a patience for people who type slow thing. I don't mind hunt and peckers. But every so often you find a hunt and pecker who types really SLOW. It's like they haven't seen the keyboard before. When pairing with this kind of person I find myself asking to drive when a typing intensive task is coming up. Under the guise of it's not something that involves a lot of thought (like a non-IDE based refactoring) and it will be faster if I type. This feels icky though and I imagine there is a better way of handling things.

[Jeff Langr]

Originally posted by Jeanne Boyarsky:
The typing speed concept is interesting. While I'm a keyboard person, I don't care whether someone uses the keyboard or the mouse to do things. ...

I have noticed a patience for people who type slow thing. I don't mind hunt and peckers. But every so often you find a hunt and pecker who types really SLOW. It's like they haven't seen the keyboard before. ...

I'm ok with people who prefer the mouse, but I'll still try to get them to learn a few shortcuts if it seems like the mousing is bogging things down. Sometimes I pick up a few mousing tricks.

Every so often, I find a hunt and pecker (hmm) who also seems to struggle with basic syntactical things--forgetting an ending semicolon, for example, and not just once but every time!. I wonder how they made it so far with sub-par control over their tools. I think one of the sadder downsides of isolation-based programming is that we do leave people by the wayside, when they might have improved over the years with a bit more peer pressure and assistance-- perhaps through some pairing. I do feel good in that I've helped many of these developers revive an interest in improving themselves.

Jeff

[suresh koutam]

i like pair programming just because it brings the best of two minds....i agree that there should be understanding between the people who work together.....

I like shortcuts and always show my friends how to do that....they like it...some times i learn from other guys who are very good at GUI buttons....

I agree that sometimes when we are involved in some debugging or logic analyzing situations...an extra pair of eyes will do more good than bad...isolated programming will never get the best of any programmer....

[Ilja Preuss]

One of the most often heard sentences when our team started to pair program was "Wow, how did you do *that*?" We all learned a lot of new keyboard shortcuts.
[ November 01, 2007: Message edited by: Ilja Preuss ]

[Christophe Verré]

We all learned a lot of new keyboard shortcuts.

I hope you'll not say that this as an advantage of pair programming But I agree that sharing with others brings a lot. I had a discussion once with a coworker, and we were challenging about the most useful Eclipse shortcut. That was fun and instructive.

[Damon Black]

Originally posted by Mike Dawson:
If done properly it brings a dynamic all of its own where you can learn.

I guess it's the "If done properly" clause that's the kicker. In my few years of dealing with it, that's been a rarity. So I wonder, how effective is a discipline that is so easy to do poorly?

That's where I start to see much of the XP/Agile zeitgeist as pie-in-the-sky fantasy. It doesn't help that most of the theory was cooked up by gifted, experienced coders looking to work in a way that was comfortable for them. My guess is that if you assigned several of these guys to a team they could successfully work through (or around) just about any methodology. The real test is how the average team in the trenches deals with it. My experience with that end of it argues strongly against XP.

As far as pairing goes, I still think it's largely a temperament thing. If pairing is an optional tool that programmers can use at their discretion, it can only help. But as a required practice it flies in the face of 'People over Process' in a big way, ignoring the fact that some people have a really tough time 'thinking in unison' with another person.
[ November 01, 2007: Message edited by: Damon Black ]

[Jeff Langr]

Originally posted by Damon Black:
I guess it's the "If done properly" clause that's the kicker. In my few years of dealing with it, that's been a rarity. So I wonder, how effective is a discipline that is so easy to do poorly?

I could say that about just about anything, including Java development itself, or RUP, or waterfall. In reality, understanding how to do pairing well is pretty easy to do, it's just that most people can't be bothered to do enough investigation or apply enough guidance to see it through properly. The reason we prefix things with "if done properly" is because too many people have a surface definition of pairing that's not correct.

That's where I start to see much of the XP/Agile zeitgeist as pie-in-the-sky fantasy. It doesn't help that most of the theory was cooked up by gifted, experienced coders looking to work in a way that was comfortable for them. My guess is that if you assigned several of these guys to a team they could successfully work through (or around) just about any methodology.

That last sentence is probably true. It doesn't make it pie-in-the-sky fantasy, however, as I've seen a number of teams with less-than-stellar developers succeed with it.

The real test is how the average team in the trenches deals with it. My experience with that end of it argues strongly against XP.

My experience with that end argues strongly against any process. My take is, while pairing may not solve the problem of an average team, all of the other processes only make things worse. Isolation-based development means we let the underperformers go off into their cube and produce bad code, which has the potential of destroying the project (seen it).

If the average team has enough senior developers that understand how to apply pairing (or other XP concepts), many of the remainder of the less-than-senior developers quickly grow in capability, moreso than in an isolation-based programming environment. This I've seen in several teams.

As usual, YMMV. My take is that not everyone is dumb enough to do pairing all the time, nor is everyone dumb enough to insist that everyone hide in a cube, and that will probably never change. Find a shop that suits your preferred way of working and go there.

Jeff

[Ilja Preuss]

Originally posted by Christophe Verre:
I hope you'll not say that this as an advantage of pair programming

But it *is*. Seriously.
[ November 02, 2007: Message edited by: Ilja Preuss ]

[Damon Black]

Originally posted by Ilja Preuss:

Originally posted by Christophe Verre:
I hope you'll not say that this as an advantage of pair programming

But it *is*. Seriously.

I can attest to this as well. It's one of the most useful benefits of pairing in my book. Honestly, seeing these shortcuts used repeatedly, and feeling a subtle pressure to use them yourself, helps push you into learning them (when you might not have gone to the trouble otherwise). And I've never heard anyone grumble about it once they adopted the habit.
[ November 01, 2007: Message edited by: Damon Black ]

[Christophe Verré]

Ok, so we have another advantage of pair programming.

And I've never heard anyone grumble about it once they adopted the habit.

Unless it goes like "while you press CTRL, I press C"

What would happen if you'd pair with somebody who really doesn't help (maybe because he doesn't know much) ?

[Vinayagam Kulandaivel]

Hi Christophe,

Some one should have to take care of this while pairing!

Thanks & Regards
Vinayagam

[Shane Warden]

Originally posted by Damon Black:
And I've never heard anyone grumble about it once they adopted the habit.

Heh, I can think of one person I've tried to pair with who absolutely *refuses* to use bash or Vim shortcuts or ctags or any of that lovely stuff. At least this person uses screen, but... yeah, it can be painful to pair with someone who always does everything the difficult way.

[Damon Black]

Originally posted by Damon Black:
I guess it's the "If done properly" clause that's the kicker. In my few years of dealing with it, that's been a rarity. So I wonder, how effective is a discipline that is so easy to do poorly?

Originally posted by Jeff Langr:
I could say that about just about anything, including Java development itself, or RUP, or waterfall.

I suppose you could. And given that I've never done 'waterfall' and that I don't even know what RUP is, I'll have to take your word for it.

So, in your opinion, is there a place in an 'agile' shop for someone who works better in a quiet, focused setting (not pairing)?
[ November 02, 2007: Message edited by: Damon Black ]

[Ilja Preuss]

Originally posted by Damon Black:

So, in your opinion, is there a place in an 'agile' shop for someone who works better in a quiet, focused setting (not pairing)?

That's a non-trivial question.

First let me say that I experience Pair Programming to be *more* focused than solo programming, not the other way around.

So what if you are less productive when pair programming?

Well, what's relevant to the business is not your individual productivity, but the productivity of the team (and other things, such as reduced risk). So even if pairing reduced your productivity, it could still be sensible to practice it, because of other benefits.

As an aside, I've noticed that, even if pair programming *feels* less productive while doing it, it often actually isn't.

Another question is whether there is a place in an Agile team for someone who doesn't *want* to do Pair Programming. As in Agile development the process belongs to the team, that will mostly depend on your teammates.

[Jeff Langr]

Greetings Damon,

Originally posted by Damon Black:
So, in your opinion, is there a place in an 'agile' shop for someone who works better in a quiet, focused setting (not pairing)?

In all honesty, most "agile" shops don't do pairing, or if they do, they do it infrequently and inconsistently. It's mostly the shops that actually use the word "XP" that are doing the pairing. So I don't think you have to worry too much about places to choose from.

I've written a few articles on pairing; I usually talk about how I came from your position of resistance, but that I grew to really enjoy it and have gotten a lot of benefit out of it. There are many benefits for both management and developers that can be derived.

Ilja's response is dead on: it's up to the team to decide if they want to work that way. In fact, I would be leery of working in an organization where someone up above (a VP, perhaps) insisted that every team had to pair. But ultimately, if the team does decide that everyone should pair, then you should either learn how to make the best of it or go find another group. Same applies to working in cube farms.

Jeff

[Damon Black]

Originally posted by Jeff Langr:
In all honesty, most "agile" shops don't do pairing, or if they do, they do it infrequently and inconsistently. It's mostly the shops that actually use the word "XP" that are doing the pairing. So I don't think you have to worry too much about places to choose from.

That's reassuring. And it's more or less the impression I got at Agile 2007, where a great many of the sessions were about convincing management to try some agile practices. None of the people I talked to there worked in in shops as rigidly agile as my previous employer. I'm going to go on the assumption that seeing "agile" in a job ad doesn't necessarily mean they pair, or do the bullpen stuff.

I've written a few articles on pairing; I usually talk about how I came from your position of resistance, but that I grew to really enjoy it and have gotten a lot of benefit out of it.

For me, it sort of seems the opposite. See, I started at an XP shop and initially I was very enthusiastic about all of it, including pairing. But from the beginning I felt awkward and clumsy when I tried to pair. For a long time I assumed it was just a matter of my inexperience. I assumed that as I became more confident and skilled (at both coding and pairing), things would improve. So I've spent the last year and a half working hard to make that happen. But even though I'm a better coder, and somewhat better at pairing, it still feels wrong.

The thing that really gets me, is that when I do have the luxury of working alone, the difference is like night and day. Everything makes sense, I'm calm and focused, and productive, and I actually have fun while I work.

I would be leery of working in an organization where someone up above (a VP, perhaps) insisted that every team had to pair.

That's exactly the situation where I used to work. I really do think pairing would be far more useful, and enjoyable, if it was treated as a tool that programmers can use when the need it. To apply it as a mandated practice seems to be a misapplication of the stated values of agile and xp.
[ November 02, 2007: Message edited by: Damon Black ]

[Jeff Langr]

Originally posted by Damon Black:
That's exactly the situation where I used to work. I really do think pairing would be far more useful, and enjoyable, if it was treated as a tool that programmers can use when the need it. To apply it as a mandated practice seems to be a misapplication of the stated values of agile and xp.

Well, as a stated value of agile, yes, and XP as of XP2e, probably. But XP version 1 explicitly expected developers to pair on all production code.

I think the business can and should mandate that code is reviewed rigorously--they need to protect their investment. I don't think most organizations should go as far as mandating the means. That could be through pairing or some other mechanism (Fagan inspections?).

Jeff

[Jeff Langr]

Originally posted by Damon Black:
The thing that really gets me, is that when I do have the luxury of working alone, the difference is like night and day. Everything makes sense, I'm calm and focused, and productive, and I actually have fun while I work.

I enjoy either, but pairing more.

You might ask for someone to monitor things the next time you attempt (or are forced to attempt :-)) pairing. You might also try pairing with a fairly senior person. A single session isn't enough--the first session is usually a process of working through an understanding of how each other works.

Jeff

[Damon Black]

Originally posted by Jeff Langr:
But XP version 1 explicitly expected developers to pair on all production code.

Ayup. We were explicitly a version 1 shop. Our 'coach' bought up a bunch of copies of the first edition book and made sure everyone read it, rather than the second edition.

I think the business can and should mandate that code is reviewed rigorously--they need to protect their investment. I don't think most organizations should go as far as mandating the means. That could be through pairing or some other mechanism (Fagan inspections?).

Oh yeah... I definitely see the need for review. I read Peter Goodliffe's Codecraft a few months ago. While I gather that much of what was in the book was considered 'traditional wisdom', most of it was new to me. In particular I liked the idea of regular code reviews, as it seemed like a great way to see the big picture and maintain knowledge of the architecture as it develops. Like most of my impulses, the idea was rejected out of hand by our 'coach'. "We do continuous code review, that's what pairing is." I can see how that's how it should work, but it rarely did.
[ November 02, 2007: Message edited by: Damon Black ]

[Ilja Preuss]

Originally posted by Jeff Langr:

But XP version 1 explicitly expected developers to pair on all production code.

Note that according to Kent, XP2e describes exactly the same XP as the first edition, just with different words.

[Jeff Langr]

Originally posted by Ilja Preuss:
Note that according to Kent, XP2e describes exactly the same XP as the first edition, just with different words.

Greetings Ilja,

I think I should go back and re-read it. My first reaction, which I thought was also bolstered by some of Beck's postings at the time, was that Kent felt that a process should not be so prescriptive.

Jeff

[Ilja Preuss]

Originally posted by Jeff Langr:

My first reaction, which I thought was also bolstered by some of Beck's postings at the time, was that Kent felt that a process should not be so prescriptive.

I found it!

http://tech.groups.yahoo.com/group/extremeprogramming/message/98303

The new edition of XP Explained doesn't describe a different XP than the first, it explains it more clearly, with the benefit of five years' experience.

Some more interesting quotes from Kent:

http://tech.groups.yahoo.com/group/extremeprogramming/message/106962

The first edition of XP Explained was a first draft. The second edition
intends to cover the same ground more clearly and explicitly so that there
is less room for misinterpretation.

http://tech.groups.yahoo.com/group/extremeprogramming/message/107769

The first edition of XPE is "the" answer (which is absurd but comforting for those who don't like ambiguity). The second edition is [...] a method for finding the answer with hints of previously-valuable directions for exploration.

http://tech.groups.yahoo.com/group/extremeprogramming/message/104327

I think the difference is that in XPE2 I am not offering people the illusion that they aren't responsible for their own choices. After all, if you just copy what I do, then it appears to the twisted that I am responsible for the outcome. That's not now it works out.

http://tech.groups.yahoo.com/group/extremeprogramming/message/128285

I think the second edition presents a more rigorous and demanding process
than the first. The second edition expects you to pay attention to people
and context, not just check off a bullet list of practices.

[Damon Black]

I read the second book first, then the original. My general impression was that the first took on a more confrontational tone, where the second seemed more inclusive of the business perspective. And I have to agree with Jeff, the second book did seem to suggest more flexibility. If Kent Beck is saying that both books describe the process, then I'd say we have to take his word for it. But there do seem to be subtle differences in the message. Maybe he needs to do a third edition to clear things up.

[Jeff Langr]

Originally posted by Ilja Preuss:
Kent: I think the second edition presents a more rigorous and demanding process than the first. The second edition expects you to pay attention to people and context, not just check off a bullet list of practices.

Thanks Ilja for doing the research!

That quote is in alignment with my notion that XP1E is very prescriptive, and XP2E says that things are best dealt with in context. My original point was that, per XP version 1, you had to do pairing or you weren't doing XP.

Jeff

[Ilja Preuss]

Originally posted by Jeff Langr:

That quote is in alignment with my notion that XP1E is very prescriptive, and XP2E says that things are best dealt with in context. My original point was that, per XP version 1, you had to do pairing or you weren't doing XP.

The way I interpret it is: yes, the first edition of the book was more prescriptive - or at least easily understood to be more prescriptive - than the second edition. That was a flaw of the book, though, not a flaw of XP itself.

[Damon Black]

Originally posted by Ilja Preuss:
... not a flaw of XP itself.

out of curiosity, what are XP's flaws, in your opinion?

[Ilja Preuss]

Originally posted by Damon Black:

out of curiosity, what are XP's flaws, in your opinion?

Frankly, I currently can't think of one.

[Jeff Langr]

Originally posted by Damon Black:
out of curiosity, what are XP's flaws, in your opinion?

I'm not sure I'd consider these flaws of XP, but they are certainly things that many teams find hard to meet:

- the discipline to always write tests first
- removing as much possible duplication in code when refactoring, to keep the code base clean. Most developers, even senior ones, don't do this enough.
- figuring out how to automate acceptance tests

XP is one of the more disciplined processes out there. Success is a matter of practicing and not abandoning the disciplines (or more importantly, the principles and values behind the disciplines), when it seems convenient to do so. I think XP requires more courage than a lot of people and organizations have.

Yet for all that talk about discipline, the teams that are doing XP well have a great time with it.

Jeff

[Damon Black]

Originally posted by Jeff Langr:
- the discipline to always write tests first
- removing as much possible duplication in code when refactoring, to keep the code base clean. Most developers, even senior ones, don't do this enough.
- figuring out how to automate acceptance tests

We managed to test-drive pretty consistently, but often the red-green-refactor cycle devolved to red-green-"next!", especially under time pressure.

That last one was spotty. We squeezed quite a lot out of Fitnesse, but in my opinion over-used it for page display tests. Selenium looked promising but was deemed too slow.

Of course pairing has my vote for the 'weakest link', but that's more my deal than anything inherent in XP.
[ November 08, 2007: Message edited by: Damon Black ]

[Jeff Langr]

Originally posted by Damon Black:
We managed to test-drive pretty consistently, but often the red-green-refactor cycle devolved to red-green-"next!", especially under time pressure.

Exactly. I think it's a tough discipline. Often we don't learn until it's too late that it's going to cause major headaches. The effect often appears long after the cause. The pressure of short cycle iterations can make disregarding refactoring in the short term too tempting.

It's one reason I hate the term sprint (among a few other things) in that other agile methodology. You can't keep sprinting (i.e. busting your butt to get an iteration delivered) without crashing at some point down the road.

Unfortunately I've seen it a team neglect refactoring a few too many times. I've seen sizable systems scrapped (2), performance fiascos (1), some mid-project ugliness (many) and utter code disasters (1).

Jeff

[Damon Black]

Heh... I just realized you authored one of my favorite programming books. I wish I'd found it sooner, as I'd already been working at Agile for a year or so when I read it, but it really helped me see things in context and filled in more than a few blanks. Thanks!

[Rusty Shackleford]

Constant distractions, noisy environment, people looking over your shoulder. What a mess.

XP is NOT a natural way to do things. That fact you need a coach is proof of that. YAGNI is just code for 'I just wasted my time on something because of a lack of proper up front design, but I am going to pretend it is something postive'. It is exactly this sort of BS that made me switch my CS focus to network security.

If you are constantly communicating, you are distracted by the task at hand. There is a lot of value in agile practices, but XP is 50% hype, 50% cult.

The problem with any process is that it is a one size fits all approach. What makes XP worse is that it is very rigid. One part fails, the project starts spiraling down.

A shop that rigidly adheres to any process is not a shop worth working for. Whatever process you use must be tailored to fit the dynamic of the team and work to the strengths of the individual programmers. Otherwise you are just pounding a square block into a round hole.
[ November 11, 2007: Message edited by: Rusty Shackleford ]

[Frank Carver]

Originally posted by Rusty Shackleford:
Constant distractions, noisy environment, people looking over your shoulder. What a mess.

Just as an aside, I don't think you can really count these as drawbacks of XP or agile methods. I have been working in software development for about 25 years, for several different companies, with a wide variety of corporate attitudes to software development. I can't think of a single case where I have not had "Constant distractions, noisy environment, people looking over your shoulder". Perhaps your experience has been different.

For me, at least, agile development is an effective way to make use of such an environment, certainly not the cause of it!

[Rusty Shackleford]

Originally posted by Frank Carver:


Just as an aside, I don't think you can really count these as drawbacks of XP or agile methods. I have been working in software development for about 25 years, for several different companies, with a wide variety of corporate attitudes to software development. I can't think of a single case where I have not had "Constant distractions, noisy environment, people looking over your shoulder". Perhaps your experience has been different.

For me, at least, agile development is an effective way to make use of such an environment, certainly not the cause of it!

Certainly other factors not related to any specific process do contribute to a distracting environment, but the core of XP demands a distracting environment. This is why I think it is perfectly valid criticism of XP.

[Lasse Koskela]

Originally posted by Rusty Shackleford:
Constant distractions, noisy environment, people looking over your shoulder. What a mess.

Hmm. That sounds more like the waterfall, big design up front, everyone sits in their own cubicles Big Corp stuff I used to be part of some years ago. And yes it was a big mess. It wasn't noisy, though. It was dead silent. Productivity was pretty dead, too.

Originally posted by Rusty Shackleford:
XP is NOT a natural way to do things. That fact you need a coach is proof of that.

Isn't that like saying it would be much better if [your favorite football team] didn't have a coach at all? It might, at first, be more comfortable to the players. I doubt that they'd fare much better in the league, though.

Anyway, needing a coach has nothing to do with XP being or not being a natural way to do things. It has everything to do with the dysfunctional ways we need to unlearn first--the habits we were assimilated to over the years in school, on our first job, etc. This is why coaches are important.

To me XP is a natural way to do things.

Originally posted by Rusty Shackleford:
If you are constantly communicating, you are distracted by the task at hand.

Have you actually experienced such a situation? You see, I haven't. Yes, I've been distracted from the task at hand but not without a reason. I appreciate that people have different thresholds for noise, distraction, and so forth but what you're describing doesn't sound familiar to me at all.

Originally posted by Rusty Shackleford:
The problem with any process is that it is a one size fits all approach. What makes XP worse is that it is very rigid. One part fails, the project starts spiraling down.

We use Scrum with a varying selection of XP engineering practices. For any practice or element that we've not taken from XP has been substituted by something we've taken from Scrum or elsewhere. So far I haven't seen many problems with this approach.

The kind of spiraling down that you're describing doesn't happen because you've taken something out from XP. It happens because you haven't substituted it with a compensating adaptation to your process. It's not really much different from any other process in that sense.

Originally posted by Rusty Shackleford:
A shop that rigidly adheres to any process is not a shop worth working for. Whatever process you use must be tailored to fit the dynamic of the team and work to the strengths of the individual programmers. Otherwise you are just pounding a square block into a round hole.

Agreed. People over process. Again, however, I've found XP and Scrum being much more "people over process" than any alternative I've seen.