Discussions

Talk of Extreme Programming is getting more and more common. Management is learning about it, and it is being used on many projects. Is it the best way to do software development? Is it right for all projects? A couple of developers are speaking out.

Once again, I find myself in brutal agreement with her. I have been observing XP as a curious beast since pretty much its inception and I have always been uncomfortable with most of the concepts this methodology preaches. In short, it is just at complete odds with reality. Let's take pair programming, for example.

1) Financially.

You cannot convince anyone in the manager and above layer that it's worth spending the salaries of two programmers to achieve the job of one. In their eyes, quantity matters more than quality, and while I used to recoil in horror at this idea, I am now slowly beginning to realize that they are right. Except that quantity and quality are not necessarily at odds if you have a good QA department. This should certainly not be a license for developers to spurn code like mad without paying attention to quality and trying to write tests before implementing, but overall, the combination of developers + QA engineers can work wonder, and you will get twice as much done than XP will ever allow.

2) Socially.

Have you ever tried to sit near a fellow developer and work with her on a problem? If you haven't give it a try and come back when you are done. My experience is that it is one of the most frustrating endeavors a software developer can ever be submitted to. There is so much dissonance in this exercise that the mind reels.

Mental dissonance, first. Even if both developers have similar backgrounds and a similar amount of knowledge (already an impossibility in my opinion), there is still the problem that both of you will have different ways of solving the problem. Granted, you might eventually agree on a common solution if both are open-minded (another requirement) but it's going to take a lot of discussing before reaching that point.

Then, practical dissonance. Most likely, you are not working at the same pace as your XP partner. You are either slower or faster. If you are slower, the growing unrest and impatience of your partner will eventually get to you. If you are faster, you will be squirming on your seat and wishing you could take the keyboard away from the slowpoke so you can get things done, at last. What if you are using an IDE and the unfortunate soul is using a text editor? You are going to cringe, trust me ("where is that source file again? Ah yes, src/com/foo/... er... what was it again?") If you are using a text editor and your partner is using an IDE... well, you will want to punch her nose after ten minutes of work to put an end to her constant reminder on how you would work faster with an IDE.

I could go on and on and dissect Kent's book chapter by chapter. Note that I still recommend you read that book, because you will most likely learn things about yourself and software engineering in general, but I can't really see how XP programming will ever leave the realm of academia.

And I would be extremely wary of working for a company that has made it its True and Only methodology.

No, XP is not the best way to build software for everyone all the time.

Nobody worth his salt in the XP community thinks that way about XP. Ron Jeffries says that XP is the best way he knows to build software, meaning that it is the philosophy that most works for him; therefore, he believes it will work for others, and he has been trying to spread that message ever since. The fact that the community at large doesn't like it doesn't make it evil.

If you don't like XP, that's fine; then don't do it. There are still millions of job opportunities for people who don't want to do XP. Just shut up and let the rest of us who want to do it, do it where we can.

Our success does not mean your failure, and vice versa. Can't we all just get along?

"If you don't like XP, that's fine; then don't do it. There are still millions of job opportunities for people who don't want to do XP. Just shut up and let the rest of us who want to do it, do it where we can."

You see, you already know the answer ... I'm not surprised people don't think and act the same way. In fact, diversity is a good thing.

Disagree: less intrusive peer review processes don't last. Under pressure, one of the first things to chop is "all that time wasted in testing and peer reviews."

In my experience, it's easier to keep PP than it is to keep doing after-the-fact peer reviews.

Also in my experience, after-the-fact peer reviews are too late. It's like testing at the end of the project: it's great that you tested, but who has time to fix the defects?

I recently taught a course at Rational. I saw a great poster. The punchline: "Testing should be done on people who think that testing should be done at the end of a project." The same is true of after-the-fact code reviews, in my opinion. (Please remember that it's a punchline, so take it as a joke. No offence intended. I don't really think you're mentally impaired.)

I've been working as a consultant and with one client,we had this XP methodology workshop by two XP mentors for a Java Project(about 25 persons and all are contractors).The XP implementation turned out to be a big failure for the foll. reasons what I found :

1. XP could work for small projects with minimum no. of persons who should be employees,not contractors.

2. Concept of Pair programming is bullshit where,when you're good in programming and your pair doesn't,you'll end up coding all the tasks assigned to your pair and the other pair persons slacks off.( I had this experience where I had to do all of the stuff!!)

3. Also, continuous integration and test before code concepts did consumed more time than it should.

None all the projects can be conceived using XP.
None all programmers are prepared to use XP... though this can be achieved with two simple issues: teaching and learner's open mind.

I worked using XP and it became my best professional experience... in all the senses:
- Pair programming allowed us to undertand the whole project.
- The code was done faster and more reliable (it's not a slogan but the truth).
- We got to the milestones at time (first and only time in my eight-year professional career..... and the only reference for all the people I know).
- At personal level, it was great too.

But, it's true: It's difficult to convince high staff that two persons working on the same machine is better. But the most difficult thing is that they don't like you to be comfortable at work even if all the metrics was at our side.

(sorry for this english of mine... it's a long time since I haven't spoken in this language).

For thsose that have been in software development for at a number of years, you've probably learned one thing about methodologies:

1. Use a methodology (unless your project is very small)

2. Use one that works *for you and your team*.

Methodologies are not magical formulas to guarantee the successful delivery of a project. They are just blueprints, or guidelines that give you a better shot at delivering. Having said that:

- You've picked on one aspect of XP that is the most radical to developers: pair programming. My experience is that pair programming happens naturally on a project, XP or not. When a developer gets stumped, they ask for help. XP just formalizes that. IMO, the pair programming should be used in two circumstances. First, use it in a junior-senior mentor-mentee situation. Junior person learns some tricks of the trade and *hopefully* the senior person gets exposed to a fresh perspective and ideas. Second, pair up on implementing a complex design. It's a good cross-training exerciseat a minimum.

- Most all of the other tenets are extremely valuable: unit testing, automated build, etc.

So let's not chastise the methodology, but those that might use it inappropriately.

I will agree with you that I don't believe XP is the right methodology for large enterprise projects. IMO, these type of projects require solid up-front design and XP shys away from that. Deferring design on this type of project can really cost you if you hit design flaws late in the development cycle.

I think many companies try to turn methodologies into Methodologies - meaning they try and take something that might work for a given team and turn it into something that works for everybody, under every situation. One of my former clients is big on doing that. In fact, their latest Methodology is XP - every project now is done according to how they view XP - they are always after that silver bullet that will produce consistent results all the time, no matter who is doing the programming - like cooking a hamburger at Mc Donalds or something. Any pasty-faced teenager can cook a hamburger consistently if they follow the Manual.

This company has been doing this sort of thing for years (whatever happens to be the trend, ISO, SEI's stuff, whatever) and their IT project success rate is pretty poor, as you might imagine.

Personally, I wouldn't fit well in an XP environment - but that's not to say that there aren't teams where that would work great. But software development has too many variables in it to be such that one Methodology, XP or otherwise, will work every time.

Excellent points. The bottom line is that managers KNOW that PP works, because they use PP on the most critical parts of their project. If they only believed that every part of their project was at least important, they might consider using PP throughout.

You might say, "Not all parts of my project are *that* important." You'd be right. Not everything is critical. There are some tasks that can be tackled by a solo programmer. There might even be tasks where PP is 100% overhead: all cost and no benefit. Agreed.

HOWEVER, those tasks are usually short: measured in hours. Anything that takes longer than that generally has a big-enough margin-for-error with respect to effort and time that the task will "run away" from a solo programmer to proud or frightened to ask for help. Here, PP would have eliminated considerable waste.

ALSO, if you use the less-important tasks as a chance to practise PP, you'll be very good at it for use on the critical tasks, when being effective at PP saves the project days or even weeks. Once again, it's a question of seeing the big picture: the project is much more than just the one task you're working on today.

So if PP happens naturally on a project; or if managers know that PP works because they use it on critical parts of the project, then XP simply says, "Since PP is so effective, let's do it all the time." It may not be needed all the time, but the more we do it, the better we're able to do it when the s2t hits the fan.

Yeah, I've seen that site, too. It is quite old and most of their points were shot full of holes by some of the leading XP advocates (Jefferies included). I wouldn't pay much mind to that site. It appears Stephens main goal is to bitch about things he doesn't understand.

BTW - have you tried XP, Vic? If you have, I would be interested in some of your critiques. If you haven't, you don't really have a good point of reference, do you?

its a way to know more of personal life of ur fellow programmer than the project, get to sit with him/her, crack some jokes, laugh on some matters like how they both suck on some programming matters, curse each other on how one thinks he is the best , his IDE is the best, his style of commenting is the best etc ...
XP should be thrown out the door .. no more discussion needed.

"its a way to know more of personal life of ur fellow programmer than the project, get to sit with him/her, crack some jokes, laugh on some matters like how they both suck on some programming matters..."

I have to agree with Ryan on this one. If both programmers are lazy bums, then that might be the case. But the great thing about pair programming is that both programmers don't have to be "on" all the time. One person may be more focused and help focus the other. That way you don't get two tired/brain-fried programmers separately surfing the web after asking for insane schedules. :)

Hi Ryan
I m not a XP programmer to talk from my mouth as well as from my ASS. I dont waste 2 resources to do one thing. I just use right things for right purpose. come out of the XP mode and u will realize that ASS is not used for talking.

Ah, quite the clever one. OK. Seriously - have you ever tried XP or pair programming? If not, than I would have to say that your opinion matters little in this discussion.

Pair programming is not about sitting around with co-workers and goofing off. It is about working together. Besides, it doesn't take PP to goof off. You can do that anywhere. But pair programming does have value. In fact, I will give you an example for today...

I was working on a XSL-transformation issue today. My XSL skills are, shall we say, green. However, a co-worker is very knowledgable of XSL. However, I have been knee-deep in this code for the past few days, so I was more familiar with the current "domain". So, we got together and knocked out the work in a matter of hours. On top of that, he is now more familiar with the current code base, and I learned more about XSL. That is what PP is used for.

This is a perfect example of PP at work: one person has the domain knowledge, another has the technical knowledge, and the two together do much more than either could do on his own. Even the harshest skeptic can see that that is true.

Now this is an extreme example -- no pun intended. Usually A knows part of the solution and B knows part of the solution. Random chance dictates that A needs to learn half of what B knows and vice versa. It is easy to see that unless the learning costs much less than the time it takes for B to work on the task, A+B will work much more quickly than A alone learning what B knows.

The cost of A learning what B knows (without B's help!), over time, is UNBOUNDED. Some stuff takes hours, some days, some weeks and some months. Tell me know that A and B working separately is faster when A could spend three weeks learning what B already knows!

Hi Ryan,
I appreciate the serious example you gave me. I have been thro XP for abt 6 to 8 months with my current employer. I dont say there are no advantages. But for most of the programmer population the real meaning and use of XP is never conveyed properly. XP was introduced with a good intentation, but i think it was just used more like ' the new thing' or 'latest buzz word' fashion.
And as for the " quality vs. quantity " argument,
1. i think if the quality of both the XP partners is the bad, then doesnt matter how many of them u put in a team, its not gonna improve.
2. If one is too good and one is not at all, then the good programmer may think he is wasting his time *TEACHING* the bad one.
3. If both the partners are good then they either argue on some stupid concept/ fundamental or if they dont fight then u may be wasting ur resources by using two good programmers doing one job.

And so to us, we started using XP in a PP way as in the good programmers will help and guide the 'not so good ones' and have some weekely 'code walk thrus' to ensure quality. This way we achieved some good quantity along with quality.
I have come across cases where in - some members started to argue to much with the other partner, some just took as a chance to *know* the other person well and things like that.
I think there is nothing like XP is great or PP is great. No one can follow only one of the two strict lines. You got to look at ur programmers, their skills, knowledge and bridge the gap to make sure u are headed towards ur goal. More books and articles on XP will be a good way to start lookign at things. I havent see a lot of books on XP which make good sense and convey the real meaning.

<shs l>
I think there is nothing like XP is great or PP is great. No one can follow only one of the two strict lines. You got to look at ur programmers, their skills, knowledge and bridge the gap to make sure u are headed towards ur goal. More books and articles on XP will be a good way to start lookign at things. I havent see a lot of books on XP which make good sense and convey the real meaning.
</shs l>

I agree, and I'll go further. Many XP books argue that when there's a conflict between an XP principal and the company/group you're in, the company/group should change. For example, if pair programming isn't working 'cuz you're in a cube farm, then you should switch to a more open office format. Or, if you're trying to refactor legacy code and failing, then you need more unit tests. If your iterations aren't matching client expectations, then your customer rep isn't having enough face time with developers. Etc. etc.

What pure XP is trying to do here is move you towards an idealized environment. Yes, having the customer visit me 5 times a week would be great. Yes, having an open office format is great. Yes, pair programming with someone I like and respect and work well with is great. Yes, finely tuned unit tests that well-match the requirements are great. Yes, developers who are so intuitive that they know how to order their own tasks without a project manger is great.

If you have all of the above, it'll actually be difficult to fail - you'd have to work at it. You have so much going for you that you live a truly blissful developers' life.

Where XP fails is when one of those idealized pieces fails to materialize on your project. What if an end user rep can't sit with the developers constantly? Are we doomed to fail?

What if I work in a cube farm and the #$^!& company refuses to change that - will pairs fail, and thence the project?

What if many developers suck at making unit tests that truly match what the integrated final product is supposed to do? Do we fire them all and go out and get Kent?

What if a genius developer just isn't good at pairing. Do I keep him out of the project because he can't/won't pair, even if he's the best person for the job?

XP has no answers for you there. The answer is always "You're in a bad enviroment for development. Fix the environment". Well - what if I _can't_?

The answer is, of course, there are things you can do. If the customer can't/won't come to you, there are still ways to get requirements from the user's head to your developers. If your environment isn't conducive to pairs, or you don't have developers who will work well in pairs, people have somehow, through some mysterious process, managed to create some pretty good software as individuals.

And a good QA group has _always_ beat developer-written unit tests everytime.

XP is the perfect world that doesn't exist except for a few very lucky people on special projects. And the really, really funny part is - if you have such a perfect world, you'll find that you exceed whether or not you use XP. But that's little help or consolation for the vast majority of the rest of us.

<quote>
What pure XP is trying to do here is move you towards an idealized environment.
</quote>

Yes, yes ... I see the problem now.

<quote>
Yes, developers who are so intuitive that they know how to order their own tasks without a project manger is great.
</quote>

What are your talking about? XP never said anything about project managers being bad. Where did you get this from? Just one reference ...

<quote>
Where XP fails is when one of those idealized pieces fails to materialize on your project. What if an end user rep can't sit with the developers constantly? Are we doomed to fail?
</quote>

Those "idealized pieces" are far from idealized. On the contrary, they are what successful shops have been doing for ages. XP is a collection of best-practices. A collection where each principle addresses a critical aspect of the XP methodology as a whole. There is an entire chapter and even a chart in the original XP book (Extreme Programming Explained - Embrace Change, by Kent Beck) that shows how interdependent all of the priciples are in the context of the methodology. If you can't convince the decision makers in your org to implement any one of the principles for whatever reason, then you probably shouldn't even be trying any of the principles, period (excepting unit testing, continuous integration, and maybe pair programming ... but, i think that's about all that will really stand on their own).

<quote>
What if I work in a cube farm and the #$^!& company refuses to change that - will pairs fail, and thence the project?
</quote>

Do what you can. What do you want? The world on a silver platter? Then do something about it. Go convince someone it's in their interest. If not, don't be surprised if the project fails. Most do.

<quote>
What if many developers suck at making unit tests that truly match what the integrated final product is supposed to do? Do we fire them all and go out and get Kent?
</quote>

If they suck at making unit tests, they should try hard to improve. If they can't or don't want to try, I think the odds are good that they might get eventually fired and someone like Kent might come and take over. More likely, there is an entire new generation of developers coming out of school. Most of them breath .NET and Java. If they're clued in to some of the latest development methodologies, such as XP, I'd be worried. And I know a lot of them are, because they're on the XP lists doing research all the time.

<quote>
XP has no answers for you there. The answer is always "You're in a bad enviroment for development. Fix the environment". Well - what if I _can't_?
</quote>

Part of the methodology neccesitates certain environmental conditions. If you can't do it, you can't do it. That doesn't mean XP shouldn't have those requirements. XP wants projects to succeed. It doesn't care if you buy a certain CASE tool or use a certain notation or use a certain requirements tracking tool, etc. It has certain requirements, though, that I would try to follow if you really want your project to succeed.

<quote>
The answer is, of course, there are things you can do. If the customer can't/won't come to you, there are still ways to get requirements from the user's head to your developers. If your environment isn't conducive to pairs, or you don't have developers who will work well in pairs, people have somehow, through some mysterious process, managed to create some pretty good software as individuals.
</quote>

You know, you kept asking if "the project will fail." Considering most software projects do fail, I think you should seriously consider that possibility.

Honestly, how many projects have you been on that succeeded? How many failed?

XP was created to help people make projects succeed in a field where most projects fail. If you have a better idea, you should publish it. The industry and the economy needs it. And I don't think, "somehow, through some mysterious process, managed to create some pretty good software as individuals," is going to cut it.

<quote>
And a good QA group has _always_ beat developer-written unit tests everytime.
</quote>

Two different things. QA typically does functional testing, not unit testing. Developers write unit tests to both establish the semantics and structure of the code itself and to make the code more resilient to change. A successful team will have both, and do both.

<quote>
XP is the perfect world that doesn't exist except for a few very lucky people on special projects. And the really, really funny part is - if you have such a perfect world, you'll find that you exceed whether or not you use XP. But that's little help or consolation for the vast majority of the rest of us.
</quote>

That doesn't describe my experience at all, and I've been doing XP by the book for some time.

<Rollins>
What are your talking about? XP never said anything about project managers being bad. Where did you get this from? Just one reference ...
</Rollins>

Please tell me where I said "XP says project managers are bad". What I said was "developers who are so intuitive that they know how to order their own tasks without a project manger[sic]". XP doesn't mandate against project managers - but at the same time, XP does say that you can get along fine without one.

<Rollins>
Those "idealized pieces" are far from idealized. On the contrary, they are what successful shops have been doing for ages.
</Rollins>

I disagree. Many of the pieces are things we want to do - but it isn't necessarily possible in a heterogenous business environment. I'd love to have someone I work well with and pair program with them. Realistically, I'm not going to always be working with people that I click that well with. I may want to use velocity measures and the like - but the business may already have its own measurements, and not look too kindly on changing them. I may not like cubes, but I have to live with them.

<Rollins>
XP is a collection of best-practices. A collection where each principle addresses a critical aspect of the XP methodology as a whole.
</Rollins>

I don't think you can call it "best-practices". No one has shown that pair programming is a "best practice". In fact, at least half of XP is highly controversial.

<Rollins>
There is an entire chapter and even a chart in the original XP book (Extreme Programming Explained - Embrace Change, by Kent Beck) that shows how interdependent all of the priciples are in the context of the methodology. If you can't convince the decision makers in your org to implement any one of the principles for whatever reason, then you probably shouldn't even be trying any of the principles, period
</Rollins>

I agree - which is why I don't like XP. It's too fragile in the real world.

<Rollins>
(excepting unit testing, continuous integration, and maybe pair programming ... but, i think that's about all that will really stand on their own).
</Rollins>

Take out Pairs and I agree - unit testing and continuous integration is good. So are short iterations. The rest of XP is unproven and highly suspect (at least to me).

<Rollins>
Do what you can. What do you want? The world on a silver platter? Then do something about it. Go convince someone it's in their interest. If not, don't be surprised if the project fails. Most do.
</Rollins>

Sorry, but my project isn't going to fail because I can't convince management to get rid of the cube farm. In fact, many projects have succeeded in that environment. Cubes are one of many things that interfere with pair programming - which is why I say pair programming isn't very practical in the real world.

Here's a thought for you to ponder - I and my coworkers succeed in precisely the sort of environments where XP tells me (actually, almost yells at me) that we should fail.

<Rollins>
If they suck at making unit tests, they should try hard to improve. If they can't or don't want to try, I think the odds are good that they might get eventually fired and someone like Kent might come and take over. More likely, there is an entire new generation of developers coming out of school. Most of them breath .NET and Java. If they're clued in to some of the latest development methodologies, such as XP, I'd be worried. And I know a lot of them are, because they're on the XP lists doing research all the time.
</Rollins>

Here's another radical thought: seperate coding from unit test creation. In fact, put unit test creation in the hands of QA. That way, someone with zero investment in the code is doing the checks.

Unit tests are valuable - but I think it's a mistake to put them completely in the hands of the developers. In my experience, developers aren't very good at policing themselves. And that doesn't matter, because they shouldn't be expected to.

<Rollins>
Part of the methodology neccesitates certain environmental conditions. If you can't do it, you can't do it. That doesn't mean XP shouldn't have those requirements. XP wants projects to succeed. It doesn't care if you buy a certain CASE tool or use a certain notation or use a certain requirements tracking tool, etc. It has certain requirements, though, that I would try to follow if you really want your project to succeed.
</Rollins>

My point, and many other's peoples point, is that projects can succeed very well in my sort of environment. The key is to not be quite so draconian in outlook as XP is, and to not put quite so much weight and trust in the developers. That way you can succeed in a very ordinary business environment, and without the need to try to enact big changes with the help of management.

As I've said before - given XP's preconditions, anyone's going to succeed. The problem is those conditions aren't nearly as easy to achieve as XP enthusiasts like to say they are. And in the meanwhile, I've got to live with my management, still get work done, and still succeed.

<Rollins>
You know, you kept asking if "the project will fail." Considering most software projects do fail, I think you should seriously consider that possibility.

Honestly, how many projects have you been on that succeeded? How many failed?

XP was created to help people make projects succeed in a field where most projects fail. If you have a better idea, you should publish it. The industry and the economy needs it. And I don't think, "somehow, through some mysterious process, managed to create some pretty good software as individuals," is going to cut it.
</Rollins>

Well, I've been a professional developer for about 14 years. Probably 2/3 of the projects I've been in have "failed" in some major sense - ridiculously late, cancelled, etc. The reasons why have always boiled down to a few simple problems. Very well known problems - I don't really need to publish stuff people already know:

Fix those problems, which you can do quite well without using XP, and your success rate goes way up (which I saw on the 1/3 of projects which have succeeded).

So why weren't the other 2/3 projects fixed that way? Because of politics, incompetent people in key positions, wrong-headed thinking, etc. In other words, realities that normal people have to put up with in the business world. I've found ways to live with those realities, but still get transparency/integration/reality checks/short iterations. Going to XP - those realities will slap me in the head like a sledgehammer, and I will not succeed.

In a word, the XP way is naive. It's an idealist's way of thinking how software development should work, and ignores human dynamics and the realities of how businesses work.

<Rollins>
Two different things. QA typically does functional testing, not unit testing. Developers write unit tests to both establish the semantics and structure of the code itself and to make the code more resilient to change. A successful team will have both, and do both.
</Rollins>

OK - but a QA group can do unit testing as well. And QA-written unit tests will have no affinity for how the code works, only on what the requirements are. And given how often real developers refactor their code (and outright just re-write it), this is IMHO the right way to go. Developer unit tests often test too much - and often test things that are going to get nuked a month later anyway. QA written unit tests test the part that matters - the externally visible behavior. The developer can certainly write their own tests to verify their own stuff, and I encourage that, but once again I find that developer written unit tests have little value when considering the quality of an overall system as a whole.

<Mike>
Please tell me where I said "XP says project managers are bad". What I said was "developers who are so intuitive that they know how to order their own tasks without a project manger[sic]". XP doesn't mandate against project managers - but at the same time, XP does say that you can get along fine without one.
</Mike>

Sure, you can work without progect manager if it works for you. Actually, the project manager's role can be taken by developer acting as "controller" to check the schedule.

<Mike>
I disagree. Many of the pieces are things we want to do - but it isn't necessarily possible in a heterogenous business environment. I'd love to have someone I work well with and pair program with them. Realistically, I'm not going to always be working with people that I click that well with. I may want to use velocity measures and the like - but the business may already have its own measurements, and not look too kindly on changing them. I may not like cubes, but I have to live with them.
</Mike>

If you have to live with cubes - it's your choice. You can also use slow computers, work 12 hours a day etc. It's up to you. But you have to understand that you'll be working much slower/worse this way.

<Mike>
I agree - which is why I don't like XP. It's too fragile in the real world.
</Mike>

The thing is that many XP principles are also reflected in most modern software development processes. They're just driven to "extreme".

<Mike>
Sorry, but my project isn't going to fail because I can't convince management to get rid of the cube farm. In fact, many projects have succeeded in that environment. Cubes are one of many things that interfere with pair programming - which is why I say pair programming isn't very practical in the real world.
</Mike>

If your management is so dumb to do such a little thing for process improvement it's time for a job change.

<Mike>
Here's another radical thought: seperate coding from unit test creation. In fact, put unit test creation in the hands of QA. That way, someone with zero investment in the code is doing the checks.

Unit tests are valuable - but I think it's a mistake to put them completely in the hands of the developers. In my experience, developers aren't very good at policing themselves. And that doesn't matter, because they shouldn't be expected to.
</Mike>

To my mind it's not practical to make QA writing unit tests. It's simply too hard for them because they're not the people who wrote the code. Unit tests check that your code does what it's expected to. Acceptance tests can be written by QA to verify external behaviour.

<Mike>
My point, and many other's peoples point, is that projects can succeed very well in my sort of environment. The key is to not be quite so draconian in outlook as XP is, and to not put quite so much weight and trust in the developers. That way you can succeed in a very ordinary business environment, and without the need to try to enact big changes with the help of management.

As I've said before - given XP's preconditions, anyone's going to succeed. The problem is those conditions aren't nearly as easy to achieve as XP enthusiasts like to say they are. And in the meanwhile, I've got to live with my management, still get work done, and still succeed.
</Mike>

Projects can succeed in various environments. But didn't you think that you could succeed even better? You could spend less time/money, make less bugs, do exactly what customer wanted etc.

<Mike>
Well, I've been a professional developer for about 14 years. Probably 2/3 of the projects I've been in have "failed" in some major sense - ridiculously late, cancelled, etc. The reasons why have always boiled down to a few simple problems. Very well known problems - I don't really need to publish stuff people already know:

Fix those problems, which you can do quite well without using XP, and your success rate goes way up (which I saw on the 1/3 of projects which have succeeded).

So why weren't the other 2/3 projects fixed that way? Because of politics, incompetent people in key positions, wrong-headed thinking, etc. In other words, realities that normal people have to put up with in the business world. I've found ways to live with those realities, but still get transparency/integration/reality checks/short iterations. Going to XP - those realities will slap me in the head like a sledgehammer, and I will not succeed.

In a word, the XP way is naive. It's an idealist's way of thinking how software development should work, and ignores human dynamics and the realities of how businesses work.
</Mike>

Actually XP was intended to take into account real-life human needs and behaviour. When we tried to do code checks we'd found that it's hard/boring to do it often. And even if you find problem and describe it to your colleague he'll forget about the solution next day. What should we do? Fire all the people below average and recruite "super-skilled" guys? Using XP all the code checks are transparent, constant complete and, what's event more important, people learn quickly and do not repeat mistakes. And that's only one example of how XP works.

<Mike>
OK - but a QA group can do unit testing as well. And QA-written unit tests will have no affinity for how the code works, only on what the requirements are. And given how often real developers refactor their code (and outright just re-write it), this is IMHO the right way to go. Developer unit tests often test too much - and often test things that are going to get nuked a month later anyway. QA written unit tests test the part that matters - the externally visible behavior. The developer can certainly write their own tests to verify their own stuff, and I encourage that, but once again I find that developer written unit tests have little value when considering the quality of an overall system as a whole.
</Mike>

It seems to me that you don't understand the purpose of Unit testing completely (at lest, in XP). External behaviour is verified by Acceptance (functional) tests. You can throw out unit testing but if the bug is found you have to start "good old debugger" and go step-by-step to find the problem. It's really slow comparing to go through the test suite and spot the problem quickly. Another important aspect is refactoring impact - without unit testing you cannot suppose what has broken with confidence. Lack of unit tests just slows you down.
And the last (but not least) important aspect of unit testing is design influence. RUP has sequence/collaboration diagrams, XP has unit testing. You have to design before coding. Unit tests allows you to understand what classes you really need and what behaviour they should have. You don't have to predict, you need just to follow the test to make transparent, complete and simple (as much as possible) system/function.

<Maslov>
Sure, you can work without progect manager if it works for you. Actually, the project manager's role can be taken by developer acting as "controller" to check the schedule.
</Maslov>

For very small projects, yes. For anything I'd call meaningful, no.

One of the pieces that bugs me about XP is that it's advocating putting more load on the developers. Look at responses in this thread. A developer can sub for a PM. QA is a luxury, and developers can do it in a pinch. This is a "developers rule, everyone else drools mindset". It's trying to succeed on a shoe string budget.

Sometimes you have no choice but to go that route, but it should not be called a best practice or a normal course of doing business. XP rose up as a knee-jerk against over formalization, 20 pound requirements documents, and bureacratic deadlock. But again, IMHO, it knee jerked too far away from formalism into the realm of developers doing most of the work ad hoc. I'd prefer to see a well integrated team - with team not meaning just developers, but developers, PM, QA people.

<Maslov>
If you have to live with cubes - it's your choice. You can also use slow computers, work 12 hours a day etc. It's up to you. But you have to understand that you'll be working much slower/worse this way.
</Maslov>

I work in NYC. Space is tight, space is expensive. Cubes are a business reality. It's not a question of choice on my part - I cannot realistically choose a non-cube environment, because I'd be cutting my employment opportunites down to almost nothing.

<Mike>
I agree - which is why I don't like XP. It's too fragile in the real world.
</Mike>

<Maslov>
The thing is that many XP principles are also reflected in most modern software development processes. They're just driven to "extreme".
</Maslov>

I agree, and I go further say that extremness makes the whole thing too fragile. There are too many pre-reqs. I find it especially silly when I can just do short iterations/unit testing/high transparency/constant integration and get the same effect without the pre-reqs.

<Mike>
Sorry, but my project isn't going to fail because I can't convince management to get rid of the cube farm. In fact, many projects have succeeded in that environment. Cubes are one of many things that interfere with pair programming - which is why I say pair programming isn't very practical in the real world.
</Mike>

<Maslov>
If your management is so dumb to do such a little thing for process improvement it's time for a job change.
</Maslov>

My management isn't dumb. It's trying to maximum its investment in office space that costs $50 sqft, with zero possibility of getting more space. This is the norm in NYC. To eliminate cubes would mean each person takes up more sqft, which would mean some people would have to get fired.

<Maslov>
To my mind it's not practical to make QA writing unit tests. It's simply too hard for them because they're not the people who wrote the code. Unit tests check that your code does what it's expected to. Acceptance tests can be written by QA to verify external behaviour.
</Maslov>

That's developer arrogance and ego talking. If a decent QA person can't write a unit test for your code, then that says something about your code. This is why I don't like developers writing tests that are supposed to be meaningful to management or to indicate overall quality. It's self-policing and lacks transparency. Yes, there's no code ownership, and developers are free to roam the code base, but too much is kept tightly within the development group alone. I prefer a much more open area where the guy writing the code is not the guy writing the test for that same code.

<Maslov>
Projects can succeed in various environments. But didn't you think that you could succeed even better? You could spend less time/money, make less bugs, do exactly what customer wanted etc.
</Maslov>

Yes, that would be great. And no, XP isn't the way to achieve it (been there, done that).

<Maslov>
Actually XP was intended to take into account real-life human needs and behaviour.
</Maslov>

No, it's not. XP is intended to give small projects with rapid requirements change a chance to succeed. IMHO it sacrifices the human side to get there.

<Maslov>
When we tried to do code checks we'd found that it's hard/boring to do it often. And even if you find problem and describe it to your colleague he'll forget about the solution next day.
</Maslov>

Committees and meetings doing "code reviews" are boring and wasteful. Instead, the technical leader or leaders should do informal reviews on a regular basis. It's very simple - you peruse the checked-in code, do diffs to see what's changing, talk to the developers to get in their head. And it's important that the technical leaders do it so their opinions have some weight.

<Maslov>
What should we do? Fire all the people below average and recruite "super-skilled" guys? Using XP all the code checks are transparent, constant complete and, what's event more important, people learn quickly and do not repeat mistakes. And that's only one example of how XP works.
</Maslov>

You get the same effect doing peer programming. And you get the added bonus that it's much easier to track individual developement. Peer programming doesn't mean that people can't work together, it just means you don't have to join people slavishly at the hip.

<Maslov>
It seems to me that you don't understand the purpose of Unit testing completely (at lest, in XP). External behaviour is verified by Acceptance (functional) tests. You can throw out unit testing but if the bug is found you have to start "good old debugger" and go step-by-step to find the problem. It's really slow comparing to go through the test suite and spot the problem quickly. Another important aspect is refactoring impact - without unit testing you cannot suppose what has broken with confidence. Lack of unit tests just slows you down.
And the last (but not least) important aspect of unit testing is design influence. RUP has sequence/collaboration diagrams, XP has unit testing. You have to design before coding. Unit tests allows you to understand what classes you really need and what behaviour they should have. You don't have to predict, you need just to follow the test to make transparent, complete and simple (as much as possible) system/function.
</Maslov>

I understand unit tests, and their role in XP. But just becuase XP advocates doing it a certain way to achieve a certain effect doesn't mean it's the only way. Just because Beck and Fowler et al come up with certain definitions of unit tests and refactoring doesn't mean that their words are definitive. As a software professional, and I see what other people are doing and I pick out what I think is good and adapt it to my needs. In the case of unit tests, my approach looks a bit like XPs from 10,000 feet, but as you drill down you find differences. The differences are my adaptations to my own environment and based on my own experiences.

To me this is the only sane way to work, because the "experts" change their minds every couple of years. If you doubt this, pick up first editions of methodology & analysis books from the early 80s, late 80s, early 90s, and late 90s, and see how they've changed. Even with a single given author, you'll see radical changes as the years go by. And I fully expect that 5 years from now the experts will once again re-write their books and much of what we're arguing now will be a moot point. But I'll keep on trucking because I don't slavishly buy into consultant methodologies whole hog, but use my own judgement.

<Mike Spille>
One of the pieces that bugs me about XP is that it's advocating putting more load on the developers. Look at responses in this thread. A developer can sub for a PM. QA is a luxury, and developers can do it in a pinch. This is a "developers rule, everyone else drools mindset". It's trying to succeed on a shoe string budget.
</Mike Spille>

The idea is that we give them the highest quality code we can, and using XP the code generally has been a higher quality than it was before we adopted XP.

This means we spend less time on the same code as well. Since QA kicks back fewer errors. The only way we "minimize" QA is that we have fewer corrections to code that we have to make. I've never seen anything that suggests QA isn't necessary.

We also have a team manager that keeps us on track. Now, I admit, trying to keep a team of developers on track is like herding a back of chimps sometimes, but that's also why you can't just toss a team leader, and I've never seen that advocated as well.

What XP does advocate is that developers work as peers. No primadonnas and no rookies. Everyone is part of the team and knowledge is shared so that over time everyone's skill levels will be on par with each other. That doesn't mean you get rid of the guy running the show.

What XP also advocates is a process that reduces minor errors, which can sometimes result in major problems, so that you spend more time writing code that works rather than writing code you have to go back and debug. Thus the QA process is simplified, but it is not rendered irrelevant or unnecessary.

<Mike Spille>
I'd prefer to see a well integrated team - with team not meaning just developers, but developers, PM, QA people.
</Mike Spille>

That's exactly what we have. In fact, this is one of the few offices I've seen where developers and QA did not have a hostile relationship with each other. There is a seperate QA team, but we work very closely with them and their work is intertwined with ours. There is a layer of management that keeps things moving and coordinated. These things are not absent just because we're in an XP environment. In fact, they are still essential.

Again, the idea is efficiency and productivity. Those are the goals. Eliminating processes like QA would not achieve these goals and are contrary to what XP advocates.

<Mike Spille>
I work in NYC. Space is tight, space is expensive. Cubes are a business reality. It's not a question of choice on my part - I cannot realistically choose a non-cube environment, because I'd be cutting my employment opportunites down to almost nothing.
</Mike Spille>

So does that mean you cannot try ANY of the XP concepts? Or you could get rid of the cubes altogether and make it a shared space. We tried that, it worked. In fact, our current system is not so great because our current space is not as open as our old one. Although the move was forced since our old work area was like Grand Central Station.

You've got to quit thinking inside the box, or cube, in this case. Cubicles only give the illusion of privacy. I came to this company from one where I had my own office. Working totally out in the open was originally unnerving, but in the end I got to like it quite a bit. I'm a private person by nature, but being forced to *gasp* interact with my co-workers went a long way towards making us a better team.

If cube space is a problem, then get rid of the cubes! I know it sounds radical, but you may be surprised at the results.

And if that's still too much, that doesn't mean everything else about XP is bad or won't work. What about the unit tests, requirements gathering, etc.? Much of XP is centered around improving communications with the "customer" as well and achieving more realistic deadlines and requirements. It's not all about the developers.

<Mike Spille>
My management isn't dumb. It's trying to maximum its investment in office space that costs $50 sqft, with zero possibility of getting more space. This is the norm in NYC. To eliminate cubes would mean each person takes up more sqft, which would mean some people would have to get fired.
</Mike Spille>

I'm not sure how eliminating walls increases the space taken by the team, unless you're talking about sectioning off a special area just for pairing up. In which case, I do understand. However, just so we're clear, I'm referring to giving everyone their own work area that might be more easily accessible than having to squeeze into three and a half fake walls. Cubicles are not a necessity, and I certainly don't see how they save space. All I really need is my desk. The walls give me an illusion of privacy that doesn't really exist.

Our QA guys are not Java developers. If I threw Java source code at them they wouldn't know it from Greek. Unit tests ensure the code performs in the way you expect it. QA makes sure the code performs to an acceptable level. What is so hard to understand about that? It's one thing to THINK your code is going to do something, an entirely different matter to prove it first.

How is it arrogance to make sure you code performs as you expect it to? Unit testing is based on the reality that no one is perfect and even the best programmer can make a stupid ytpo.

<Mike Spille>
Peer programming doesn't mean that people can't work together, it just means you don't have to join people slavishly at the hip.
</Mike Spille>

In reality, people here aren't joined slavishly at the hip. That doesn't mean you have to throw out pair programming all together. The reality is, not every office has the luxury of letting two people work on a project all the time. We still have management that thinks "5 developers == 5 ongoing projects". However, we are slowly changing that perception. Even if we're only realistically increasing our productivity by 10%, even if it's not a significant gain (and I don't know if it is or not, I just know we get stuff done faster and with fewer errors than before) I'll still take what I can get. I'll take a small gain over nothing.

<Mike Spille>
But I'll keep on trucking because I don't slavishly buy into consultant methodologies whole hog, but use my own judgement.
</Mike Spille>

Which is your right, but it seems silly to write off XP as useless altogether just because it doesn't mesh with your personal way of doing things. You've made a lot of noise about developer arrogance, but at the same time talk alot about what "you know". I'm not trying to be insulting, just pointing out that you are pretty dead set on relying on your own understanding.

I can understand being wary of "the experts", but I like to keep my options open. Maybe XP isn't right for your office, I can respect that. At the same time, just because it doesn't work for you doesn't mean its worthless either.

<Mike>
I agree, and I go further say that extremness makes the whole thing too fragile. There are too many pre-reqs. I find it especially silly when I can just do short iterations/unit testing/high transparency/constant integration and get the same effect without the pre-reqs.
</Mike>

Those pre-requisites are appliable to most modern software development processes. The same things you can find in RUP, FDD, <name it yourself>... The difference is that XP clearly defines required things while another processes (like RUP) try to hide their complexity behind marketing claims like "you can take only what you need and throw out the rest". This usually leads to throwing out really important things due to "lack of necessity" and project failure.
Software development is really complex thing. Programs are harder and harder to write. They're like custom skyscrapers - each customer needs it's own. And XP just reflects and overcomes this complexity owing to it's practices.
Look carefully: you'll find the same things in RUP, for instance. And in many other processes.
But I'm sure that yours is the best :)

<Mike>
That's developer arrogance and ego talking. If a decent QA person can't write a unit test for your code, then that says something about your code. This is why I don't like developers writing tests that are supposed to be meaningful to management or to indicate overall quality. It's self-policing and lacks transparency. Yes, there's no code ownership, and developers are free to roam the code base, but too much is kept tightly within the development group alone. I prefer a much more open area where the guy writing the code is not the guy writing the test for that same code.
</Mike>

Not at all. It's stupid and selfish to pass unit testing to QA. They cannot handle with it not because the code is bad but because they usually don't have the expertise required: it's pretty hard for non-Java developers to write unit tests for code written by another person.
Actually it would be really simple for me to shift problems with my code to QA and say: "I'm done". Unit tests assure certain level of quality before functional testing.

<Mike>
Committees and meetings doing "code reviews" are boring and wasteful. Instead, the technical leader or leaders should do informal reviews on a regular basis. It's very simple - you peruse the checked-in code, do diffs to see what's changing, talk to the developers to get in their head. And it's important that the technical leaders do it so their opinions have some weight.
</Mike>

Have you tried it yourself? We've tried. Didn't work for us. I'd been working for a large company and we had a rule that lead developers had to check the code and design of their team-mates. Each time during and after check most lead guys had been really angry: the code was bad each time (more or less), and what's even more important - they had to loose a lot of time to understand what was wrong, to find the solution, to explain it to developer. They could do the work themselves for this period of time. And next time the same problem could easily appear again (and it did as junior people just couldn't memorize all the important things and pattern at once). We'd been doing it for three or four month and then the management cancelled this requirement: it took a lot of time without visible results.
Now we do PP and the whole thing about code reviews is like a nightmare for me: I hope it'll never happen again.

<Mike>
I understand unit tests, and their role in XP. But just becuase XP advocates doing it a certain way to achieve a certain effect doesn't mean it's the only way. Just because Beck and Fowler et al come up with certain definitions of unit tests and refactoring doesn't mean that their words are definitive. As a software professional, and I see what other people are doing and I pick out what I think is good and adapt it to my needs. In the case of unit tests, my approach looks a bit like XPs from 10,000 feet, but as you drill down you find differences. The differences are my adaptations to my own environment and based on my own experiences.

To me this is the only sane way to work, because the "experts" change their minds every couple of years. If you doubt this, pick up first editions of methodology & analysis books from the early 80s, late 80s, early 90s, and late 90s, and see how they've changed. Even with a single given author, you'll see radical changes as the years go by. And I fully expect that 5 years from now the experts will once again re-write their books and much of what we're arguing now will be a moot point. But I'll keep on trucking because I don't slavishly buy into consultant methodologies whole hog, but use my own judgement.
</Mike>

Yes, you're right. The technologies and methodologies are changing (improving all the time). You can stay were you're or you can try "running for the train" like most developers do or at least trying to. It's a specific industry and we have to learn quickly and adopt the best practices/technologies/approaches. I'm not saying about dumb implementation of "another known-all's inventions". You have your own brain. Try to be open-minded, try to understand it, pass it through your perception instead of throwing thing away just because you think that it's bad from the beginning. You can loose a lot with such approach.
There's a saying: "Wise man studies at another person's faults, stupid man studies at his own". I think that the most appropriate way is to learn as more as you can about different things, understand them and then choose. I consider Beck, Fawler, Booch, Oberg smart people. Definetly smarter than me :). So it's better to take the best they can give me to become better, more productive and happy developer.

<Maslov>
Those pre-requisites are appliable to most modern software development processes. The same things you can find in RUP, FDD, <name it yourself>... The difference is that XP clearly defines required things while another processes (like RUP) try to hide their complexity behind marketing claims like "you can take only what you need and throw out the rest". This usually leads to throwing out really important things due to "lack of necessity" and project failure.
</Maslov>

There's alot of truth to that statement, but for many developer's it's not very applicable. The reason why is that few development teams adopt a "pure" methodology whole hog. The good teams pick and choose pieces of things that they like, and generally do well. The bad teams also pick and choose - but end up focusing on the wrong bits. And in my experience, they'd do just as bad if they tried something "pure".

Personally I don't do pure RUP, or pure Agile, or pure XP, or pure anything. I've been in the game long enough to see what's worked best on projects I've been on, and on each new project I look for new ideas that can make it even better. But I'd never throw away all of my experience, trust Beck (or whoever) to get everything 100% right, and blindly try their way. Perhaps there are organizations that can afford to throw away a million bucks (or whatever) by trying a radical new way of development. But most will try refinement and gradual process improvements.

<Maslov>
Software development is really complex thing. Programs are harder and harder to write. They're like custom skyscrapers - each customer needs it's own. And XP just reflects and overcomes this complexity owing to it's practices.
Look carefully: you'll find the same things in RUP, for instance. And in many other processes.
But I'm sure that yours is the best :)
</Maslov>

I disagree with your assertion here. Programs are no harder to write than they used to be. I used to write C and assembly on for IT middleware, on "high end" machines running at 20MHz with 8MB of RAM. Now I'm writing IT middleware with a massive J2EE infrastructure around me, 4 800Mhz processors on the box, with 8GB of RAM (and 100-Mbit TCP/IP). I do the same physical amount of work I used to, but I'm delivering alot more value.

As for mine being the best - I have no 100% fixed methodology. There are certain things I promote on every project I'm on, certainly - but at the same time, I adapt to my environment.

<Maslov>
Not at all. It's stupid and selfish to pass unit testing to QA. They cannot handle with it not because the code is bad but because they usually don't have the expertise required: it's pretty hard for non-Java developers to write unit tests for code written by another person.
</Maslov>

Not all unit testing should be passed on to QA, but at the same time developers shouldn't have to be responsible for all unit tests. Certain unit tests should be written by QA because they're not close to the code. As for the expertise question - I don't think you should hire QA people who have zero programming knowledge. It limits their effectiveness way too much. No I recognize you can't always pick and choose who your QA people are, but when I have my druthers I go for QA people who can also do some development.

<Maslov>
Actually it would be really simple for me to shift problems with my code to QA and say: "I'm done". Unit tests assure certain level of quality before functional testing.
</Maslov>

You make it sound morally wrong to shift some burden onto QA. I don't think it is. A developer's job is difficult enough - enough so that I don't think we should keep adding to it (OK, Joe, now you're a developer, QA person, and PM - hae fun!). As I've mentioned before, developers can and should do unit tests, but they can't be accepted as the be-all, end-all. It's self-policing, which doesn't work. The value of tests not written by the developers is that the PM and management can have a higher confidence level in where the project's at. A fundamental truth is that everyone take's what developers claim with a big grain of salt. Until someone else has tested the code, you can't make too many assumptions. In some circles this is called "verification". You can't verify yourself.

<Maslov>
Have you tried it yourself?
</Maslov>

Yes, with great success on very many projects.

<Maslov>
We've tried. Didn't work for us. I'd been working for a large company and we had a rule that lead developers had to check the code and design of their team-mates. Each time during and after check most lead guys had been really angry: the code was bad each time (more or less), and what's even more important - they had to loose a lot of time to understand what was wrong, to find the solution, to explain it to developer. They could do the work themselves for this period of time.
</Maslov>

How long were the periods between checks? You make it sound like long stretches (other wise it wouldn't take so long). The idea is to casually check the code two, three times a week. If there's a problem, you talk to the person involved and work out a better way it should be done. This requires some patience on the part of the leaders, and I agree it's not for everyone.

But in my view - you shouldn't be called a "leader" if you can't do casual code review and help fix the problem.

<Maslov>
And next time the same problem could easily appear again (and it did as junior people just couldn't memorize all the important things and pattern at once). We'd been doing it for three or four month and then the management cancelled this requirement: it took a lot of time without visible results.
</Maslov>

If you ran into these kinds of problems, it sounds to me like you have the junior people in over their heads.

<Maslov>
Now we do PP and the whole thing about code reviews is like a nightmare for me: I hope it'll never happen again.
</Maslov>

I'm glad it worked out for you, but I have to wonder. In the XP experiements I've seen, particularly with junior people involved sort of like you described above, the end result of pair programming is that the junior people largely coast on the tails of the senior ones. Worse - some of them don't coast, they honestly try to do their share, but are overriden by the senior person in the pair.

In this sort of scenario - yeah, your quality goes up. It goes up because your best people are doing the bulk of the work, and the worst people are effectively pushed out. This isn't synergistic pairing where two good guys are becoming better than the sum of the parts. Instead, you're damping down the effect of the worst people.

In my experience - and it may not match yours - people need to go at certain things alone or they will not learn. This doesn't mean you let 'em run without a net. That's what the casual code reviews are for. You let people try on their own, and (gently) correct their mistakes after they've made them.

<Maslov>
There's a saying: "Wise man studies at another person's faults, stupid man studies at his own". I think that the most appropriate way is to learn as more as you can about different things, understand them and then choose. I consider Beck, Fawler, Booch, Oberg smart people. Definetly smarter than me :). So it's better to take the best they can give me to become better, more productive and happy developer.
</Maslov>

I agree, except for the last bit about Beck et al. First, context is really important. Beck's projects differ radically from mine in a number of ways (industry, scope, and technology). The same is true of Fowler, Booch et al.

Second - all of these people you've quoted are consultants and people who sell books. Whether you realize it or not, they're not your buddy down the hall trying to help you out. They're trying to get you to buy their book(s), and buy their consulting services.

And the third part - many methodology preachers don't actually practice what they preach. Buy into their services, and then see how they act on a day to day basis vs. their published methodology. It's surprising to see the differences between the idealized mantras, and someone getting paid a high consulting fee to deliver a real project.

<Mike>
There's alot of truth to that statement, but for many developer's it's not very applicable. The reason why is that few development teams adopt a "pure" methodology whole hog. The good teams pick and choose pieces of things that they like, and generally do well. The bad teams also pick and choose - but end up focusing on the wrong bits. And in my experience, they'd do just as bad if they tried something "pure".

Personally I don't do pure RUP, or pure Agile, or pure XP, or pure anything. I've been in the game long enough to see what's worked best on projects I've been on, and on each new project I look for new ideas that can make it even better. But I'd never throw away all of my experience, trust Beck (or whoever) to get everything 100% right, and blindly try their way. Perhaps there are organizations that can afford to throw away a million bucks (or whatever) by trying a radical new way of development. But most will try refinement and gradual process improvements.
</Mike>

No methodology or process says that you have to do "pure everything". But most of them are focused on certain key practices you have to do or you'll make the whole thing uneffective.
I think that it's important to have an established and sound development process. Every developer has its own preferences and advantages. Everyone can tell you that he knows better what to do. Sure, if you're the big boss you can tell your people: "Do as I say". But then you have to "say" first all the things you expect from them. It is not so simple. First, you have to define the whole process for yourself and be prepared for the "holy war" where you should win from pragmatic and technical side. You cannot just say: "I'm the chief and I know better". People should trust in your process or everything's going to fail.
I know that because I had to convince people of XP and it was really hard. Every programmer knows somewhere inside that he's doing almost everything right. The bad results are usually:
- damn customers that don't know what they want
- stupid management which makes us do silly things
- lazy neighbour developers that just don't want to learn
- bad managers that make plans for "marketing" not for production
etc.

<Mike>
I disagree with your assertion here. Programs are no harder to write than they used to be. I used to write C and assembly on for IT middleware, on "high end" machines running at 20MHz with 8MB of RAM. Now I'm writing IT middleware with a massive J2EE infrastructure around me, 4 800Mhz processors on the box, with 8GB of RAM (and 100-Mbit TCP/IP). I do the same physical amount of work I used to, but I'm delivering alot more value.
</Mike>

I agree that physical amount of work is the same. You have the same amount of time and maybe even the number of keys pressed is comparable.
But I can hardly compare assembler development with distributed systems. It just different level of complexity: coding complexity vs architectural complexity.
I agree that to code the distributed brokerage system is not more complex than to write editor in C. But there are a lot of important issues in the first scenario you have to deal with: distribution, concurrency, system loads etc. This is where design and architecture solutions come to play.

<Mike>
As for mine being the best - I have no 100% fixed methodology. There are certain things I promote on every project I'm on, certainly - but at the same time, I adapt to my environment.
</Mike>

This is how most developers do. They use some things that helped them during the past and fight with the rest of the problems project-to-project.

<Mike>
Not all unit testing should be passed on to QA, but at the same time developers shouldn't have to be responsible for all unit tests. Certain unit tests should be written by QA because they're not close to the code. As for the expertise question - I don't think you should hire QA people who have zero programming knowledge. It limits their effectiveness way too much. No I recognize you can't always pick and choose who your QA people are, but when I have my druthers I go for QA people who can also do some development.

You make it sound morally wrong to shift some burden onto QA. I don't think it is. A developer's job is difficult enough - enough so that I don't think we should keep adding to it (OK, Joe, now you're a developer, QA person, and PM - hae fun!). As I've mentioned before, developers can and should do unit tests, but they can't be accepted as the be-all, end-all. It's self-policing, which doesn't work. The value of tests not written by the developers is that the PM and management can have a higher confidence level in where the project's at. A fundamental truth is that everyone take's what developers claim with a big grain of salt. Until someone else has tested the code, you can't make too many assumptions. In some circles this is called "verification". You can't verify yourself.
</Mike>

You simply don't understand (or don't want to?) my point of view.
First, all my code have to go through acceptance tests. These are written by QA team (using some script language) and test the whole function. They test the front-end. I cannot say that delivered functionality works if it doesn't pass acceptance test. Unit tests is a first check level, acceptance tests is the second.
Second, QA guys are not Java-developers. If they were they'd probably wouldn't work at QA department. As far as I know most QA people would like to be developers but not testers. It's a life. Many people think that developers are paid better and their work is more interesting than writing tests each day. We have to deal with this fact in some way. We have to give QA people easy and friendly yet robust tools. Personally I prefer some script-based things.

<Maslov>
We've tried. Didn't work for us. I'd been working for a large company and we had a rule that lead developers had to check the code and design of their team-mates. Each time during and after check most lead guys had been really angry: the code was bad each time (more or less), and what's even more important - they had to loose a lot of time to understand what was wrong, to find the solution, to explain it to developer. They could do the work themselves for this period of time.
</Maslov>

<Mike>
How long were the periods between checks? You make it sound like long stretches (other wise it wouldn't take so long). The idea is to casually check the code two, three times a week. If there's a problem, you talk to the person involved and work out a better way it should be done. This requires some patience on the part of the leaders, and I agree it's not for everyone.

But in my view - you shouldn't be called a "leader" if you can't do casual code review and help fix the problem.
</Mike>

The checks were performed two times a week. But to help fix the problem I have to:
1) understand idea of that "ugly" design;
2) propose better solution;
3) explain it to developer.

It just takes too much leader's time.

<Mike>
I'm glad it worked out for you, but I have to wonder. In the XP experiements I've seen, particularly with junior people involved sort of like you described above, the end result of pair programming is that the junior people largely coast on the tails of the senior ones. Worse - some of them don't coast, they honestly try to do their share, but are overriden by the senior person in the pair.

In this sort of scenario - yeah, your quality goes up. It goes up because your best people are doing the bulk of the work, and the worst people are effectively pushed out. This isn't synergistic pairing where two good guys are becoming better than the sum of the parts. Instead, you're damping down the effect of the worst people.

In my experience - and it may not match yours - people need to go at certain things alone or they will not learn. This doesn't mean you let 'em run without a net. That's what the casual code reviews are for. You let people try on their own, and (gently) correct their mistakes after they've made them.
</Mike>

I'm glad that you can hire best people in industry. And all of them have the same level of knowledge. And they're willing to learn all the time.
As for my experience, always there's some kind of "impedance mismatch" in the team. Some people know more, some know less. Some people read all the weekend, some go into sports. Some people know J2EE, some are Swing experts. But all of them are good developers. Nobody can know everyhing: there are a lot of technologies, patterns, approaches to learn. It's simply impossible (know it for myself :) ).
You just have to find a way to share experience, to make people understand themselves.
I think this is the point.

<Mike>
I agree, except for the last bit about Beck et al. First, context is really important. Beck's projects differ radically from mine in a number of ways (industry, scope, and technology). The same is true of Fowler, Booch et al.

Second - all of these people you've quoted are consultants and people who sell books. Whether you realize it or not, they're not your buddy down the hall trying to help you out. They're trying to get you to buy their book(s), and buy their consulting services.

And the third part - many methodology preachers don't actually practice what they preach. Buy into their services, and then see how they act on a day to day basis vs. their published methodology. It's surprising to see the differences between the idealized mantras, and someone getting paid a high consulting fee to deliver a real project.
</Mike>

I don't follow their advices blindly. It was pretty hard to convince management of going XP-way. Some practices we have been using for long time (refactoring, short builds, collective code ownership) but some were too frightening (Test-First Design, PP, Customer on site).
We've decided to apply practices one-by-one for single pair of developers. It worked. After that the management was confident and we had a "green light".

<Maslov>
You cannot just say: "I'm the chief and I know better". People should trust in your process or everything's going to fail.
I know that because I had to convince people of XP and it was really hard. Every programmer knows somewhere inside that he's doing almost everything right. The bad results are usually:
- damn customers that don't know what they want
- stupid management which makes us do silly things
- lazy neighbour developers that just don't want to learn
- bad managers that make plans for "marketing" not for production
etc.
</Maslov>

One of the reasons I don't like XP is that it's excessively hard to convince people to try it (and for good reason :-).

That said - every project still needs leaders. Not everything can be driven from consensus. Sometimes someone with authority and accountability has to say "I understand your concerns, but this is how it's gotta be".

<Maslov>
But I can hardly compare assembler development with distributed systems. It just different level of complexity: coding complexity vs architectural complexity.
I agree that to code the distributed brokerage system is not more complex than to write editor in C. But there are a lot of important issues in the first scenario you have to deal with: distribution, concurrency, system loads etc. This is where design and architecture solutions come to play.
</Maslov>

No, this is to me the fallacy of "software architecture". There is no conceptual difference between writing complex assembly code and writing complex distributed systems. The difference is (as always) where your resource costs and error points are. A distributed system is just like a self-contained process, except that method calls can fail due to network problems, calls are often more expensive, and there are more failover points, and the scaling characteristics are different.

My point is that imagine you had to do the J2EE style apps you're doing now - using assembly, 20MHz processors and 8MB of RAM.

The languages and tools have made things that used to be hard easy, and so we compensate by doing more complex things. But given the advances of the languages/tools, the complexity visible to me, the developer, isn't any different from the complexity I dealt with 10 years ago. I'm simply getting more bang for my buck.

<Maslov>
You simply don't understand (or don't want to?) my point of view.
First, all my code have to go through acceptance tests. These are written by QA team (using some script language) and test the whole function. They test the front-end. I cannot say that delivered functionality works if it doesn't pass acceptance test. Unit tests is a first check level, acceptance tests is the second.
Second, QA guys are not Java-developers. If they were they'd probably wouldn't work at QA department. As far as I know most QA people would like to be developers but not testers. It's a life. Many people think that developers are paid better and their work is more interesting than writing tests each day. We have to deal with this fact in some way. We have to give QA people easy and friendly yet robust tools. Personally I prefer some script-based things.
</Maslov>

OK, so we have radically different ideas of QA (and QA people). I understand your view - but please accept that people-writing-QA-acceptance-scripts is not the only valid view of QA. Think of working with QA guys with more programming knowledge, and what that can give you on a project overall....

<Maslov>
The checks were performed two times a week. But to help fix the problem I have to:
1) understand idea of that "ugly" design;
2) propose better solution;
3) explain it to developer.

It just takes too much leader's time.
</Maslov>

To be a bit trite, that's the cost of doing business. The most senior developers on a project need to track progress and quality, all the way down to the code level. No, they can't check everything, so you check the big chunks that get checked in that are critical to success. And it will take time to do those checks, and more time to help people fix ugly/broken/hopeless code. But it helps everyone in the long run.

And doing pairs does not get around the above. Despite what XP says, pairs can check in crappy code. People practicing pair programming without informal code reviews are walking the high wire at 1,000 feet without a net.

<Mike>
In my experience - and it may not match yours - people need to go at certain things alone or they will not learn. This doesn't mean you let 'em run without a net. That's what the casual code reviews are for. You let people try on their own, and (gently) correct their mistakes after they've made them.
</Mike>
<Maslov>
I'm glad that you can hire best people in industry. And all of them have the same level of knowledge. And they're willing to learn all the time.
As for my experience, always there's some kind of "impedance mismatch" in the team. Some people know more, some know less. Some people read all the weekend, some go into sports. Some people know J2EE, some are Swing experts. But all of them are good developers. Nobody can know everyhing: there are a lot of technologies, patterns, approaches to learn. It's simply impossible (know it for myself :) ).
You just have to find a way to share experience, to make people understand themselves.
I think this is the point.
</Maslov>

I don't know where the above came from - my point is that teams are made of wildly different people. Not all of them will be good developers. Some will (frankly) suck. Some will be stars. Some will be blazing fast, some slow.

I let people work at their own speed in their own way, and use tools like casual code reviews to monitor what they're doing but not get in their way (unless they start checking in bad code).

In contrast, with pair programming people's differences are constantly in each other's faces. And I think that's bad for everyone concerned.

<Maslov>
I don't follow their advices blindly. It was pretty hard to convince management of going XP-way. Some practices we have been using for long time (refactoring, short builds, collective code ownership) but some were too frightening (Test-First Design, PP, Customer on site).
We've decided to apply practices one-by-one for single pair of developers. It worked. After that the management was confident and we had a "green light".
</Maslov>

You extrapolated XP's effectiveness from a single pair of developers? I hope I'm misreading you....

<quote>And a good QA group has _always_ beat developer-written unit tests everytime.</quote>

Objection. They do different things and are therefore incomparable. Programmers write Programmer Tests. QA folks run Integration and Customer Tests. PTs are meant to give the programmer minute-to-minute feedback and help him make progress. ITs prove that the system hangs together. CTs prove that the system solves a business problem.

<quote>
XP is the perfect world that doesn't exist except for a few very lucky people on special projects. And the really, really funny part is - if you have such a perfect world, you'll find that you exceed whether or not you use XP. But that's little help or consolation for the vast majority of the rest of us.
</quote>

Disagree. Sufficiently malicious and/or stupid people can even mess up Eden.

I WANT the ideal environment. Why wouldn't I? If I don't have it, then I fight for it. I get as far as I can. If you wish to settle for a crappy or middling environment, then that's great. I want the prize.

I WANT the ideal environment. Why wouldn't I? If I don't have it, then I fight for it. I get as far as I can. If you wish to settle for a crappy or middling environment, then that's great. I want the prize.
</Rainsberger>

Some spend their life cursing the inequitites of the universe, bemoaning what could be "only if...".

The rest recongize that the universe is imperfect, and struggle on as best we can.

I do not "settle" for a crappy or middling environment. I try to improve things where I can. But there is a point where you must shit or get off the pot. You either recognize that things are as good as they're going to get, and do what you can to succeed, or you keep pushing against the immovable object and go no where.

In the processes that I follow, they certainly work best in an ideal world. But they also work in a middling environment. I don't like XP whole-hog because it's plainly geared to succeed _only_ in the ideal environment - and several people in this thread have outright said so. And I'm not going to go to my manager and say "sorry, we've got cubes - we're all doomed".

I know that this probably falls into the category of ad hominem, so I hope you're wearing the alleged anti-ad-hominem suit.
I have never --EVER-- seen anybody have the gall to post 10 --COUNT 'EM, TEN-- messages in a row to a message board; not just this board, but ANY message board.

I just don't know what to say here... I don't have the time to read all of your thoughts... could you please post an 11th time with a summary in 2 paragraphs or less?!?!?

I'm sorry, Mr. Ellison. I forgot to give you your summary. You asked nicely, so here it goes.

Paragraph 1:
XP doesn't work for everyone. That should be no surprise, since nothing does, except possibly breathing (and even some people have problems with that). XP has worked for me. I'm sorry that not everyone agrees with my experience or opinion. I'm glad that some do. If you don't like XP, go do something else and let the XP community wallow in its apparent madness. I don't walk around slamming the folks doing Waterfall, even though I sometimes wonder what they're thinking. Since I fundamentally disagree with them and nothing they say can convince me that they're right, I agree to disagree and leave them alone.

Paragraph 2:
Either debate the actual topic of discussion or go away. Please, or next time I'll post 100 messages in a row.

<quote>And a good QA group has _always_ beat developer-written unit tests everytime.</quote>

<Rainsberger>
Objection. They do different things and are therefore incomparable. Programmers write Programmer Tests. QA folks run Integration and Customer Tests. PTs are meant to give the programmer minute-to-minute feedback and help him make progress. ITs prove that the system hangs together. CTs prove that the system solves a business problem.
</Rainsberger>

I understand your objection, but I believe we're talking to different points. When a developer codes and runs his unit tests and declares "success!", nobody jumps up and down and gets the champagne. This is because a developer's idea of success rarely matches what's needed by the project. This isn't bad - it's just the nature of developers.

This is why we have tested beyond developer's unit tests. Because it's not done when the developer says it's done. That's my point - unit tests are good, but they don't tell the PM or the customer _anything_ about whether the whole thing will work for their needs.

To clarify - I'm not down on developer's writing unit tests. It's a good thing - but a good thing on a small scale. In a pinch, given a choice between chucking unit tests and chucking your QA group, which would you choose?

<quote>
XP is the perfect world that doesn't exist except for a few very lucky people on special projects. And the really, really funny part is - if you have such a perfect world, you'll find that you exceed whether or not you use XP. But that's little help or consolation for the vast majority of the rest of us.
</quote>

<Rainsberger>
Disagree. Sufficiently malicious and/or stupid people can even mess up Eden.
</Rainsberger>

Agreed. At the same time, do you concede that not all approaches are equally robust in the real world?

I've been doing it for 5+ months. I believe Ron Jefferies was mentioned in this thread.

"I've really changed position on this. I think maybe concentration is the enemy. Seriously. If you're working on something that is so complex that you actually need to concentrate, there's too much chance that it's too hard."

Now come to find out after 5 months I've been doing it all wrong. I was concentrating. Let's see, if not concentrating is good, then why don't we not concentrate ALL THE TIME! It's extreme, but it makes sense. I fully support XP and especially these particular words of wisdom from one of the founding fathers.

By the way, did any of you folks see the super bowl commercial where they had the football player tackling non-productive office workers? I was wondering if we could add that as one of the XP practices. Image, pair or get tackled. That will really improve productivity.

And who is doing the junior participants work? Are they both doing everything together. Didn't the software world come up with patterns to address this specific point of division of labor.

I would have to disagree that they will accomplish both objectives as quickly working together on both items. What value does the junior bring trying to solve the more complex problem. I would presume that this combo would only delay the implementation of complex problems otherwise the junior wouldn't be a junior. How are these two suppose to cummunicate on the same level. I can't imagine 8hrs a day of grunting and pointing at the monitor as being very productive.

PP is not for everyone, even the authors of Extreme Programming admit that you should only adopt PP if it works for the developers and the project. But that's no excuse for labeling the XP methodology "evil", because XP does offer important aspects of any reasonable development process should include, i.e. unit testing, automated builds, and etc.

Another point that critics of XP frequently forget is the #1 tenet -- use XP only if the cost of change is low. If you adopt XP and don't think about the cost of change in the late stage of your project, then there's no one to blame but yourself.

After reading both blogs, it sounds like they are against pair programming, not XP. XP has twelve "core practices". Pair programming is one of them. There are many more that I think most developers would agree on: collective code ownership, coding standards, small releases, refactoring, simple design, continuous integration.

As for pair programming - it is not for everybody. I know this. We practice it where I work. Sometimes it is great - two people that really feed off each other cranking out a lot of code in a short period of time. Sometimes it is painful. However, it think it does have its merits. From my experience:

1. Fewer errors occur because two people are watching the code. I have found this two be an almost absolute.

2. Better code is written because two people are driving the "micro-architecture" of the problem at hand. This is not always the case, but often in my experience.

3. Knowledge is transferred - especially when you pair a somebody who is a "newbie" in a certain area (e.g. sockets) with somebody who has experience.

And I certainly don't think that half the amount of code gets written. It isn't equal to when everybody works alone, but I think the trade-offs can be worth it if everybody can do it. As for Cedric's scenario of one person using a text editor and one using an IDE - here is my take. If the user of the text editor is painfully slow, somebody needs to make them use a more productive tool. Programming should not be about personal preferences, it should be about writing *good code effeciently*. They can use what ever the hell they want on their own time. When it is my time as well, they need to keep up or find another line of work.

Oh, and pair programming is not unique to XP. So if people want to condemn pair programming, fine. I just wish they would just say that.

Yes, I believe their comments was based on Pair Progrmming with their attitude and experience towards it. But still, how many teams in this industry are not using a "Common IDE" strategy? Dont you think, in most of the companies, thats becoming one of the necessary things to follow a common IDE to make things more productive, especially in the time where vendors are making their own extensions from J2EE Specifications and web services? I believe, from my experience, pair programming success depends on "how you pair the team" and not depending on how the "pair works" after picking "Cat and Rat" in a team.!
I am with the advatnages of many of the other features of Xtreme Programming.
Lets try to pick the good side of everything, telling this, I never read any book on Xtreme programming, other than some internet stuff and forums.
Kudos to all those guys who are trying to make others life easier and kudos to those who are trying to find the issues associated with it to make it better in future.
Mahesh

Most of us Java developers work in cube farms, with a few meager square feet of space to hang a couple pictures of our kids with thumbtacks. Now management and a few XP zealots think we should share this space with another programmer. Hey, perhaps we should stack three programmers in each cube for triple the brainpower!

Since it is such an effective work strategy, let's have upper management share cubicles too. They can sit in front of a computer together when they write their mission statements and annual objectives, and correct each other's grammar along the way.

Perhaps if TWO of them put their heads together, they will be smart enough to omit this ridiculous tenet of the extreme programming model!

You don't get it, do you? XP never suggests cramming two people in a cube. One of the first things that is a candidate for change in a work XP environment is the office layout. XP advocates on open layout - preferrably a computer where two people can work comfortably side-by-side, such as a big card table. This lets the keyboard be passed between the two without moving positions. Cubes suck. But in an XP environment, they suck big time.

And one more thing, liking pair programming or XP doesn't make you a zealot. Pair programming is not for everybody, but don't label those of us who like it and practice it as zealots. And lose the sarcasm until you have all the facts straight.

|
| Perhaps if TWO of them put their heads together, they will
| be smart enough to omit this ridiculous tenet of the
| extreme programming model!
|

While I think that pairing is one of the more difficult aspects of XP to get right, I feel its the most important.

Whats more, there is a good marketing phrase (quoted to me by an XP proponent actually) that says "You cant be *given* it - you have to *get* it" - and this is so true of XP. When XP was introduced to me, I "got" it - it didnt take much convincing. It took a while before I got to actually use it (and even then, all aspects were not there) - but in the meantime, I learnt as much about it as I could. Now having done some, all experiences I have had thus far reinforce the benefits.

Unlike most other approaches that are _process-oriented_, XP is a practice that is heavily dependant on _discipline_. This is both its weakest and strongest point.

One of the things that you come to understand is that all of the tenants of XP (I can never remember them to recite them) are there for a reason. Whats more, they all lean on each other. The weakness of one tenant is countered by the strength of another.
e.g: A programmer writing on their own is less likely to write good unit tests - but in a pair, they are more likely to do the right thing. You would imagine that by constantly refactoring, that you would never be confident that anything worked - but because of your unit tests, you are. You would imagine that the lack of emphasis on "up-front" design, that the design would stink - but by constantly refactoring, it doesnt. And so on.

While adopting any practice requires a level of pragmatism, in leaving out any one of the fundamentals of XP, you have to understand that you are weakening it - perhaps fatally. Its quite possible that by half-doing XP, in some cases, you may be worse off than doing none. You just have to be aware of what the consequences are.

In my personal experience with paired programming:
1) Its what I do naturally - and I think its very good at getting large quantities of QUALITY code done.
2) You have to be conscious of paired programming becoming paired arguing. Swap partners regularly - take "personal time" breaks. Change what you are working on.
3) *Recognise* that when you are doing some exploration work that you might be quicker on your own. (But all PRODUCTION code in pairs)
4) Its quite exhausting - your brain is at 100% utilisation all the time. Take breaks.
5) Realise that you are building a working relationship with your pair - it wont come together in one session.

I don't think 'XP' is THE solution to anything any more than any other set of pratices is THE solution ... I don't think responsible people in any camp make claims like that.

I think that different projects may be run in different ways depending upon the specfic needs of the project. 'XP' may not be appropriate for a project involving teams on three different continents attracting the attention of management in many layers of the organization. There it may be more appropriate to use a more formal methodology.

I think that we should take from it the practices that are valuable in a specific situation ... 'test-first', for instance, may be cost-effective in some situations, pair programming may be useful when an important part of the work is mentoring, which is quite common (whatever the original intent of PP may be) ... most importantly I think it is a valuable reaction against USELESS formality. What is useful and what is useless is still a judgment call, but in my opinion it is important to question some of the document-heavy practices we have been using for years ... and to the extent that these 'agile' methodologies help us do that, I think they are providing a valuable service.

Business managers may not know about these considerations ... why should they ? That's why they hire us - right ? So nothing has changed ... it has always been, and will always be, the job of the IT professional to make the right choices for project management and to explain and justify those choices to the business management. That means we will have to struggle against fads and the urge to apply ideas inappropriately ... but that is everyday business in all levels of an organization, isnt' it ?

XP is a lot more than pair programming, but pair programming is probably its least widely applicable facet. I endorse pair programming only for mentoring and debugging. Quite generally, the weaknesses of XP as I see them are human-factors weaknesses. XP could be caricatured as "hire [an even number of!] heroes and trust them implicitly." In the real world, most shops have to integrate the efforts of people with different levels of skill and experience. In my experience, XP can't cope with that.

The notions expressed in the Agile Manifesto are, in my view, much more realistic and closer to the mark. They deprecate documentation, which is INEXCUSABLE; the only alternative to documentation is folklore. If XP tacitly assumes that everyone is at the same skill level, Agile seems to assume that there will never be any turnover of personnel.

But the basic idea of keeping the process as lightweight as possible is essential. Backtracking cannot be prevented, so the best you can do is make it cheap. As for the heavyweight, branded methodologies, I have seen half a dozen shops descend upon them like cats on tuna fish, with incoherent cries of joy, then choke to death on the scaffolding: the terminology, the diagrams, the processes. Allowance is never made for the time it takes to migrate these things into the organizational culture. If it were, for all I know, they might work; all I'm saying is 1) I've never seen that, and 2) I don't think it's necessary. The basic notion of the iterative process can be taught in half a day and then what matters is to just immediately start turning that crank. A mentor needs to hang overhead for a while, pointing out looming dangers of iteration scope creep or lumps of complexity that will be hard to backtrack across.

<Frank Wilhoit>
Quite generally, the weaknesses of XP as I see them are human-factors weaknesses. XP could be caricatured as "hire [an even number of!] heroes and trust them implicitly." In the real world, most shops have to integrate the efforts of people with different levels of skill and experience. In my experience, XP can't cope with that.
</Frank Wilhoit>

Well put. XP has many good ideas if you look at them at a high level, but the specific implementations of them don't match up with any real world companies or projects I've seen. The big lynch pin is that if you accept pair-programming, then the existence of pairs lets you make alot of other assumptions about trust and process. But if you take away pair programming (which I think is a must - pairs just aren't workable in most companies), the _specific_ XP practices start to break down.

As you mentioned, one of the good things to come out of XP is the idea of smaller iterations. That's a great start toward verifiability that the developers and end-users are in agreement. But what XP misses is the middle-men - you absolutely need a PM in some guise to ensure that work is being done in reasonable orders, you absolutely need QA people to keep the developers honest.

Related to that - the idea of unit tests in general is great. It's a wonderful developer's tool. But the XP advocates forget the key phrase there - "developer's tool". Unit tests don't mean squat to the end product. For that, you need integration tests, and regression tests put together by people who have no relation to the code (e.g. QA people).

In all I like the move away from massive, bloated methodologies. But frankly, XP sucks because it knee-jerks too far in the opposite direction - no true developer responsibility, no indepedent verifications (before the customer sees it!), nothing written down permenantly. In a nutshell, XP says you must trust your developers completely and absolutely. Well, I've yet to meet the perfect developer - has anyone else?

"But frankly, XP sucks because it knee-jerks too far in the opposite direction - no true developer responsibility, no indepedent verifications (before the customer sees it!), nothing written down permenantly. In a nutshell, XP says you must trust your developers completely and absolutely."

No it doesn't. It does not ignore the need for QA. It does not say things cannot be written down permanently (note cards are more a metaphor that requirement are never set in stone - they aren't a must). Software can always go through QA before being shown to the customer. However, if it is a prototype, I don't see why it has to go through QA first.

So, if you have your QA in place (with a suite of acceptance and regression tests) and a project manager keeping things on track, what is wrong with XP (other than PP)?

Hey, if people don't like PP or XP - fine. It is not for everybody, and even the most avid XP proponents will say that. But before people are critical of XP, they should at least get their freakin' facts straight!

<Ryan Breidenbach>
XP never says that you do not need a project manager. XP never says that you do not need a QA. Where did you get that idea?
</Ryan Breidenbach>

I'm coming from a slightly different perspective. What I'm saying is that XP gives people the perception that alot of projects can succeed without a PM, and without QA. And more naive people end up believing that PMs and QA aren't as necessary as they believe "'cuz XP tells me so". And 6 months later they find out the truth....

To flip it around a little, your argument sounds just like Rational's on RUP. You say "XP never says <blah blah>", just like Rational says "RUP is any weight you choose! You choose what parts to use and not to use".

It differentiates, but gives you no clue how to go from one to the other. The problem here is that indepedent pairs are off happily unit testing in isolation from other pairs, and integration is a special step. After all the necessary integrations are done, then you go to acceptance. This is fabulous for small systems, but it's death as the project grows. Over time, you find that integration of pair work costs more than each pair's unit of work (e.g. the graph of component interactions is more complex than the sum of the components).

The best approach on any system less than a toy is to rely much more heavily on automated _integration_ testing. Unit tests are a side line and not much paid attention to by anyone, the integration tests are where the real answers lie. And that's where developers should spend more of their time - on component interactions and being sure their stuff works in the system at large, not that it works because a toy unit test driver told them so.

<Ryan>
No it doesn't. It does not ignore the need for QA. It does not say things cannot be written down permanently (note cards are more a metaphor that requirement are never set in stone - they aren't a must). Software can always go through QA before being shown to the customer. However, if it is a prototype, I don't see why it has to go through QA first.
</Ryan>

There's obviously lots of ways you can do it, many processes you can follow. XP doesn't disallow anything, that's for certain. But at the same time XP gives the impression that you can safely omit things like QA and PM's for many projects. It's a powerful impression, and it's lead many groups down the garden path.

And the really funny thing - when you've done both, and tried things different ways, you find where your effort is most importantly spent. XP emphasizes unit tests with a vengeance. My own philosophy emphasizes integration tests with a vengenance. Neither precludes the other, but emphasis _does_ matter. In my world, the emphasis is on integration, and integration works, everything works. In the XP world, unit tests have the emphasis - but when unit tests are done, you still haven't proven anything. This isn't a big deal in small systems, but again it's deadly as a system grows in size and complexity.

<Ryan>
So, if you have your QA in place (with a suite of acceptance and regression tests) and a project manager keeping things on track, what is wrong with XP (other than PP)?
</Ryan>

The problem here isn't a problem, but really it's an issue of classification. What I've found is that as you add such things (some QA here, some regression there, some PMs over there)....well, after awhile you find you're just not doing XP. Maybe you want to label every process that's iterative with short cycles and that has unit tests "XP" - but it's not.

Here's a question for you, a serious one. How much can you take away from XP, or add to it, and still seriously call it XP?

Mike:
To flip it around a little, your argument sounds just like Rational's on RUP. You say "XP never says <blah blah>", just like Rational says "RUP is any weight you choose! You choose what parts to use and not to use".

Not at all. You said XP is missing a PM and QA. I simply replied by saying the XP does not say you go without QA or PM. In fact, both of these are mentioned quite extensively in the XP books. Quite a bit is written about QA working with the customer to develop a suite of acceptance tests. A whole book is written about managing XP projects, and I don't think a PM is neglected there, either. If you get a different impression, I do not what to tell you. You must be reading stuff I have never seen.

As for RUP trying to be lightweight... I think that is Rational trying to lure back people that realize that many of their heavy tools/processes are bullshit for many projects. They may very well have their place in large enterprise projects, but the full blown RUP can burden small/medium projects. RUP is trying to appeal to the little guys, too. XP never tries to say it will work for large teams.

Mike:
But at the same time XP gives the impression that you can safely omit things like QA and PM's for many projects.

How did you get this impression? Again, you must be reading some stuff I have yet to see. All the stuff I have seen never says these two can be safely omitted. I can't see how a project could succeed without either, personally.

Mike:
The best approach on any system less than a toy is to rely much more heavily on automated _integration_ testing.

And that is fine. I agree that integration test are critical. However, they normally can't be done with nearly the frequency as unit test. If you decide to refactor a method to clean up some hairy code, do you want to unit test that class, or do you want to build the entire system and run a full integration test? Unit tests check for errors on a micro level. Integration tests check for errors at a macro level. Both are critical, but it is the unit tests that help you move quickly, which lead to shorter releases, which leads to the customer seeing the working code faster, which leads to...

I think you get my point. Also, XP tends to make the integration tests a function of QA. If you want develop to own that, fine. I think it should be a combo of both. The developers work with QA to let them know what the software does, and QA owns/maintains the acceptance/regression test suites.

One last thing on unit tests. In my experience, I have found that writing unit tests also leads to better code. In order to unit test a class, it needs to be decoupled from the rest of the application so it can be isolated. This leads to designs that communicate through abstractions (interfaces) rather than directly (class inter-dependencies). A great side-effect of unit tests, if you ask me.

<Ryah>
And XP agrees. It clearly differentiates between developer test (unit test) and customer test (acceptance test).
</Ryan>
<quote>
It differentiates, but gives you no clue how to go from one to the other.
</quote>

You don't really "go" from one to the other. Maybe that's the problem. What was the specific problem you were having with the acceptance tests, in light of the unit tests and any transitioning between them?

<quote>
The problem here is that indepedent pairs are off happily unit testing in isolation from other pairs, and integration is a special step.
</quote>

Integration is not a special step. In fact, in XP it should be happening more than once a day. (See: Continuous Integration, a core XP practice)

<quote>
After all the necessary integrations are done, then you go to acceptance. This is fabulous for small systems, but it's death as the project grows. Over time, you find that integration of pair work costs more than each pair's unit of work (e.g. the graph of component interactions is more complex than the sum of the components).
</quote>

This is totally wrong. Integration of pair work should be happening at least once a day, preferably more than once. It happens so often, there is no Big Bang integration event at the end of each cycle; it's a non-event. Collective code ownership and pair programming should minimize the amount of friction between interacting components. If there is confusion anywhere on an XP project between developers of components or subsystems, as far as API or interface, it's discovered immediately.

<quote>
The best approach on any system less than a toy is to rely much more heavily on automated _integration_ testing.
</quote>

Can you describe this? Your terminology is, uh, a bit loose, and confusing in the context of your statement.

<quote>
Unit tests are a side line and not much paid attention to by anyone, the integration tests are where the real answers lie. And that's where developers should spend more of their time - on component interactions and being sure their stuff works in the system at large, not that it works because a toy unit test driver told them so.
</quote>

Yes, testing is not well understood by many developers. There are differences in unit testing, functional testing, system testing, integration testing, etc. Each type of testing provides a different type of coverage. They are all complimentary and should all be used to the extent that everyone is confident in the quality of the code. XP is not at odds with this and goes to great lengths to stress the importance of quality and confidence. Now, having said that, what exactly are you talking about?

<quote>
XP emphasizes unit tests with a vengeance. My own philosophy emphasizes integration tests with a vengenance. Neither precludes the other, but emphasis _does_ matter. In my world, the emphasis is on integration, and integration works, everything works.
</quote>

You know, I really don't see the difference, except that maybe you are omitting class and method level testing, and only testing code that combines more than one class, library, or component. So, you are actually doing less testing. And almost going out of your way to do so. XP says to "test anything that can break". To me, this means unit test, integration test, etc. The emphasis is not on classes or methods, it's on code ... specifically, code that can break. Furthermore, the XP approach to testing is intimately tied to Test-Driven Design, Refactoring, and Continuous Integration, which I'm pretty much convinced at this point you guys never did.

If integration works, then the application works --at that point in time. That says nothing about the resilience of the code once people start to change it or reuse it in some other context.

<quote>
In the XP world, unit tests have the emphasis - but when unit tests are done, you still haven't proven anything. This isn't a big deal in small systems, but again it's deadly as a system grows in size and complexity.
</quote>

When unit tests are done, you've proven that you can go in and change anything with that code at any time in the future and be absolutely confident that you haven't broken anything. The tests will always be there and if you are practicing continuous-integration you will be running the full suite of tests as regression tests on a daily basis, so you will know on a daily basis how healthy your code is. Integration testing should be an extension of unit testing, so you're really not missing anything as far as large systems are concerned.

<quote>
Here's a question for you, a serious one. How much can you take away from XP, or add to it, and still seriously call it XP?
</quote>

In my opinion, you can't take anything away. It's all there for a reason and the interdependencies are thoroughly, if not painstakingly, documented. Do so at your own risk.

As far as adding anything to it, that depends ... I would definitely research what you are about to add by searching all of the available information on XP and Agile processes to see if there has been any debate about it. If what you're adding is in line with the spirit of the methodology, as far as Keep It Simple Stupid, You Aren't Gonna Need It, etc. then you're probably safe. XP doesn't really recommend any development tools, for example, but there are a few obvious favorites with the community, such as JUnit, CruiseControl, Cactus, etc. To my knowledge, XP has never said to do away with PM or QA. That's an extreme interpretation that doesn't really jive with the intent of the philosophy.

You are getting very emotional whenever someone disses you. This indicates to me that you are a useless bum who does not know how to program, and the only reason you're getting paid is because your nerdy partner-pair-buddy thing or whatever you want to call that freaking Klingon who knows his XSL better than you do, is paying you big dividends.
Here's the bottom line: For those of us in the industry who actually are smart and deserve to be called "programmers" or "developers", well, we don't need a little teddy bear next to us to help us when times get tough. We find out all the information ourselves and always have a good solution.
XP sucks, man... the only reason you like it is because you suck too. Once you get good at programming, you won't beat the drum for your XP friend anymore.

HAHAHAHHAHAH
OH MY GAWD, IT'S BEEN SO LONG SINCE I LAUGHED SO HARD.....

Thank you Leonard for that humorous anecdote, this stale debate needed that....

I don't see why everyone is arguing about this. Some people like to eat rabbit and others don't, why is there essays being written on how wrong the other side is? Do what ever you want.
Now excuse me while I stop my ribs from splitting...

"You are getting very emotional whenever someone disses you. This indicates to me that you are a useless bum who does not know how to program."

Nobody is "dissing" me. Some people have said some things that I thought were unfounded or untrue and I commented. The only person that has "dissed" me personally is you. But if taking personal shots at people you don't know floats your boat - have at it.

"For those of us in the industry who actually are smart and deserve to be called "programmers" or "developers", well, we don't need a little teddy bear next to us to help us when times get tough. We find out all the information ourselves and always have a good solution."

OK. So, if you come across something that is new to you. Or maybe you know everything and this is not possible. If that is the case, forgive me your highness. But for the sake of argument, say you need to implement something using JMS and you have never used it before. And let's say you have a co-worker who has been working on a system using JMS for six months. Would you:

A. Ask your co-worker to get you up to speed quickly so you can get to your real work.
B. Go at yourself and spend countless hours reading up on a new technology.

You would obviously go for 'B', because you are the uber-hero who doesn't need help, right?

Also, let's say you have a co-worker who is writing a Swing application for the first time. And let's say you just finished a ten month project wtiting a Swing application. Your co-worker asks you to sit with him and help him out. Would you:

A. Sit with him and share with him your experiences/short cuts/patterns/pit-falls you have discovered in the last ten months so that you can help him and your company succeed.
B. Say, "Go to hell you freakin' weakling. I'm not your mom. Go do your own freakin' homework. I don't have time to hold your hand!"

Again, you would choose 'B'. And that would make you the ******* I'm thankful I don't work with.

You are an arrogant little boy and you obviously know everything. The likes of you have destroyed more in this industry than anything. Thank god the dot com fallout is just about over and there are few of you left.

<quote>
Well put. XP has many good ideas if you look at them at a high level, but the specific implementations of them don't match up with any real world companies or projects I've seen. The big lynch pin is that if you accept pair-programming, then the existence of pairs lets you make alot of other assumptions about trust and process. But if you take away pair programming (which I think is a must - pairs just aren't workable in most companies), the _specific_ XP practices start to break down.
</quote>

What assumptions abour trust and process are you talking about? I've actually done XP, by the book, and I'm not sure what you're talking about.

XP is very clear that all of the practices are there for a reason. If you can't do them all, for whatever reason, then you need to find a better process for your org.

Pair-programming is hard to learn and do well. But, so is Java/J2EE. Does that mean it's not workable in most companies?

<quote>
As you mentioned, one of the good things to come out of XP is the idea of smaller iterations.
</quote>

In all fairness, XP did not come up with this. On the contrary, XP didn't come up with ANY of the practices it ties together. They existed in the wild long before anyone started thinking seriously about software methodologies. XP is a collection of best-practices that happen to make a pretty good methodology when combined.

<quote>
But what XP misses is the middle-men - you absolutely need a PM in some guise to ensure that work is being done in reasonable orders, you absolutely need QA people to keep the developers honest.
</quote>

Why is it up to XP to tell you to get a PM or QA dept? I suppose XP misses the bathroom, and the coffee pot, and the carpet, and the roof, too, since it doesn't specify what you should use. Or, are you implying that XP prescribes you not have a PM or QA dept? If so, I think you should check your facts.

<quote>
Related to that - the idea of unit tests in general is great. It's a wonderful developer's tool. But the XP advocates forget the key phrase there - "developer's tool". Unit tests don't mean squat to the end product. For that, you need integration tests, and regression tests put together by people who have no relation to the code (e.g. QA people).
</quote>

XP does a good job stressing the importance of testing at all levels. Acceptance tests are used to verify the quality of the code throughout the process, from the very beginning. This is facilitated with unit testing, automated unit regression testing (once a day or more), automated functional testing, integration testing, etc. If you have the luxury of a QA dept., that's great. If not, then someone else does it, usually the developers. The important thing is that all of the necessary levels of testing are covered and XP accomodates this.

Your assertion that unit tests "don't mean squat to the end product" is wrong.

Unit testing is an efficient, cost-effective way to ensure the application doesn't break as it is modified and changed over the years. This provides incredible value. It's a lot cheaper to have developers uncover and fix bugs they create AS they create them, rather than to wait until the application goes all the way to QA and back to the developers.

<quote>
In all I like the move away from massive, bloated methodologies
</quote>

Like what? And what didn't you like about THEM?

<quote>
But frankly, XP sucks because it knee-jerks too far in the opposite direction - no true developer responsibility,
</quote>

I'm not sure what you mean here, but on an XP project there is nowhere to hide. If you're not doing your part, it will come out immediately, if you're doing: regular standup meetings, pair programming, collective code ownership, and continuous integration. If you can't figure out whose not doing their job under those circumstances, I'm afraid there is not a methodology or process in the world that will help your org.

No, actually, it doesn't say that. An XP team is an open book. It actually goes out of its way to say, "Hey, don't trust us! We make mistakes, like all people make mistakes, and here is what we all need to do to help us not make mistakes." How can it be any more clear in that respect? Why do you think it bothers to prescribe a methodology at all? Developers don't need to be perfect. We just need a little bit of humility.

Anyone who really cares about putting out high-quality software in their org should read up on XP. There's a lot of good info on the web and a slew of books available that really dig into the specifics of the methodology. It's no silver bullet and it never claimed to be. It's also challenging to implement, but aren't all good things?

<Rollins>
XP does a good job stressing the importance of testing at all levels. Acceptance tests are used to verify the quality of the code throughout the process, from the very beginning. This is facilitated with unit testing, automated unit regression testing (once a day or more), automated functional testing, integration testing, etc. If you have the luxury of a QA dept., that's great. If not, then someone else does it, usually the developers. The important thing is that all of the necessary levels of testing are covered and XP accomodates this.
</Rollins>

OK, here's where you and I are diverging. In my world a QA department is _not_ a luxury. And people who believe so are shown the door. Certainly not every project out there needs formal QA, but I feeling that we'd strongly disagree on which projects should have it and which should not.

Why is this? Because developers are too close to the code, and too far removed from business realities. They need a QA department as a double-check.

<Rollins>
Your assertion that unit tests "don't mean squat to the end product" is wrong.
Unit testing is an efficient, cost-effective way to ensure the application doesn't break as it is modified and changed over the years.
</Rollins>

Unit testing does not ensure that. If you believe so, then I don't see any point in going further in discussion. Unit testing has value, I won't dispute that, but its value IMHO is much lower than you assert.

<Rollins>
This provides incredible value. It's a lot cheaper to have developers uncover and fix bugs they create AS they create them, rather than to wait until the application goes all the way to QA and back to the develope
</Rollins>

I agree, it's cheapers for developers to eliminate bugs before it goes out the door. But your assumption is that developers will find most/all bugs. In my experience, they do not.

As for "all the way to QA", you make it sound like you have to ship your code to the moon to get it tested. It doesn't have to be that way. In projects I've worked on, QA people were thoroughly integrated with developers. In between formal test runs, testers run spot checks and regressions as developers check in code. It's not unusual for a QA person to call me 15 minutes after check in and say "Hey Mike, you've got a little bug in new login code...".

You may say that PP can do this sort of function, but it can't. Developers tend to be tightly focused at the problem at hand, and can lose track of the system as a whole. And at the same time, PP ties up two people for significant amounts of time.

If you go with an integrated QA team, alot of problems like this go away. One QA person can cover many developers, and they're not emotionally tied to the micro-deliverable of the moment.

Once again - unit tests have value. But unit tests are not a replacement for real QA. Developers should test their code, but developers are poor testers compared to QA professionals.

The points raised in this thread do nothing more than propagate misconceptions about Pair Programming.

In PP, two programmers working on the same problem do much more than two programmers working on separate problems, in general. Before you speak up, I realize that it is always possible to find a short period of time (measured in hours or days) over which two specific programmers working on specific spearate problems may outperform the pair; however, in the large and in general, a dynamic pair beats two singles. The reason is simple: less waste.

A dynamic pair wastes less time going down blind alleys, wastes less time looking up reference material, wastes less time trying to decipher the requirements of the task at hand. The studies have shown that pairs inject about 15% fewer defects and spend 15% more calendar time doing it. The result is a little more up-front cost in exchange for larger savings in later phases of a project. Go to http://www.pairprogramming.com for the details.

As for the social aspect of PP, I have done it and my experience is not all negative. In fact, much of it is positive. I have worked with thoughtful, intelligent programmers who were focused on solving the problem at hand. I have worked very well with these people. We have often disagreed on an approach to solve a particular small part of the problem, but generally, that has not been an issue. We simply agree to try one approach (flip a coin) and be aware of a potential for going down a rat hole. We have no ego (well, not much) so if my solution doesn't work out, I can live with that, saying, "OK, let's try it your way." The key here is to be committed to the Power of More Than Just One. If you make a few ego-concessions in favor of leveraging the strength of the team, then the project is generally better off. This is true of teamwork in general, and of Pair Programming in particular.

As for the practical aspects of PP, we did have all our development environments set up the same way (jEdit, Ant, and so on, with all the same plug-ins) and it worked beautifully. Whenever someone found a cool new feature of the IDE, he shared it with the group and we all benefited. If there be Coding Standards, then what's wrong with IDE Standards? Again, if you know the power of the team, then you make concessions to leverage the power of the team. If I go more slowly for one week becoming accustomed to the new IDE, but the project goes eight weeks faster because everyone talks to one another, then the project wins and I gain a new skill. We all win.

On this last statement, I must absolutely, categorically and violently agree:

>And I would be extremely wary of working for a company
>that has made it its True and Only methodology.

Any company that makes any methodology its True and Only is too short-sighted to benefit from my employ. So it should be for us all. No One Metholody Fits All Projects.

<J.B. Rainsberger>
As for the social aspect of PP, I have done it and my experience is not all negative. In fact, much of it is positive. I have worked with thoughtful, intelligent programmers who were focused on solving the problem at hand. I have worked very well with these people.
</J.B. Rainsberger>

Congrats - you work well with people who are easy to work with and who get along with you. Unfortunately for me:

- some people I work with have radically different styles than mine. Our end results are both good, but we'd go slightly crazy being forced to meld our styles.

- some people just plain don't get along. And no, you can't always afford to fire someone just because they don't pair-program well with someone.

- some people are most productive in a quiet, isolated environment. People who like think time to solve problems, not chatter. Pair programming penalizes such people.

- People are unmatched in ability. Period, full stop. Unless people are closely matched, the "lesser" person is riding on the other person's coat tails.

The point is that you can successfully pair program - but only if you're paired with the right person. Now - how often are you going to be paired with someone you like well enough to be that close to, and who is close enough to your ability that one doesn't eclipse the other?

<quote>
Congrats - you work well with people who are easy to work with and who get along with you. Unfortunately for me:

- some people I work with have radically different styles than mine. Our end results are both good, but we'd go slightly crazy being forced to meld our styles.
</quote>

I pair-program with people of different backgrounds, sexes, races, ages, styles, and abilities. My goal is always to write software, teach something, and learn something. In that order. It just takes a little getting used to, but I really value those opportunities.

<quote>
- some people just plain don't get along. And no, you can't always afford to fire someone just because they don't pair-program well with someone.
</quote>

You should focus on writing sofware and not whether you like the person you're pairing with. I don't socialize outside the office with 95% of the people I work with, and some of them really offend me, but that doesn't stop me from working with them to accomplish a team objective.

<quote>
- some people are most productive in a quiet, isolated environment. People who like think time to solve problems, not chatter. Pair programming penalizes such people.
</quote>

This *may* be true, but pair-programming eliminates some risks that coding alone will never eliminate. You may be able to bang out more lines of code when you're alone, but it probably has more bugs and you may not have used the most efficient approach than if you had an extra set of eyeballs watching.

<quote>
- People are unmatched in ability. Period, full stop. Unless people are closely matched, the "lesser" person is riding on the other person's coat tails.
</quote>

There are entire books that have been published that show you how to leverage these situations for the overall good of the project.

<Rollins>
I pair-program with people of different backgrounds, sexes, races, ages, styles, and abilities. My goal is always to write software, teach something, and learn something. In that order. It just takes a little getting used to, but I really value those opportunities.
</Rollins>

The goal of PP is that two people are going to create more reliable code. For this to happen, the pairs actually have to work well together. If you accept this as sort of obvious, then can make some observations. And the most relevant observation is that there alot of people who do not work especially well together. People clash, for a variety of reasons. And if you have a clashing team, PP is not going to get more work or better work out of them then if they were working alone.

<Rollins>
You should focus on writing sofware and not whether you like the person you're pairing with. I don't socialize outside the office with 95% of the people I work with, and some of them really offend me, but that doesn't stop me from working with them to accomplish a team objective.
</Rollins>

Then I'd say you're a better man than most. If I have to work closely with someone, to the extent of PP, that I don't work well with, then my work suffers. If they offend me, or their style clashes with mine, or they're too slow, or too fast, it's going to raise my stress level. And in my experience people with elevated stress levels don't do as well as those comfortable and relaxed.

I don't have a problem with pairing per se. I've worked with paired with some people where we clicked, and got alot accomplished. What I don't like is the idea that you have to work in pairs.

<Rollins>
This *may* be true, but pair-programming eliminates some risks that coding alone will never eliminate. You may be able to bang out more lines of code when you're alone, but it probably has more bugs and you may not have used the most efficient approach than if you had an extra set of eyeballs watching.
</Rollins>

I agree, but fortunately I haven't taken the coding alone approach in a long time. That's where testers come into play. A tester, a PM, regression and perf tests, and a good version control system can show who's got what sort of bug counts. It catches the developers mistakes, and lets you look out for developers who are cranking out alot but with a high rate of defects. You take those people aside and tell 'em to pay more attention to quality.

As for efficiency - again, that's what tests are for. Even XP will tell you, no one cares if you have the most efficient solution. What they care is that it's efficient enough - and that's why you have load tests and stress tests, to tell you definitively that your code is fast enough. In fact, those tests are much more definitive then another developer's eyeballs and brains.

"Some people I work with have radically different styles than mine. Our end results are both good, but we'd go slightly crazy being forced to meld our styles."

Coding style or work style. Why does this matter?

"People are unmatched in ability. Period, full stop. Unless people are closely matched, the "lesser" person is riding on the other person's coat tails."

So what? Doesn't this happen anyway. Don't the more talented people always pull more weight? And maybe the person will learn something.

"Some people just plain don't get along. And no, you can't always afford to fire someone just because they don't pair-program well with someone."

As above - isn't this a problem regardless of PP? And if two people really don't get along, there is no rule saying they have to pair together.

"Some people are most productive in a quiet, isolated environment. People who like think time to solve problems, not chatter. Pair programming penalizes such people."

And there is nothing saying these people can't go off and think. I do that all the time when I am stumped. I solve problems better sometimes when I walk around. So I will walk around. When I come up with something, I will share it with some other developers. If it sounds like a good idea, I sit with somebody and bang it out.

Sometimes you don't even have to work with anybody to code. If you want to work on a new concept, you are free to go sit at your desk and work on something new or prototype a new idea. Once it is fleshed out some, you can grab somebody and start working it into the code base.

"And if two people really don't get along, there is no rule saying they have to pair together."

Isn't there? Pairs are to be fluid. XP developers shouldn't pair exclusively with a subset of the total team. You should get up and switch pairs often. It is therefore inevitable that you WILL pair with each team member. So indirectly there is in fact a rule that they have to pair together. Sorry, you're wrong. Read up on your XP in all that spare time.

"you are free to go sit at your desk"

Something tells me you haven't been in too many XP labs. You have a desk?

"I do that all the time when I am stumped."

Really? You must not be practicing XP correctly. If you're pairing correctly you never get stumped. I've never been stumped before. Nope, not ever. Well, sorry, to be honest there was that one time when I concentrated, but just as soon as I stopped we were back at it. I mean if you have to think about something it means that it's just too complicated and you're doing something wrong.

XP is a very disciplined methodology. People aren't disciplined enough to write test cases on their own so they must work in pairs. This requires less discipline than before, I mean, you'd have to be really disciplined to program alone... Wait...XP is a less disciplined methodology because we didn't have enough discipline to cope with the other methodologies...no, no, I've got it all wrong. XP is a disciplined methodology, which is why we need coaches...no, if we were disciplined, we wouldn't need coaches. Well anyway, it's really really disciplined. That's what I'm trying to say. Even though traditional software development requires more discipline, XP is disciplined. See? Isn't that clear?

Taylor:
Actually there is something saying these people can't go off and think and his name is Ron Jeffries. As I stated earlier, Ron Jeffries has stated quite clearly "concentration is the enemy".

"Concentration is the enemy" was referring to pair programming. You aren't pair programming all day long. There are times when the team talks about design. This design talk is more on a micro level, but this still happens. You are allowed to think sometimes.

Taylor:
So indirectly there is in fact a rule that they have to pair together. Sorry, you're wrong. Read up on your XP in all that spare time.

I have never had this problem. Somebody *else* mentioned the scenario where two people just can't get along. If the team is sufficiently big (6-8 people) there is no reason that pairs can't be switched around enough and these two still don't work together. That is, if they just *can't* get along. Personally, I find this ridiculous that somebody can't get along with somebody else for strictly work purposes, but some people are just hard-headed I guess.

Taylor:
Something tells me you haven't been in too many XP labs. You have a desk?

I have a desk. With a computer. We also have a large table with two pair machines that face each other (4 developers + manager). Have you been in an XP Lab? Since you are clearly an expert on XP, I assume you have.

Look, XP suggests that you use these practices as guidelines. It also suggests that you follow as many as you can, as they support one another. But it also says that sometimes this isn't possible (like if there is an ******* that nobody wants to work with). If this is the case, you bend the rules to suit your needs.

In XP, where the group is really a team and everyone sees what everyone else is doing, (people) problems surface quickly. I'm talking about people going down dark alleys, goofing off, letting themselves be stuck on a problem for days instead of hours before asking for help. Those kinds of problems.

In XP, then, those problems surface quickly. It takes courage to solve those problems, by asking for help, and so on. (A pair can get stuck, too. We're not perfect. We just usually get stuck on something hard, not something silly like the syntax of a particular API call.) It takes discipline to take steps to avoid the problem in the first place, by agreeing to pair.

It takes discipline to follow a coding standard, integrate every fifteen minutes, have all tests running 100% all the time, remain honest, have respect for people and so on. XP demands this.

That's not to say that those things are not found in other environments; however, in a typical, fragmented group, when I don't have working code for four months and then kill myself to put it all together in the last two weeks, pushing dozens of bugs into the QA cycle, I can hide it from you. In XP, that's impossible.

I understand your points, and offer you this: PP is not about "making it work in a crappy environment"; it's not even about "making it work in any environment"; it's about creating an ideal environment for work and leveraging the power of PP within that environment.

You might claim that that's entirely impractical. "*My* group couldn't do PP" and you cite your reasons.

The bottom line is that PP embodies a different philosophy about problem solving than is traditionally found among software developers. Full stop. Ron Jeffries went so far as to say something about concentration being the enemy: if one needs to concentrate on a problem, then likely the problem is too big for one person to solve on his own. I understand that some people like this kind of challenge, but not on my watch: if my team knows it does best when it works together, then my team works together, including PP. It's that simple.

Is it for every team? No. Is it something that only works on rare teams? For me, the jury is still out. I admit that I have had poor PP experiences, but they have been with people that I wouldn't want on my team, regardless of PP. I haven't yet worked in a group that has a lonewolf genius that no-one likes. The so-called lonewolf geniuses I have met in this business have actually been pretty poor programmers, although they've had good ideas. Their problem has been poor execution, leading to difficult-to-maintain code.

Now if their ideas had been funnelled through my fingers typing, with input back and forth... that could have been excellent.

...and neither is any other method in an 100% "as is" form.
PP _can_ be a powerful tool when used right, this means that you should not over do it.

As mentioned before in this discussion, 100% PP is not good for any project - software development is more then programming and we all need some time on our own - even at work.

We also need to respect each other when it comes to choosing methods, we are all humans (I hope) and we are all different. Fore some people and some teams PP works just fine but for others adaptation of the method is needed.
But then again, you can't use RUP (for example) as is in every case either. Both XP and RUP are great tools - if they are used right and the people executing the work have a chance to influence their working environment!

The research on pair programming is not very extensive. Most, if not all, of the research was done with university students. It's quite a stretch to claim that the results would hold for a team of highly experienced software developers.

I've worked on a project where we used pair programming in a relatively pure XP environment for about a year. Although I found immense value in the XP focus on testing, the pair programming was not very beneficial. Rickard's "peer programming" approach has been much, much more productive for myself and my team. To be more specific, after a majority of the previous team was laid off and we transitioned to peer programming rather than pair programming we found that we just as productive and software quality did not diminish even with 1/3 the team size.

That being said, I work on a team where there is no issue in "calling in a pair" when needed or desired. There are some types of development tasks where I like an extra brain and set of eyes. Most of the time though I work alone (in a common area within earshot of the other developers) and it's great.

We don't have a problem with shared knowledge since we practice collective ownership of the code even without pairing. If you did a CVS annotate on our source code, you'd find that a large majority of the files will have been touched by 2-3 people at some point in time.

And, believe it or not, we still have plenty of social interaction without pair programming. :)

I don't know what type of programming environment you worked in before you tried XP and pair programming. Pairing obviously works better for you and it apparently works well for at least some university students. It doesn't work better for me and others who have tried the pure XP "way".

<quote>
That being said, I work on a team where there is no issue in "calling in a pair" when needed or desired. There are some types of development tasks where I like an extra brain and set of eyes. Most of the time though I work alone (in a common area within earshot of the other developers) and it's great.
</quote>

Folks, this is an example of doing XP.

They have paired; they are good at pairing; they will pair when it is needed; they understand when it is needed and when it is not needed. This is what Ron Jeffries means when he says that XP is not the practices, but rather what you know after you've done them. This is a glimmer of real XP.

Contrast this to "They refuse to pair; they will pair if forced to it; they complain when they pair; they are not effective at pairing when they do it." This is where many teams are that think PP is ineffective.

Is it with that kind of low-level provocative all-or-nothing troll-prone headline that you want to catch people's interest ? There's usually no such thing as all-or-nothing. Of course XP works in some cases depending upon people and the size of your project, of course RUP works in other circumstances, etc. But this headline... please... it just sucks big time and makes it sound like we're reading some low quality tabloid.

Sadly, the "X is evil" phrase is used in common discourse among programmers to mean "I don't see a good use for X". I don't find that it has the same sensationalistic bite that the literal meaning of the phrase has.

But I agree. "X considered harmful" is nicer and a better tribute, anyhow.

Seems to me that pair programming is what she really finds offensive. I tend to agree that pair programming is a tough sell for most people and that her experience with it is actually a common one.

The only effective pairing that I see on our development teams is when a particularly difficult problem needs to be solved. When you have someone else sit down with you and run through things, a good solution often results. This may take minutes, hours, or even days of putting heads together, but the result is almost always quicker, higher quality solutions to problems. Perhaps this sort of thing would be called Pair Problem Solving.

I think XP still has a number of common sense principles that are very helpful, and I still find it quite refreshing when compared to larger methodologies that make you a slave to process and paperwork. What works best for me is studying a number of methodologies and picking pieces that work best for my teams and my clients. We have essentially formed our own lightweight process out of others, and surprisingly enough, it mainly consists of common sense principles.

My advice is to become knowledgeable with many methodologies and to put them under the lense of your experience. Pick what works best for you and always use common sense as your guide.

By the way, if you're interesting in fast-forwarding through the preliminaries, this whole thread's been done to death over at StickyMinds.com. Bill Walton wrote, "That Dog Won't Hunt" and it sparked lively debate for weeks on the XP mailing list as well as the creation of two more mailing lists: Extreme Customering (XC) and XP Adoption. All three are Yahoo! groups.

Go to www.stickyminds.com and search for "That Dog Won't Hunt". The actual URL is long and nasty.

It seems to me that this discussion is too much focused on pair programming. XP is more than that. XP IMO has more to do with iterative development.

Projects get shorter and shorter. We need to do more in less time and iterative development enables you to more quickly adapt to always changing requirements. The same thing is going on with (R)UP and DSDM. These methods are getting more and more popular every day because of that.

Well, the article says "XP is Evil"
but all I have read was about pair programming.
One must not forget though, that pair programming might work if you have pairs like "Beck-Gamma", but I must agree, having average developers, it the end pair programming turns out to be nothing more than a peer-review or on the job mentoring (best case) or hurt feelings (worst case).
The best case events have been described as SD good practices aeons ago.
I must disagree with the financial part:
The work done: coding + QA
QA: testing + code review
(I omit functional and acceptance tests.)
During pair programming (and XP) it is performed by two people in parallel, while during the more traditional developer + QA process it is done sequentially. Thus I see no big difference there.
I do agree with the social part, though, completely.

However, XP does offer some good practices (most of which of course were not invented by XP, eg.: JAD) and I think it would not hurt anybody to read a few XP books. Those guys do have experience.

As for the last sentence, the True and Only methodology does not and will never exist. IMHO.

Dion -
can you, please rename your topic - use maybe - Pair Programming is tough -
I don't think that XP is evil - and I can tell from my past successfully projects ( yes Chiara these XP projects were big and they didn't fail). Kent is right - XP can recover a doomed project, not a doomed team.

To be balanced, I should share my thoughts on the times when PP has not worked well for me. There have been a few.

I worked on a project that had one member who just didn't like PP. When she was pairing and not driving, she sat back and did nothing. Perhaps she didn't understand the point of the navigator role in pairing. Although she would occasionally save my butt with simple suggestions that stopped me from going "the long way", I suppose that she undervalued her own contribution, and the point of pairing ended up being lost in the process. It's a shame, because she initially looked like she was willing to learn J2EE and become an accomplished J2EE programmer.

Now I could speculate that she was ashamed of her skill level or she was just being spiteful or she wanted to have the freedom to waste time reading e-mail or whatever... but that would be horribly unfair. I know that these are impediments to PP, but they are also impediments to software projects in general. PP just makes them more apparent. (I have often said that, if nothing else, XP brings problems out into the open and makes us deal with them. I know that that's enough to make many people wary of XP.) I would rather focus on how her reticence to participate in PP is reasonable. She may just not have realized how much she was contributing.

Another short-term member of the same team was a COBOL programmer new to Java. Pairing with him was often difficult because he literally couldn't put together a Java statement without help. We thought that he was eager to learn, but the pressure of finishing the project made it difficult for us to teach him Java from the beginning. We gave him Bruce Eckel's book, but he didn't read it. That told us that he was unwilling to learn Java, and we later realized that it was because he didn't really want to do programming. He just thought that he needed to do it in order to be promoted to the next level. When he realized that there was another way, he transferred off the project. Pairing with him was liking poking out my own eyes at times; at other times, it was OK. It was never dynamic, as it was with the other members of the team.

So PP won't work if one of the individuals involved is not interested in doing the work and is not focused on solving the problem. Ego and pride are the two biggest defeaters of the power of PP. Some might say that people generally are proud or have egos; therefore, PP is not a practical choice. I say (and The Right Honorable Mr. Gerald Weinberg agrees -- so there!) that pride and ego are an impediment to team work and to software development, and not only to Pair Programming.

You know - with the current headline, it almost appears as if TSS is endorsing the fact that a highly successful methodology, that perhaps has one or two quirky tenets (not necessarily as quirky as might appear once viewed in the right light) is all bunk.

Floyd talked recently about filtering out posts that are sensational. Floyd - I think you should really walk that talk and perhaps rename that title.

As somebody who has practiced RUP and XP, let me tell you that both emphasize on formal adoption of best practices that have been prevalent in the industry for decades. XP is NOT evil. Its very practical. Its scientific. And it works.

Besides I think that I find Beck and Fowler a little more authoritative on software engineering subjects than - Chiara.

Excellent points. Sometimes PP can uncover some things about people on your team that you did not know before. Like you said, some people may not want to PP because of they just don't like it. But you may also find that some people will not PP because it will expose their lack of skills or take time a way from their "personal time" like IM'ing, sending email, or wasting time of TheServe...

Now, now, Ryan... you've been Pair Programming, which means that your project is probably done by now. You deserve a break!

Imagine, folks: with PP you can finish the same jobs in less time and with higher quality! While your organization is frantically testing others part of the product (not build with XP) and those programmers are fixing bugs, you can cruise FOR WEEKS!

It sounds ridiculous, but I did it. At my last project at IBM, I cruised for three weeks because I had only two bugs to fix and the rest of my department had dozens. I kept myself busy doing research half the day for future versions of the product and writing articles. I was published twice. All because I used the core coding practices of XP and I did as much PP as I could. (Not much, but I did some. Everyone else was "too busy".)

I must have done something right. It can't be that I'm just that good a programmer, because there are many folks in that department as good as or better than I.

Congratulations. However, the "down time" could be for any number of reasons. You could have had less code to write, you could have had easier code to write, you could have been a better programmer (but you already said that wasn't the case). You even said you didn't pair very much, so how did that anecdotal evidence support your conclusion that "with PP you can finish the same jobs in less time"?

One of the criticisms I've heard of XP is that one actually has less down time when they are working fulltime on an XP team (vs. occasional pairing on a non-XP project). Although I suppose a team could schedule "down time" into their iterations, I haven't heard of any that do. I suspect that most teams have a backlog of stories and tasks ready to work if the team underestimates their velocity for a particular iteration. I know our team does. Because of this level of intensity, some developers are concerned that they won't have time for learning new skills on the job, etc. There is some truth to this concern although good developers will always somehow find the time on or off of the job to maintain their skill levels.

Seriously, an organization what would allow a capable developer to cruise for weeks while other parts of the organization are struggling to release a product has more serious issues than whether they use XP or not.

You're right, though: "Down time" has been the topic of some research within the XP community. I can't think of the references off the top of my head, but I know that one team in England (Connextra? Tim McKinnon, was that you?) used the idea of "freebie cards" that team members can use to do other things during a project, like outside research, offline skills development or just relaxing.

During my last XP project (while it was an XP project -- long story), we regularly took short breaks to re-energize ourselves throughout the day. The difference is that we did it in a slight more regimented way than a solo programmer would. We took a lot of breaks, because we were so productive when we were coding. We were able to achieve a good amount of balance, there.

As for me "cruising" at IBM, the term is relative. I wasn't "doing nothing". I was developing my skills, informally mentoring others in addition to playing some ping pong and surfing the web. That's just the way companies seem to work: they ride you for weeks (or months), then look the other way when you flake for a few days or "get sick". I would think it better to get sustained effort from everyone all the time -- we might not quit nearly as often. That's built in to XP, too.

My statement wasn't meant to back PP; rather it was meant to back XP in general. I'm still not clear who's focusing on PP and who's considering all of XP in this discussion. The thread title is pretty misleading. :) There was good stuff in XP that allowed me to feel in control of my work (Planning Game), make steady progress (Test-Driven Programming) and know that there is an end to the dark tunnel. I didn't work much overtime -- only when I wanted to knock a task out of the day, rather than let it sit overnight. For me, "XP For One" was a huge success. I can only imagine how good it would have been had I been able to pair.

When I *did* pair -- not on my own work -- I managed to help a few people get moving again when they were stuck. I shared knowledge, they learned and one admitted to me that he's a much better programmer now. So if strategic pairing works, then we ought to pair all the time and see where pairing becomes wasteful. In my experience, it's not often enough wasteful to justify incurring the overhead of deciding when to pair and when not to pair. It's cheaper just to pair all the time.

I work for a high-intensity startup company rather than a large corporation. I've worked as a technology consultant at many large corporations and I've observed that it is easier to "cruise" in those large organizations, especially if the surrounding people are busy deploying a product. I'm guessing you don't work in an XP-ish common area. It's certainly easier to cruise when you are alone in an office or cube.

| So if strategic pairing works, then we ought to pair all
| the time and see where pairing becomes wasteful. In my
| experience, it's not often enough wasteful to justify
| incurring the overhead of deciding when to pair and when
| not to pair. It's cheaper just to pair all the time.

Sorry, but this type of "logic" doesn't help to sell XP and it's practices. I do agree that there may be benefit to pairing "experimentally" to see if it works for an individual or a team. Of course, people may wish to take the more efficient route of learning from the experience of others. Unfortunately, this experience is anything but conclusive, either for or against PP.

There may be a lot of overhead for you personally to decide when to pair or not. That's not the case for me. There is also no evidence whatsoever to back up the claim that "it's cheaper just to pair all the time". That conclusion is an example of the unhelpful logic I mentioned earlier.

Take a look at section 2.5 in a recent Pair Programming Summary report (http://www.agilesweden.org/doc/PPSurveySummary.pdf). The experienced software professionals (many with 6 months or more of PP experience) made comments like the following about PP.

"According to my opinion PP is only good for specific tasks and not for all. In a large project is 80% of the code easy to write, to sit 2 is not only a waste of time it is also frustrating. For the other 20 % is PP very good and is used a lot".

"Taken from my own experiences, having a partner that i worked very well with, we stopped using PP because of the introduced stress, and a number of other reasons, reverting back to semi-PP, in the sense of SP with continuous crosschecking, sitting side by side with having a computer each. This way, we found that what we did as PP in a week, only took us about three days to accomplish using parallel SP".

So here is a statement that SP with continuous crosschecking is MORE efficient than PP. This is from an experienced software developer rather than from resource that focussed on university students doing PP in a classroom.

These statments match my own experience in pairing for over a year before transitioning to (back to) "peer programming".

You can imagine that if these experienced developers were forced to PP constantly because the manager believes "it's cheaper just to pair all the time", they would probably be at least somewhat unhappy. They might even start viewing XP as "evil". :) Of course, it's the overselling, hype, and misapplication of XP that is "evil" rather than the practices themselves.

Well, I'm sorry if my experience doesn't match your experience or everyone else's experience. I find it a little insulting to be told that my experience is somehow "wrong". I don't see how experience is less conclusive than theory, since experience is what counts, and not what someone thinks ought to happen. At the end of the day, it's what happens that counts.

I will read that PP Summary report, since I'm behind on the literature. Thanks for the reference.

| I don't see how experience is less conclusive than theory,
| since experience is what counts, and not what someone
| thinks ought to happen. At the end of the day, it's
| what happens that counts.

What "counts" is a function of values. I value working with my team to get high quality products delivered in a timely fashion. I wouldn't be able to feel good about weeks of down time while my team is struggling to deliver a product. I prefer to work in an organization where people with extra time find ways to assist those who don't. My point was not to criticize your down time experience but to share that, in my experience, in an XP environment there is little or no down time. Due to collective code ownership, there aren't situations where one person finishes early and watches stories/tasks not get completed. I can't imagine this happening for a day, much less three weeks. Generally, in our work environment anybody can start working on any story/task at any time.

I was also questioning the veracity of the conclusions about XP and PP that you've drawn from your experience, but I covered that in the previous message.

<Foster>
Due to collective code ownership, there aren't situations where one person finishes early and watches stories/tasks not get completed. I can't imagine this happening for a day, much less three weeks. Generally, in our work environment anybody can start working on any story/task at any time.
</Foster>

That last sentence scares the hell out of me. Let me get this straight - you have _no_ dependencies in any of your projects? All stories/tasks are completely indepedent?

Or is this the case of "everyone codes indepedently, writes drivers for the missing parts, and we integrate later"?

If the former - well, I've never seen such a system. If the latter - that's integration hell.

Don't take "Mr.Two-Initials-Then-My-Last-Name-Sounds-Cool" so seriously.

J.P. Rainburger is saying anything and everything to try and force the will of his communistic, clone theory upon us.
XP is a farce. In the end, good developers make good code, and good managers can handle good developers. It's always been that way and will forever be. Believing in XP is like believing that you are a machine.

You might as well slip into a cocoon and hope that Keanu Reeves gets you out after the Matrix is solved.

| Generally, in our work environment anybody can start
| working on any story/task at any time.
| </Foster>
|
| That last sentence scares the hell out of me. Let me get
| this straight - you have _no_ dependencies in any of your
| projects? All stories/tasks are completely indepedent?

Of course we do, I never said we didn't. I did say that it's
*generally* not a problem that causes people to be idle for
days (weeks would be totally out of the question). The dependencies are reduced greatly through good design and some of the techniques you mention below.

| Or is this the case of "everyone codes indepedently,
| writes drivers for the missing parts, and we integrate
| later"?

Almost, but not quite. Yes, we do design the code to be highly testable and that naturally leads to it being modular. Almost every part of the system can be tested and developed (in that order) independent of the others (once the shared object interfaces have been defined). That modularity allows us to have more concurrent development activities that we'd have otherwise.

| If the former - well, I've never seen such a system. If
| the latter - that's integration hell. Is there a third
| option here? If so, I don't see it.

The third option is write modular, highly testable code and integrate *now* rather than later. Instead of doing a "big bang" integration after weeks or months of development, integrate frequently, maybe 5-10 times a day. Sounds "extreme" doesn't it? Maybe. But it works great for us.

<Foster>
Almost, but not quite. Yes, we do design the code to be highly testable and that naturally leads to it being modular. Almost every part of the system can be tested and developed (in that order) independent of the others (once the shared object interfaces have been defined). That modularity allows us to have more concurrent development activities that we'd have otherwise.
</Foster>

In my experience (and that may not be applicable to your environment, I concede), as the complexity of a system grows this sort of approach becomes less and less tenable. The problem is the exact semantics of those shared object interfaces. For simple systems, the semantics are plain for anyone who can read an interface definition. For more complex systems, there can be _alot_ of nuances where the "other side" of the shared interface can have a wide leeway in how it does things - and where these nuances affect the externally visible state of the system. In plain language, interfaces in today's languages aren't expressive enough to nail down an exact specification. And this means that what _you_ think the interface means won't necessarily match what the other guy thinks it means.

In short - for simple systems, this isn't a big deal. In larger systems, the bulk of the time can be spent trying to connect these indepedently developed pieces together (e.g. integration hell). In fact, you've described pretty much what I try to avoid at all costs in a software project - people coding inter-related pieces in parallel with no real physical link between them, just fake drivers and facades. And with the phrase "Don't worry, we'll hook 'em up later"....

Perhaps this works for you. I've tried it, and it doesn't work for me. That's why I pay alot of attention to dependency analysis up front, and try to schedule things so that developers are hitting real code on the "other side" as often as possible. This is a very long winded way of saying "Don't integrate often - stay integrated constantly, or as close as you can manage".

Yes, teamwork really requires communication, not just working on the same project. Pair programming is just a more intense (extreme) instance of teamwork. If you're doing it right, trying to work together rather than display your brilliance, the communication can be amazing. If you're doing it right, changing the pairings all the time, the communication covers the whole team. Such promiscuous pairing has the secondary benefit that you don't have to spend long stretches of time with that person that rubs you the wrong way. Of course, if most people rub you the wrong way, it won't help. ;-)

"Even if both developers have similar backgrounds..." In my experience, there's more benefit from having different backgrounds. This brings a wider variety of viewpoints and solutions to bear.

"you will have different ways of solving the problem." This is a feature, not a bug. Talk about those ways. Is one simpler that the other?

"it's going to take a lot of discussing before reaching that point." Don't discuss the alternatives forever. If two alternatives look reasonable, pick one. Say, "let's try this one and see how it goes." If it's not looking as good in an hour, roll back the changes and try the other. You don't have to make a perfect choice all the time if you're willing to admit a mistake and try something different.

"If you are slower, the growing unrest and impatience of your partner will eventually get to you." Try saying, "Why don't you drive for a bit."

"If you are faster, you will be squirming on your seat and wishing you could take the keyboard away from the slowpoke" Try saying, "May I drive for a bit?" But most of all, relax. Speed of development is more than speed of typing. The non-driving pair should be looking at the bigger picture rather than just the text-entry of the driving pair. If there's a bunch of text to be entered, though, by all means let the faster typist drive for awhile.

"If you are using a text editor and your partner is using an IDE" Try the IDE. It's amazing how quickly you pick up a new tool when someone next to you can remind you where to find a particular feature. It's much better than having to look it up in the manual.

In summary, pair programming is for people. If you don't get along with people, it's not going to work well for you. I suggest that learning to get along with people is a better long-term solution than denigrating pair programming.

With PP, those kinds of exchange are continual. I learned more in three months pairing with good programmers than I did in six months learning on my own. Why? Because I learned what I needed to know when I needed to know it, accounting for 50% of what I learned; then I had enough time at the end of the day to learn the other 50%.

Amazing! Less waste means more productivity and more fun. It's just that simple.

One of the keys to learn and to like Pair Programming is to learn with someone who does (or did) it and love it.

Learning Pair Programming is hard when no expertise exist within the pair or in the team.

Trying to pair program 8 hours a day from the start is not a good idea.

Start small: 15 or 30 minutes a day and gradually go up to 5 hours a day (Max). (The rest of the day is anyway taken by reading email or exploring some technology. It is not wasted time.) My experience just say it is almost impossible to pair program 8 hours a day 5 days a week!

Do not forget to pair with other people within your team (change a least once a day).

Is it absolutely normal to have a lot of exchange when you are new to pp with another person (even if you know that person pretty well). The more your pp with that person, the more you "learn" the other person. And then, the exchange are more efficient. You do not have to tell so much to express thing. (I agree, learning to work with another person maybe hard for some developers).

Reflect and exchange on how your are doing within a pair. After few months working with one person, I introduce this mini feedback question after one session of pp. I discovered that person was not very confortable with working with me when I was sitting at her left side! This could have been discovered after few sessions if we had used feedback...

Please, take a look a the marvellous book: Pair Programming Illuminated by Laurie Williams. A lot of typical behaviour are addressed in the book with pratical answers.

In summary, Pair Programming:
1- You have to learn it
2- You will have to learn it a little bit again with a new person
3- Good news, practicing it makes easier to pp with newcomers
4- Reflect with your partner after pp session. You will simply accelerate the learning
5- This is part of team building, the social side of XP...

The simplest and most direct sign that Pair Programming is working is similar to the most direct sign that your workout is doing something for your body: you feel the beautiful pain.

If you are exhausted Friday afternoon to the point of almost being useless, then you have done some good pairing. Of course, I mean "exhausted in a satisfied way" and not "exhausted out of exasperation".

If you don't feel the beautiful pain, then that doesn't mean that PP isn't working; but if you do fell it, then likely it does work.

<quote>
The studies have shown that pairs inject about 15% fewer defects and spend 15% more calendar time doing it. The result is a little more up-front cost in exchange for larger savings in later phases of a project. Go to http://www.pairprogramming.com for the details.
</quote>

I would love to see similar numbers coming from another place than the reference site for pair programming :-)

More seriously, and to answer the general comments about the radical opinions expressed by Chiara and myself: it is common in the weblog community to use XH ("extreme headlines" :-)). It's a standard practice in journalism to use sensationalism to hook readers in, but if you read more carefully, you will often realize that the content of the entries are usually more reasonable than their lead-in.

My goal was not to disparage XP in general and pair programming in particular, but to voice some of its aspects that concern me and see what the community has to say. So I thank Dion for exposing this to a different community than the weblogsphere this time.

I think both supporters and enemies of XP programming will learn something from these threads, including myself. If you want to promote XP in your company, I think you need to be aware of experiences such as Chiara's or points such as those I raised myself. And if you don't like XP, you need to read Kent Beck's book because it covers so many different grounds that I bet you will find yourself in agreement with more than just one of them.

In two words, educate yourself. It's the only concept that I think everyone will agree on.

<quote>
The studies have shown that pairs inject about 15% fewer defects and spend 15% more calendar time doing it. The result is a little more up-front cost in exchange for larger savings in later phases of a project. Go to http://www.pairprogramming.com for the details.
</quote>

I would love to see similar numbers coming from another place than the reference site for pair programming :-)

</quote>

This really bothers me, the smiley notwithstanding.

Who do you expect to publish studies on PP? Sure it will be people who are pro-PP. If someone is anti-PP, they're not going to waste time researching it; and if they did, they may be tempted to hide their results because the results contradict their assumptions.

THEREFORE

If you mistrust research results from the PP community, then you will never be swayed by research. You can be closed-minded if you want, but I think that's a mistake.

it is fairness. Does the PP site post studies that show PP does not work? Probably not and I'm not sure that they should. However, I will always take what advocacy groups say as just that advocacy. We don't take a vendors word for fact when they start comparing products. We wait for other to verify. I suspect that the same common sense applies here to PP and to XP.

Why do you have such issues with getting a neutral source? Or even anecdotal sources from say, industry companies that have tried and succeeded/failed?

Does it annoy you when some research group releases a study that was paid for by so-and-so, and it just so happens that they got a good review?

If not, carry on. But I think Cedric and I just would like to see some independant confirmation of the statistic. Especially when they theow out a hard number like a percentage the way they did.

On top of that, anyone who ever took a statistic class knows that even a hard, independantly found percentage is a useless without other knowledge like standard deviation and variance. If the Std Dev was 20%, then 15% means nothing. Do you really think they have hard numbers for this even in the advocacy site?

I'd be even more interested to know what variables might cause variance in this methodology? Workplace setting? Time in pair programming? Breaks? whatever?

<quote>
Why do you have such issues with getting a neutral source? Or even anecdotal sources from say, industry companies that have tried and succeeded/failed?
</quote>

I don't have an issue with it, I just doubt the existence of such "neutral sources". I'm asking the OP to name a neutral source from whom such a study would be accepted, good or ill. I haven't seen that response yet. (It may be there, but I haven't seen it yet.)

As for the StdDev, I agree. I don't remember the number off the top of my head, so I can't comment. I'm pretty sure that it wasn't as high as the 20 percentage points you mentioned. :)

<quote>
I'd be even more interested to know what variables might cause variance in this methodology? Workplace setting? Time in pair programming? Breaks? whatever?
</quote>

2. Patience. The less patient the individuals, the less effective they are at PP. I'm guilty here: I sometimes go too fast, which takes away the opportunity for my navigator to correct my erroneous trajectory. I noticed this and worked on it. I'm better, now.

3. Length of session. I observe an optimal session length of 1/4 day or so. More and personality compatibility becomes the dominant factor; less and you can't get anything interesting done.

4. Workplace setting. Those not comfortable with the room see PP as a constant reminder of their lack of comfort. On my last project, I liked the room, but others didn't. It probably caused minor problems that I didn't realize at the time, since I didn't know that they didn't like the room.

Cedric: your weblog entry states, "Don't pair on production code." Clearly, managers ask people to pair on critical parts of production code near the end of the release. We've all done it, I'm sure. Are you truly saying that we ought NOT to pair in this situation, in particular?

IMHO the big secrets about programming (coding and management) were discovered a long time ago, and they are all based on common sense, and they are not changing. One of the big truths: there is no silver bullet. If you are not aware of this, and you think in terms of silver bullets, your project is at risk no matter what methodology you use.

Perhaps the reason why pair programming is beneficial and necessary in XP is that it keeps you honest when you are writing the tests. And if you write the tests first, then you will probably have no bugs. So the schedule will shrink even though the developer's productivity may be arithmetically lower.

This topic has focussed primarily on pair programming and that's understandable since it appears to be the most controversial practice from a programmer perspective (and it was the primary topic of the referenced blog entry). However, there are other areas of XP that are just as questionable. One of those is the notion of using abstract "points" and point-based "velocity" to estimate effort and track progress.

Kent Beck, one of the founders of XP, has even recently referred to this technique as "voodoo" and asked that XP practitioners experiment with using time-based estimating and progress tracking.

I've seen various claims that "points" make it easier to estimate, that developers are afraid of time estimating but they aren't afraid of points, that points are more accurate, and so on. But I haven't seen any evidence to support the accuracy or effectiveness claims. Maybe it eases some developers fears, I can't comment on that claim since I'm not afraid of time-based estimating.

The most common argument I've seen for points is that it isolates the developers and their estimates from management. My interpretation is that the abstract points obsfucate the estimates to the extent that the poor befuddled manager cannot determine if the team is working at peak performance or even on schedule or not during an iteration. XP proponents claim that using a previous iteration's points as the estimate for the following iteration (known as "yesterday's weather") provides accurate estimates. That may be true if a team is delivering very similar software functionality every iteration so that the past estimates support future ones. However, just as (metaphorically) "yesterday's weather" works better in Phoenix (I predict it will be sunny like yesterday) than other places, one would expect the success of this approach to vary widely as well.

Recently, I've seen a recommendation from a lead figure in XP suggesting that if velocity is varying wildly from iteration to iteration then it's ok to average over several iterations. What's the point of this? So the average is relatively stable as one would expect, but the estimates from iteration to iteration are still wildly inaccurate. It just doesn't make sense, common or otherwise.

To be fair, XP teams will often tie their "points" to some form of "ideal time" (pure programmning hours). When ideal time is adjusted for overhead (XP calls it a "load factor") then you have clock time again. In this case, it seems that the use of the word "point" makes the developers believe that the management can't manipulate the team by making them work twice as long. The developers feel they can respond by saying "we only have x points for this iteration, no matter how many hours we work". I'm guessing that most managers are smart enough to see through this ploy. I do believe it's foolish to make a team work twice as long in the mistaken belief that they will be twice as productive. However, I also believe that the best way to deal with a difficult management is to work with him/her directly and honestly rather than trying to manipulate them with concepts like "points".

I was on a team that struggled mightily in this area, but I believe the problem was that we were trying to sell XP within a larger organization, so we felt pressured to "show results". Rather than listening to what velocity was trying to tell us, we kept trying to increase velocity. It's a lot like Kent's recent work on Software In Process: don't try to improve the metric; rather listen to the metric trying to tell you that you're in trouble...

I have tried both time-based estimates and points. The big problem with time-based estimates is that every day is not created equally. I have phone calls, meetings, my computer barfs, my cats barf... any of a number of things can happen to turn my 8-hour day into a 4-hour day. Over time, this evens out, but by estimating (and talking) in "points" (not time), there isn't the in-built assumption that 1 hour is really 1 hour. I also don't have to futz with figuring out how long my average day really is (it is 5.7203 hours or 4.981029 hours?). All that matters is this: how much work can I expect to get done by Day X? Ah, about 12 points. I'll sign up for 12 points.

If the team fixates on "speeding up", it'll miss what a low velocity is trying to tell them: for example, maybe the IDE is no good; maybe we need faster machines; maybe we need better chairs; maybe we need to get rid of Fred.

I find velocity to be very effective at converging towards predictable deliveries.

| The big problem with time-based estimates is that every
| day is not created equally. ... Over time, this evens out,
| but by estimating (and talking) in "points" (not time), there | isn't the in-built assumption that 1 hour is really 1 hour.

This is what I find interesting. Our team has never made the assumption you describe (therefore, it's hardly "in-built"). Nobody, developer or manager, has any problem understanding that an hour of programming time (what XP calls "ideal hours") does not necessarily occur in an hour of clock time. They also have no problem understanding that 8 clock hours does not equal 8 programming hours when meetings and other overhead are taken into account. It seems so simple that I am amazed that some people can't grasp that concept.

| I also don't have to futz with figuring out how long my
| average day really is (it is 5.7203 hours or 4.981029
| hours?). All that matters is this: how much work can I
| expect to get done by Day X? Ah, about 12 points.
| I'll sign up for 12 points.

What is the difference between tracking how many programming/ideal hours you worked in an iteration vs. how many points? One difference is that the ideal hours actually are tied to some objective measurement. IOW, the clock. With abstract points, the measurements are much more subjective. The only objectivity comes from using past experience with similar stories/tasks to estimate the points for this task. This approach works well is many of your stories are very similar to previous ones, but in most of the environments I've worked within, many of the stories are relatively unique. I am not a cookie cutter programmer. However, I realize that some companies may be a better fit for this technique.

| If the team fixates on "speeding up", it'll miss what
| a low velocity is trying to tell them: for example,
| maybe the IDE is no good; maybe we need faster machines;
| maybe we need better chairs; maybe we need to get rid
| of Fred.

This is the beauty of the clock-based approach. It points directly to what needs to be done to "speed up". You must make better use of the available *time*. There is only so much of it. A rational person will ask, "where is my time going?" Am I spending too much time on the phone? If so, why? Can I communicate more efficiently. Am I going to too many meetings? How can I reduce the time I spend in meetings that are you useful to me? If my computer is "barfing" or the IDE sucks, how can I convince management to improve our equipment (by showing the cost in terms of time and the resulting productivity impact is a good start). So, my point is that with the time-based view the desire to speed up will lead directly to these questions.

Basing velocity explicitly on ideal hours also can result in predictable deliveries. In addition, the team's development plans are presented in a language that almost any manager can clearly understand. This not only helps to sell the overall development process (XP) to management but it helps them sell it to *their* managers. No hocus pocus or voodoo has to presented to the upper management. In today's layoff-happy corporate environment, I suspect that most managers will not try to convince directors or VPs on planning using abstract points (or "gummy bears") as an estimating technique.

I never heard of XP until someone asked me about it in a job interview. After the interview, I found Ron Jeffries' book "XP Installed" and couldn't put it down. While reading the book I realized all the mistakes we were making on my current project and all the mistakes we made on my previous projects. I ended up getting that job and became one of the leaders of the project. We implemented as much XP as possible, but not everything. I saw more productivity on that project than any other that I've ever been on. I think a lot of it is due to the XP principles we used. I've been using XP ever since. I've never used pair programming (I'd love to try it some day) and that's the point I want to make: You don't have to use ALL of XP to get benefits. Use whatever you can. If you just use one XP principle it will improve your process.

I don't participate in flame wars, so let me just say XP worked great for me on several projects. The most important thing isn't that you use XP, the most important thing is that you use A PROCESS. As for me, I'm forever grateful for the guy who asked me about XP in that interview, and to Ron Jeffries for his wonderful book. I really feel XP changed my professional career.

<I ended up getting that job and became one of the leaders of the project. We implemented as much XP as possible, but not everything. I saw more productivity on that project than any other that I've ever been on. I think a lot of it is due to the XP principles we used. I've been using XP ever since.
>>

This is the most cheezy story i have ever read. U can create a movie out of it. U can have Ryan in the lead role.

Just be normal in this forum. Its not easy to fool some smart people out here.

Hey Ryan
I think u really are a baby.
Why r u trying to convince everyone abt XP and
defending it so much.
U like it , u use it and be happy.
When u grow up, u will know what
XP has done to u. :)
Take a chill pill now
... and ask ur XP partner to take one too :)

Not really sure what that means, but I will try to decipher your gibberish...

First, I don't think you convince people about XP. That doesn't even make sense. Do you mean convince people to "use" XP? If so, I am not trying to convince people to use XP. You can use it. You can not use it. I could not care less either way. I even said as much earlier. I also said PP has its advantages, but it is certainly not for everybody.

Also, I am not defending it. I never said XP is the right way or the best way. It is *a* way to develop software that I happen to enjoy practicing. What I am trying to do is "set the record straight" on some things. If somebody says XP sucks because it does not allow for QA, I will question that because it is wrong. I don't see anything wrong with that.

However, if you think I have been trying to convince people to use XP, please show me where I said that. Other than that, I would appreciate it if you would take yourself and your dumbass pal Larry and shut the hell up (but I know you can't).

Yes, that's right, I don't support helping my fellow programmers if they make a request like: "Can I sit next to you for 8 hours a day so that I can learn how to code instead of taking it upon myself to learn on my own?"

XP is for lazy people. The personality of an XP supporter is the same as that guy in your class at school who always jerked around, day in day out.... but when it came down to writing the test, then suddenly this moron would be copying off of everybody, and begging to be included in the study groups.

That's what XP encourages --- lazy people who believe that they can justify their laziness by telling their manager that "XP is a radical new approach to quantifying productivity gains".

Sorry Ryan, but's that's all just a bunch of crap and you know it. I could do the work of 10 XP "Pairs"; how's that for some heavy ROI?

<Leonard>
XP is for lazy people. The personality of an XP supporter is the same as that guy in your class at school who always jerked around, day in day out.... but when it came down to writing the test, then suddenly this moron would be copying off of everybody, and begging to be included in the study groups.
</Leonard>

I don't completely agree with this characterization, but there's a big kernel of truth in there. The problem I have with XP, and PP in particular, is that it largely ignores human factors and - dare I say it - human nature. There are going to be projects that have one or two lazy developers - and in PP, those lazy developers are going to get credit for work done by (literally) their better half.

And as someone else has said - just because you don't pair program well doesn't mean you're a misfit or lack social skills. It just means that you're not good at pair programming.

And a note for the XP proponents making statements about non-PP people being miserly, lone wolves with crappy code and the personalality of a rabid dog: thanks for showing how eXtreme methodologies and ideas can twist people towards absolutist thinking. Just because I don't pair program doesn't mean I don't work with people. In fact I collaborate with others often on projects. I've just found that the pair way is ridiculously inefficient and stressful, and that there are much, much better ways to get the same positive effects without the inefficiencies and the stress. You don't have to sit next to each other and "pair" to collaborate. You can work with someone and not get annoyed that they type too slow/too fast. I can bounce ideas off people and check out some dicey code without being joined at the hip with them.

And frankly - some of us like to listen to music, multitask with other things, etc while we work. Should I sacrifice all my little pleasures at work to get the unsubstantiated benefits of pairs? I think not.

1) What if s/he stinks? No seriously, what if they have bad body odor? I would quit if that was the case. Is that very efficient? No.

2) What if s/he is a big fat baby like Ryan, who obviously wants to spend all his time trying to convince the REAL programmers that their anti-social freaks just because they won't give all their skill to him for free? Would I want to sit next to Ryan all day while he whines, "WAIT!! WAIT!! How did you know to do that?!?!? You're so smart! Show me more!" Screw that!!! Tell Ryan to go pick up a book and read for Chris'sakes. There's no free lunch in this world, you XP freaks.

3) What if your little pair buddy is sick one day? Does that mean you stay home too? HAHAHAHAHAHA, that's not very efficient, is it? But hey, you're not allowed to code unless Ryan is there, so I guess that means I can play Age of Mythology all day while Ryan is home puking in the toilet.

Are you sure that you have the permission from your XP group to spend your time on this board and post messages? Did you ask your bum buddy if that was all right?
I'll bet that he secretyly despises you! I'll bet he tells on you!!!

Those tips are for people who are purposely trying to discredit somebody.
That's not what I'm doing, I'm merely pointing out the facts of XP.
Nobody's talked about personality, bad breath, sick leave, or skill-sucking. All they mention is how cool it would be if people were like robots and wouldn't mind being merged to each other 8 hours a day (Any more than 8 hours, and you have violated one of the tenets of XP!!! Beware!!!).
So Matt Olson's analysis (which I admire by the way) does not apply here.

And besides, I like the Tragically Hip, dammit. Although I will admit that they are getting less relevant and less entertaining. "Thugs" was their last great song back in the mid 90s....

Leonard, when my team pairs, everyone gets to know the entire system. Before long, anyone can do anything reasonably competently and many of them become experts.

When I get sick or take vacation days, someone else can fill in for me and do a good job. Nobody calls me in a panic because I'm the Only Guy Who Can Do It.

I want to do PP so that I can be allowed to get sick or go on vacation.

Incidentally, I think "bum buddy" is a clear example of "trying to discredit somebody", so please spare us your hypocrisy and stick to debating the issue. Thanks. (And by the way, don't turn the ad hominem attacks on me. I'm wearing a stupidity-resistant suit.)

Sweet... but inefficent! I thought XP was all about efficiencies. Oh well, so much for that thought...

It's also inefficient to work with this "Customer" person. This person sits around all day writing requirements on little yellow cards and handing them over to the Pair Programming team. The team then has a gab session with the "Customer" and talks about how to code out the requirements and test them in an iterative process.

It's a ridiculous waste of money to hire the "Customer". If your Project Manager or Executive Sponsor is not capable of communicating requirements to the development team, well then hey, you've got bigger problems than wondering whether or not your pair buddy bothered to wear any underarm deodorant today.

Extreme Programming is the result of companies hiring people straight out of school for 5 bucks an hour and throwing all the crappy work ethic and sub-standard production that results from these poor hiring decisions onto the development team's shoulders.

That's great that some of you more experienced types don't mind "Trying Something New" or whatever, but it's laughable that XP is being pushed as this New Industry Standard for production efficiencies --- it's not! It's just the old capitalistic characteristic of trying to offload inefficiencies away from upper management onto the grunts. It's a shame that there are obviously people out there who have bought into this scheme.

There is nothing that XP can do that a qualified Project Manager and a qualified Developer can't, period. And none of these silly rituals that are being passed off as tried, tested, and true methodologies. What silliness, and all who support it.

"Sweet... but inefficent! I thought XP was all about efficiencies. Oh well, so much for that thought..."

You know, this is just the kind of verbal hocus pocus that would have dismissed Edison in Menlo Park or Henry Ford's radical production line implementation or Kelly Johnson's Skunkworks at Lockheed. We programmers have learned to bank on our intelligence so thoroughly that humility and openness to new ideas can be quite a stretch.

How about, "I don't see how this could be efficient"? How about coming to grips with the concept that layers of management between businesspeople and programmers actually impedes clear requirements gathering? You want to talk about silliness, how about the stubborn position that complex systems are best built by making all the design decisions up front (as if business realities don't change during the implementation of these beasts)?

I feel sincerely badly for Chiara and the miserable experience she had with her XP project. Interesting that she mentions that none of the programmers would "rat" on the bad ones... So much of XP is about clearing up communication and she was stuck in world where the so-called solution hid the problems even further. But I don't know of any methodology that can withstand blind management and mute developers.

I find it very amusing how some humans believe that labor can be dragged and dropped.

Two heads are the better than one, efficiency this and that!

Ridiculous --- scientists like yourselves cannot appreciate the intangibles involved with labor. Things like attitude, human spirit, and --- here's a shocker --- personality, will all come into play to throw down your XP house of cards.

I so far have lurked on this conversation, but now I feel it is time to comment. You are absolutely correct that there are many intangibles that interact and effect a team using XP. For sometime, I served as an XP coach for 14 programmers of varying skill on a large software project spanning many months and I watched first hand as 6 powerful programmer personalities undermined my role, the process I was working to install and later act as interlopers with my senior management to get themselves assigned "plum" assignments off the XP team. These personalities did knock down my XP "house of cards". Do not discount the power of unhappy, confrontational and unwilling participants to undermine and scuttle ANY efforts to improve a software development process or apply any order to chaos.

I can make this observation, when the team of 14 used most of XP, we produced a damn good software project mostly on time (just six weeks late) with low defect rates and high customer satisfaction. In fact, by using pair programming, the 6 interlopers passed the maintenance work to the remaining eight programmers with minimal effort. The eight knew the system inside-and-out and I was very proud of their ability to extend and maintain the system for ten months.

The 6 were then assigned development of a rewrite, then replacement, of our existing product with a six month deadline using the development practice of their choice; something akin to a "head surgeon" metaphor where the cheif architect directs and assigns components to each person on the team and moderately strong peer programming environment.

This is the ideal situation, right? Each programmer, a well skilled professional is taking direction from an architect, building as they see fit and collaborating when they are stuck. In fact these people were some of the best, brightest and most productive on the team. Unfortuantely, this group has been unable to match their previous performance and are 1 year past their deadline of 6 months.

I will not be so bold to say, if they had XP they would have suceeded. These people had XP, tried pair programming, unit testing, refactoring and hated it. What I feel qualified in saying is that this "ideal" decimated their chances of suceeding. Say what you want about XP, but it has been my observation that XP focuses development like a laser.

I think you might have missed the point of my experience. Powerful personalities will destroy ANY attempt to improve software development processes if they do not get their own way.

The 6, with their average of 2.5 years of programming experience, seemed to think they knew better than all the rest of the people in the organization on how to deliver a new software product. They completely disregarded what had worked and told management, "Trust us. We will deliver this product in 6 months written in a brand new language". Eighteen months later, their product is still not ready to sell. They approach the 6 used, chief architect assigning components with peer programming, was a failure.

<Nettleton>
The 6, with their average of 2.5 years of programming experience, seemed to think they knew better than all the rest of the people in the organization on how to deliver a new software product. They completely disregarded what had worked and told management, "Trust us. We will deliver this product in 6 months written in a brand new language". Eighteen months later, their product is still not ready to sell. They approach the 6 used, chief architect assigning components with peer programming, was a failure.
</Nettleton>

An average of 2.5 years...that's pretty damn low. What was the high end for experience and low?

If they all happened to have around 2.5 years of experience - well, then I'm not very surprised that they failed. They were all junior guys. If they all were that inexperienced, then shame on management for allowing this to happen.

I just wanted to make sure I understood what you are saying here. You seem to be saying, the work enivornment where a senior architect distributes modules to other programmers with a peer programming environment only works with "experienced" developers; not for juniors. Is that correct? In the experience I shared, the architect had about 5 years of experience and the team average was about 2.5 years.

What most impresses me about XP is almost anyone can do it. You do not need pages and pages of training manuals. You do not have to read all these papers in journals. You do not need to purchase some expensive software or hire a high cost consultant. All you really need to start is a whiteboard, some index cards, programmers, a "customer" and some computers.

If the people using XP are committed and disciplined, then you can make a serious go at it with just the books. If the developers and management are not committed and disciplined (like the people in my experience), XP with completely fail. However, it has been my experience, if you have undisciplined coders and flakey management, they are pretty like to fail in any event. XP with its short cycles and frequent releases would just show that a project is heading for failure much more quickly. I think that was one problem XP was trying to solve; let the business people know early on the project is going to fail so they can kill the project without spending a lot of THEIR money.

<Nettleton>
I just wanted to make sure I understood what you are saying here. You seem to be saying, the work enivornment where a senior architect distributes modules to other programmers with a peer programming environment only works with "experienced" developers; not for juniors. Is that correct? In the experience I shared, the architect had about 5 years of experience and the team average was about 2.5 years.
</Nettleton>

No, not at all. Most likely I didn't explain it very well (I've been battling some ugly distributed messaging timing problems and it's rather distracting :-). Let me try it again from the top...

I advocate an environment where a small team of senior people (possibly as small as one, but it depends on who you've got and the size of the project) control the development. They sort out dependencies, do the view-from-10,000-feet architecture, and monitor progress and give feedback where it's needed. I don't generally believe in "architects" per se, since in software that seems to imply that they don't code. I stick with senior developers.

Each and every person is given a core domain that they're in charge of (possibly more if they can handle it). They're the main guy or gal for that piece. This doesn't mean they own it, but it does mean they know the most about it. They do the heavy-lifting in those areas.

As the project progresses, the senior team coordinates who's doing what, and monitors it. People are swapped onto different areas from time to time - both to keep people from getting stuck in a rut, and to transfer knowledge.

People are also assigned work appropriate to their abilities. You don't put the kid out of college on the multithreaded server kernel, and you don't put the grizzled veteran in real time systems on writing Javascript field validators.

All of the senior people (PM, devs, QA) monitor the project and apply feedback. The senior devs in particular have to review the code being checked in. Not all of it, for sure, but the big chunks with critical functionality. IMHO this should be done whether you're doing RUP, XP, Waterfall or Joe's Methodology and Sausage Factory. You want to take advantage of the senior guys and their expertise, and use them as a reality check directly against the code.

And it scales because a small number of senior devs can keep tabs on the coding of a large number of less senior people. Scales much better than pairs, in fact.

This puts an added burden on the senior people - but that to me is part of being senior. And it also allows you to adapt to the real people on the project in real time. If a junior guy is showing talent beyond his years, you can spot it early and ramp them up to more challenging things. And if someone more senior isn't up to their rep, you can figure out what to do about it.

<Nettleton>
What most impresses me about XP is almost anyone can do it. You do not need pages and pages of training manuals. You do not have to read all these papers in journals. You do not need to purchase some expensive software or hire a high cost consultant. All you really need to start is a whiteboard, some index cards, programmers, a "customer" and some computers
</Nettleton>

The way I develop software, and many people I know as well, isn't XP but still doesn't require expensive software or high cost consultants or scholarly journals.

Your statement above sounds like a backlash against RUP et al. That's common sense to me - that stuff is too heavy weight for most projects. But my beef against XP is that it takes the backlash too far to the opposite extreme of no accountability, no real support structure.

<Nettleton>
If the people using XP are committed and disciplined, then you can make a serious go at it with just the books. If the developers and management are not committed and disciplined (like the people in my experience), XP with completely fail. However, it has been my experience, if you have undisciplined coders and flakey management, they are pretty like to fail in any event. XP with its short cycles and frequent releases would just show that a project is heading for failure much more quickly. I think that was one problem XP was trying to solve; let the business people know early on the project is going to fail so they can kill the project without spending a lot of THEIR money.
</Nettleton>

This is most assuredly a good thing. My point is that you can do this _without_ using XP.

Well, in every case I've seen where somebody said that
XP doesn't work, upon further questioning, it is -always-
found that they didn't really do XP. Usually, somebody
took a few of the practices or even only one practice like
pair programming, called that XP, watched it fail and then
used that as an excuse to say that XP failed. Another thing
that happens commonly is that people hear the titles of the
practices and don't learn about them. They just make up
what they think those titles mean and come up with something
that has nothing to do with XP. Hopefully somebody can do
some questioning here and get some answers. I'm certain
beyond any shadow of a doubt that one of these things has
happened. Of course, there are projects for which XP was
not designed. So far, the only limit I've seen is the size
of the team (more than 20 programmers can be a problem).
Typically, an XP team of 8 can do what a non-XP team of
15 can do. I have productivity numbers proving that in
my environment, XP is providing between 30% and 3TIMES
more value (in lines of code, lines of code touched and
feature/function points) compared to non-XP (such as RUP).
The arguments about pair programming simply don't hold up.
The rant from Cedric is very telling:
"Have you ever tried to sit near a fellow developer and work with her on a problem? If you haven't give it a try and come back when you are done. My experience is that it is one of the most frustrating endeavors a software developer can ever be submitted to. There is so much dissonance in this exercise that the mind reels."
In this rant, Cedric shows that he has difficulty working
with others. Putting on my manager hat (and I do a lot of
interviewing and hiring), I would ask my candidates about
this issue specifically. (Caution: I'm only giving my
opinion and the opinion of the few hundred managers I
know personally). I wouldn't hire anybody who can't work
side by side with somebody else. XP didn't change this.
I asked the same question when I interviewed people back
in 1987 that I do now. This is a critical social skill
and the lack of this skill lowers the value of any
potential candidate. Anyway, enough ranting. I've grown
very tired of the sensational "XP doesn't work" headlines
and I see that this is very similar to the adoption of
Object-Oriented Programming by the community. OO has
pretty much dominated but many people never really got it.
OO is so prevalent that the ones that don't get it aren't
as vocal anymore. I hope that we can do a better job of
teaching XP than we did with OO.

<michael>
I wouldn't hire anybody who can't work
side by side with somebody else. XP didn't change this.
I asked the same question when I interviewed people back
in 1987 that I do now. This is a critical social skill
and the lack of this skill lowers the value of any
potential candidate
</michael>

You are mixing up two very different things:

1) Having social skills
2) Being able to share a keyboard with a colleague

I would never hire someone who doesn't have 1). If they can have 2), it's a plus, but not a requirement (besides, you cannot have 2) in the absolute, you will only be able to pair with certain specific people, and there is no way you can determine this in an interview anyway).

LOL,
This is funny...Social Misfits commenting on socialization with
peers...

The point of of pair programming is to insert different perspectives to achieve a superior result. Check the uber-coder ego at the door please.

Financially: 30 years of late and overbudget software projects leave many people questioning the value of traditional methods. Solution: Send it offshore..at least if its late it's cheap. Thats something to think about..isn't it?

True programmers are cynical &#8211; we all know that. And XP came out as a cynical reaction to all the nonsense methodologies that were tried on us in the project management lab.

XP was meant as a down to Earth recipe for developing sofware. Do this, do that and your project will be successful. But in reality, XP is nothing but a cynical joke, a reaction to the lack of efficiency in the software industry. And like it&#8217;s predecessors, XP is yet another non-sense way of doing things and it completely misses the point.

The point is we have to think before we act. No matter what we&#8217;re doing, thinking cannot be replaced by a recipe, nor by a methodology, nor a process nor by anything else.

So don&#8217;t make XP, OOP, AOP, whatever, don&#8217;t make them your belief. Instead doubt them, deconstruct them, find and understand their principles. Then apply all this wealth of knowledge constructivly and find out how things can be done in each particular situation. Think, adapt, create, enjoy &#8211; don&#8217;t just blindly apply a method saying "XP is the best thing since sliced bread, from now on this is my mantra .... "

I find these opinions disappointing, because usually I'm in agreement with Cedric. I don't find these comments to be objective criticisms -- they're more like "it's not for me".

That's quite all right if "it's not for you". But let's be clear: Cedric works for a software vendor, with a product release cycle. This is a different environment than what XP was evolved for, and may not even be appropriate for Cedric's environment anyway. I am at odds with XP proponents that suggest it is the "One True Method". It is not.

But XP is valuable, and I contend with several points made:

"You cannot convince anyone in the manager and above layer that it's worth spending the salaries of two programmers to achieve the job of one."

There seems to be this paradoxical argument that XP is somehow "manager-imposed" on one hand, and "managers will never accept it" on the other hand.

XP evolved out of a specific project at Chrysler, the c2.com website, and the experiences of many Smalltalk developers over a decade of development. Pair progrmaming came out of Kent Beck & Ward Cunningham's experiences working together. XP didn't come from management, but there also is a lot of management interest in it. Cedric, I would suggest talking to your consulting wing a bit more, I think you'll find XP, or at least "agile methods', are being accepted by management (for better or for worse) more than you think.

"Have you ever tried to sit near a fellow developer and work with her on a problem?"

Yes, regularily for the past 3 to 4 years. I program solo too, though. I enjoy both, though there's a different sense of accomplishment when you program in a pair -- more like working with a winning team than painting your masterpiece.

"My experience is that it is one of the most frustrating endeavors a software developer can ever be submitted to. There is so much dissonance in this exercise that the mind reels."

I am saddened you feel this way, but I would suggest that your experience, while common, is not universal.

"Most likely, you are not working at the same pace as your XP partner. You are either slower or faster. If you are slower, the growing unrest and impatience of your partner will eventually get to you. If you are faster, you will be squirming on your seat and wishing you could take the keyboard away from the slowpoke so you can get things done, at last."

It's not that big of a problem. It does require a certain emotional maturity. It's probably the closest thing to Gerry Weinberg's "Egoless Programming" that's come out in 20 years.

Might I suggest reading "Pair Programming Illuminated" by Laurie Williams for some examples of how people deal with these issues.

"I could go on and on and dissect Kent's book chapter by chapter."

I would appreciate this, if you think this method is so evil. Because all I see right now is a knee-jerk reaction against pair programming -- not XP.

I find it fascinating that veteren developers tend to either embrace XP on first glance, or cast it to hell. I embraced XP at first, and became wary of it later, now I think I have a good understanding of where XP is useful and when XP is possible. So, I do not believe that it's the "True and Only" methodology. I don't even think Kent Beck ever claimed that.

There's a whole slew of methods coming out of the Agile Alliance that have similar value systems, and do not necessarily carry the same practices as XP.

On a closing note, one thing I note in these criticisms is that they are not holistic criticisms of the process, they're purely emotional outbursts relating to 1 or 2 of the 12 practices of XP. They don't also seem to criticize the value system that XP carries at its core.

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

The whole point of XP and other agile methods are for projects that have small teams, working in the same area, that can have a collaborating customer (marketing group, etc), and where the requirements change regularily.

These values grew out of developing business software -- where business conditions change, minds change, people change, and whole management groups change. Perhaps it's not as appropriate to product development, but to wholesale reject its utility because of distaste for 1 practice is the epitome of intellectual irresponsibility.

Whew! It took some time to read this entire thread. Fortunately, I was able to skip ahead by skimming over the over-emotional and outright abusive comments.

Interesting trend I noticed, is that those defending XP also seem to be the same people pointing out its real weaknesses. Maybe instead of setting your heel against it and refusing to listen to the potential benefits, it might be worthwhile to at least consider the possibilities.

I work alongside Ryan Breidenbach and I'm not comfortable with the idea of pair programming myself. I LIKE figuring things out on my own and I LIKE working on things. I'm kind of a loner by nature and so the idea of pair programming is not exactly thrilling to me.

However, that doesn't mean there aren't benefits and I won't shun working in a pair even if it is contrary to my nature. There's not always time for me to learn something myself and that is true of my co-workers as well. All of us on this team have areas where we are stronger. Besides which, as much as I prefer to learn things hands-on, if I have deadlines pressing or if I want to move on to a future project that looks more interesting, it just makes sense to pair up with someone and knock it out rather than muddle through.

We don't always work in pairs here. We have two pair programming machines that is shared between 5 developers. Recently, Ryan and I were both assigned to a project and I also had another project to work on at the same time. I ended up having to finish up most of it at my desktop while Ryan paired up with another developer to be a second pair of eyes. The other developer had her own project but was waiting on a response from a third-party vendor.

The ability to switch off and also to have something to do when you'd routinely have downtime seems more productive to me. It's potentially hazardous to have 5 different developers doing 5 different projects, all of which may overlap and possibly break each other. There is no perfect source control or QA process.

Using pair programming, we are not missing deadlines, we often have extra time to implement new features or do testing BEFORE the code goes to QA. We are getting just as much done, if not more, than we were having 5 different developers working as autonomous units.

Do I enjoy pair programming? No, not really. Am I willing to do it to improve efficiency and productivity? Wow, I'd be the worst employee in the world if I didn't want to be more efficient and productive. You can see the benefits of pair programming here at the office. We didn't start out in an XP environmet, so the benefits have been very obvious since we changed our methodology.

There are other aspects of XP that we do better than others. Ideally, you want to incorporate all the tenets of XP in your workplace should you choose to use them. Unfortunately, very few workplaces are "ideal". I see certain aspects of XP we are not benefitting from that we probably should be. I'm sure Ryan and my co-workers would agree.

The beauty of XP though, is that it's flexible. You can take what works for you and toss the rest. I don't recommend it, but if some of the concepts seem to outlandish for you, that doesn't mean you have to throw them all out.

No one says you HAVE to use XP either. I admit, it may simply not work in every office. However, saying it has no benefits is certainly not true. I would not want to go back to the way we used to develop apps around here. We had shorter development times, but spent the "saved" time fixing bugs that got further along than they should have.

No one is a perfect programmer, but two different people will tend to make completely different mistakes. Having that extra pair of eyes to catch mistakes you'd make but they wouldn't, or vice versa, is a huge benefit.

It's not two programmers doing the work of one. It's two programmers doing the same amount of work in nearly half the time.

But hey! I'm glad some of you seem to think you're qualified to criticize the skills of one of my co-workers despite never having worked with him yourself. Let me tell you another secret about pairing up. We don't always get along here and the 5 of us are fairly diverse. However, conflict can be a good thing. Sometimes the only way to reach an ideal solution is to compromise between two extremes. If you can remain professional and willing to accept that your way may not always be the "right" way, then you'll definitely benefit from pairing up.

So essentially you're telling us that you don't enjoy XP, but because you're getting paid to do what management tells you, you have learned to take it like a man.

OK, great, thanks for your honesty, and I mean that seriously.

I can't fault you or Ryan for your company's approach, which is basically forced communism, but hey, times are tough and not all of us are as lucky as others to have decent management.

I now sympathize with you and Ryan thanks to your prose. I think that the best thing that could ever happen to your guys' company is that the Project Managers and Directors "pair up" so that they can see how it feels. Hey, don't laugh --- if two brains are better than one over there, then why not apply the template up to the top? It's all about the greenbacks, right?

I do like XP, pair programming is an aspect of it that I find outlandish. I do it because I see the results though.

Maybe it's hard for others to deal with, but I'm willing to admit that just because I don't like something or it seems outlandish doesn't make it bad. Anyone who has read "Green Eggs and Ham" should be able to understand stubborn refusal to try new things is often more work than actually giving it a go.

Pair programming is against my nature, but sometimes old habits work against you.

I'm not going to get paid less if I refuse to pair off, and I'd like to think that we're not so petty that we'd fire someone who doesn't participate. Evaluations are done on performance, and if my performance improves using XP then yes there could be some monetary compensation there.

XP had some concepts I really liked, so I was willing to try it. That also meant trying out some concepts that other people might work out well. In the end it's not about money, though XP can save you money. It's about being as productive as possible.

It's worth repeating though. Pair programming is not about having two people completing the same task in the same time. It's about having two people completing the same task in half the time with fewer errors.

And trying XP, really TRYING it without determining it will fail before giving it a fair chance, means you may have to do things that you're not comfortable with or establishes what you may have been taught is the "right" way.

<Jason Cox>
It's worth repeating though. Pair programming is not about having two people completing the same task in the same time. It's about having two people completing the same task in half the time with fewer errors.
</Jason Cox>

In your original post you seemed to have taken a different stance then the one presented here in your second post. What am I talking about? In your first post you seemed to be leaning towards Pair programming being of benefit to very particular and complex items of a project. Meaning those pieces of a project that present the greatest risk or conceptual complexity.

I'm not gonna buy into the fact they these two people working on the same thing are going to be more productive to the project timeline than them working separately on two issues.

But I don't think the essence of pair programming in these instances should be about comparing productivity. It should be about tackling items that are on the project critical path.

I have some personal thoughts how it should be used.

1. Develop a rating system, albiet abstract that can be used to identity items that may qualify as being benefical to be done by a pair.

2. There is no need to have a two highly trained and skilled individuals carry the torch through every tedious line of code. Working in pairs shouldn't be an all or nothing thing on the macro level and neither should it be on the micro. A pair should be able to break down the problem and come up with an attack plan and design. This includes what it is, what it does, and what its interface is. One of the pair should support the torch carrier through rocky parts and up the hills but he should then be used to tackle a manageable issue on his one and let the carrier run with it.

3. At no point ever (opinion!) should people of different skills be paired. Or to further qualify, never pair two of different titles together. You'd be setting yourself up for failure here I believe. Why, would I say this? Well for the first reason I revert to my other two statements. Pair programming isn't a damn jackhammer, it's a scapel and this isn't an after school special. Critcal items should be handled by individuals of equal talent. Second, you may have individuals who are of equal talent but one may be senior in rank due to other factors. This puts unfair weight in one pair of hands and you cannot expect an object outcome. And will mostly likely result in resentment in the junior ranked individuals losses on more points than she/he wins.

Matthew, that was very well put and a very credible analysis of pair programming IMHO.

From my perspective, I'm not against people working closely together. As you said:

<Matthew Cox>
A pair should be able to break down the problem and come up with an attack plan and design. This includes what it is, what it does, and what its interface is. One of the pair should support the torch carrier through rocky parts and up the hills but he should then be used to tackle a manageable issue on his one and let the carrier run with it.
</Matthew Cox>

It's a great idea to have two people working on a major "chunk" of the system together. They can bounce ideas off of each other, have intimate knowledge of how thing works (or is supposed to), and support each other when sticky points or reached. Or, as you said, if they're unbalanced one the more experienced person can get the other one out of a tough patch.

But this isn't the same as pair programming - and in fact I think it's vastly superior to it. I often work with people in this manner. At times we may be acting as a pair - one guy banging on the keyboard with the other looking over their shoulder - but this is a rare occurence. Most of the time, it makes no sense for two people to be working on exactly the same task.

The problem is that Beck et al literally say that pair programming mean two people working on one task, with one driving the keyboard and the other looking over their shoulder.

To shorten it to the bottom line...close collaboration on a complex sub-system - good. Tied-at-the-hip pair programming - bad.

<Spille>
The problem is that Beck et al literally say that pair programming mean two people working on one task, with one driving the keyboard and the other looking over their shoulder.
</Spille>

I just have to correct part of this. Yes, pair programming is two people working on the same task. It is NOT one person looking over their shoulder. It it were that, then I completely agree that pair programming is a waste of time and resources.

What the other person is doing when not typing is a code review. They are there to remind the person of the coding conventions, what interface to use and how to use it, how this "thing" is supposed to tie in with the rest of the architecture and spot duplications for refactorings.

If reviewing the code as written is not valuable to you, then I would suggest not using pair programming. Stick with a more peer programming environment and use "casual" code reviews . IME, peer programming is not as efficient than pair programming. When someone asks me for help and I jump in, it takes me a little while to orient myself to what they are doing and why. I do not understand the reasoning that lead to the roadblock.

<Nettleton>
I just have to correct part of this. Yes, pair programming is two people working on the same task. It is NOT one person looking over their shoulder. It it were that, then I completely agree that pair programming is a waste of time and resources.

What the other person is doing when not typing is a code review. They are there to remind the person of the coding conventions, what interface to use and how to use it, how this "thing" is supposed to tie in with the rest of the architecture and spot duplications for refactorings.
</Nettleton>

Umm....I think we've said the same thing. Someone's got the keyboard, another person is "looking over their shoulder". By that I don't mean they're staring at the screen and are mute. They're offering suggestions, giving ideas, observing what's being written, etc.

<Nettleton>
If reviewing the code as written is not valuable to you, then I would suggest not using pair programming. Stick with a more peer programming environment and use "casual" code reviews . IME, peer programming is not as efficient than pair programming. When someone asks me for help and I jump in, it takes me a little while to orient myself to what they are doing and why. I do not understand the reasoning that lead to the roadblock.
</Nettleton>

As with everything in life, timing is the thing. Casual code reviews don't "block" anyone - they're done indepedently. At the same time, jumping in to help someone directly should be a rare event. Yes, you need time to orient, but it shouldn't be happening that often.

By contrast, pair programming ties up two people working on exactly the same thing. For really complex stuff this can be exciting and productive. For most code, which is pretty boring to be honest, it wouldn't surprise me if the non-keyboard person nodded off occasionally.

That point that I think some may be missing is scaling. In a peer sort of environment that I've described, everyone's doing alot of productive work without any bottlenecks. Yes, there can be interruptions, but they're the exception, not the rule. If something is exceptionally hairy or complex, then you may pair for an hour/day/whatever - but again, you're doing this because it makes sense for the problem at hand, not because someone mandated pairing.

But in a pair environment, you're mandating that two people work on one task together. This is a guaranteed bottleneck - one of the people is going to slow the other down. This is worsened when you realize that most business logic is very easy, but takes time just because of sheer bulk. Pair programming gives you zip, zero benefit when writing boilerplate code.

Very good points. This is probably one of the clearest arguments against "mandated pair programming" I have read. In fact, as I have read you last couple of postings, I have softened some in my PP stance (actually, I have never been an XP absolutist - I just like playing devil's advocate).

As many have said before, PP has its benefits. But, like you just explained, it perhaps it is not needs for all things, such as boiler-plate code. For example, if you are creating a new data object (i.e. creating a fairly generic bean class), you probably can get by without a partner. If you are refactoring the engine of your messaging system, it probably wouldn't hurt to work with somebody.

In fact, even as my team is embracing the "spirit" of XP, we do not pair all of the time. Mundane bug fixes, experimenting, small refactorings/enhancements are often done solo. We tend to pair on either nasty bugs, tricky code, or when starting a new project/sub-project. I have found that pairing when starting new is very helpful for a couple of reasons. One, working with somebody else tends to drive creativity. Two, you are less likely to hit a mental roadblock as you are fleshing out a new design.

Back to writing boilerplate code solo...this brings up another point. We shouldn't have to do this much, right? Isn't that what frameworks and tools like and XDoclet handle for us? When I write an ample amount boilerplate code, I start to think, "How can I automate this crap." Often, two people spending a few days working out how to automate generic code can save tons of time down the road.

<Breidenbach>
As many have said before, PP has its benefits. But, like you just explained, it perhaps it is not needs for all things, such as boiler-plate code. For example, if you are creating a new data object (i.e. creating a fairly generic bean class), you probably can get by without a partner. If you are refactoring the engine of your messaging system, it probably wouldn't hurt to work with somebody.
</Breidenbach>

Absolutely. Walking through designs with someone else is a very good thing. Even if the design is just squiggles on a bunch of napkins, it's good to have someone else look at it for holes or problems.

<Breidenbach>
In fact, even as my team is embracing the "spirit" of XP, we do not pair all of the time. [....]
</Breidenbach>

It all sounds sensible to me - pair when it makes sense, pair when it feels to the developers like the right thing to do. Share knowledge and ideas.

At the same time - I still believe in having domain experts in different areas of the code. I don't mean in the sense that one person is a bottleneck because he's the only one who knows anything about it. Rather, you have an expert because that someone can grow their knowledge in that area over time, and make refinements based on their direct experience there. Others can come in and make changes, but there's one "master" of that area who knows how it's changing over the long haul. What I miss in XP pairing and collective ownership is that accumulation of knowledge over the long term. Different pairs popping in and out of different sub-systems doing various user stories means to me that alot of knowledge is getting diffused out, and ultimately spread too thin.

<Breidenbach>
Back to writing boilerplate code solo...this brings up another point. We shouldn't have to do this much, right? Isn't that what frameworks and tools like and XDoclet handle for us? When I write an ample amount boilerplate code, I start to think, "How can I automate this crap." Often, two people spending a few days working out how to automate generic code can save tons of time down the road.
</Breidenbach>

I'm a huge fan of code generation (if done right!), but I don't think we'll ever move away from boilerplate. Frameworks and generators do more work for us, and give us more bang for the buck, but that just means more work comes in to fill our time, and the boilerplate moves somewhere else. For example, in a previous job we had a home-grown generator that described & managed system entities (not EJBs, but logical business entities), and spit out a whole bunch of boilerplate code. But....while we didn't have to write all that, there was now boilerplate definitions in the XML definition files and code templates. We were doing more, but there's still points of drudgery.

Either I am dense or ignorant, but I just do not see how pair programming ALONE can create bottlenecks that do not occur in a more distributed programming environment. Please explain what you mean by bottlenecks? Perhaps I am misunderstanding what you mean by this term.

I am not completely sold on the case that XP on its own can scale to very large and/or distributed teams. XP works well with smaller teams that are all located in the same location. I am not convinced that it can scale to larger organizations and still remain XP. It may be Agile, but my guess is that it would not be XP.

From this thread, I seem to be drawing two fears about pair programming (not XP). One, that team (or developer) goes slower. Two, "I'm going to be bored watching someone code all day", or alternatively "I don't want someone watching me over my shoulder all day." Is this correct? Again, I am either dense or ignorant, but why are these fears?

<Nettleton>
Either I am dense or ignorant, but I just do not see how pair programming ALONE can create bottlenecks that do not occur in a more distributed programming environment. Please explain what you mean by bottlenecks? Perhaps I am misunderstanding what you mean by this term.
</Nettleton>

I don't think it's you, I'm just not describing it well enough.

The bottom line on both sides of the fence is to get higher quality code without hurting efficiency. That's the big bang you're supposed to get from pairing, and it's the big bang I go for too.

In my model, the "higher quality" part is achieved by lots of QA tests, and senior technical people doing informal reviews on the side (e.g. not taking up developer's time doing formal code walkthroughs and the like). The efficiency comes from individual developers doing their own pieces (or collaborating as they feel necessary), and in planning dependencies early on to keep the development pipeline full.

On the pairing side, higher quality comes from unit tests, and two people working on the same task simultaneously. This has some implications:

- The number of tasks that can be worked on simultaneously is cut in half. This can't be disputed.

- Each person "at the keyboard" has someone working with them, either semi in the background, looking over their shoulder, sitting next to them, whatever. That person in the background is going to generate a high level of interrupts to the guy at the keyboard. I don't think you can seriously dispute this, either. To me it means each individual gets less think time while they're actually creating code, and is also getting interrupted when they may be in a "flow state". This I believe is going to slow things down on a micro-level.

- The micro-level slow down is supposed to be balanced by the fact that two people will write more good code earlier, so there's less bugs and less debugging (e.g. they work slower, but thrash less than the individual). This ties into test-driven development as well. The test-driven dev and "better code earlier" effects are supposed to offset the micro-level slow downs from the previous point.

So what do we have? In my model, a small number of senior people do a bit more work, don't interfere with other developers unless there's a problem, and (hopefully) gets high quality. The theoretical # of simultaneous tasks is the number of developers you have - but you'll rarely do that well. But overall, I don't see any serious bottleneck here. So at best 6 developers can work on 6 simultaneous tasks in parallel (for example), with infrequent interrupts from senior people.

In the XP pair model, the theoretical max of simultaneous tasks is halved - 6 developers can only work on 3 tasks in parallel. Of those three tasks, there are frequent interrupts to the guy writing code right now. Supposedly, even though there's less parallelism and more interrupts, the quality means overall they're working faster.

But this has a baseline assumption - if they're not in pairs, the quality is significantly worse. What if, as in my scenarios, quality is _not_ significantly worse? What if my peer model's quality is about as good as the pair?

If that's so, then pairing is a giant crock. The bottleneck is that 50% of your developers are interrupting the other 50%, and they swap every so often.

<Nettleton>
From this thread, I seem to be drawing two fears about pair programming (not XP). One, that team (or developer) goes slower. Two, "I'm going to be bored watching someone code all day", or alternatively "I don't want someone watching me over my shoulder all day." Is this correct? Again, I am either dense or ignorant, but why are these fears?
</Nettleton>

Why is going slower a fear? Does that need to be explained?

Why is boredom a fear? Why is being constantly being interrupted a fear? Perhaps because I like to try to enjoy my work, at least a little. And, strangely enough, happy people are more productive in the long run than unhappy ones.

<Spille>
But this has a baseline assumption - if they're not in pairs, the quality is significantly worse. What if, as in my scenarios, quality is _not_ significantly worse? What if my peer model's quality is about as good as the pair?

If that's so, then pairing is a giant crock. The bottleneck is that 50% of your developers are interrupting the other 50%, and they swap every so often.
</Spille>

I agree that it is entirely possible, and proven, that a development environment you describe can, and does, produce as good, or in some cases better, code than code developed in pairs. The success of projects prior to XP-style pair programming (or even XP) cannot dispute this fact. I also do not dispute that on any give day, 6 coders working in pairs can work on only half as many physical tasks as 6 individual coders.

However, I disagree that pair programming is a giant crock. I believe you still get more out of pair programming than without. I will not recite a list of examples of how and what, but if you are interested I can explain some more of my ideas and see what you think. Perhaps they are really not as important or persuasive as I think?

<Spille>
Why is going slower a fear? Does that need to be explained?
</Spille>

Is this an experienced fear or one imagined? I do not ask to be flip, but I am just curious to see if this has happened to you. Is so, why did you think you went slower? What sort of things did you do to try to solve the problem of going slower? Or was it a problem that simply could not be solved in the time provided? Some things just take too much effort to care about.

<Spille>
Why is boredom a fear? Why is being constantly being interrupted a fear? Perhaps because I like to try to enjoy my work, at least a little. And, strangely enough, happy people are more productive in the long run than unhappy ones.
</Spille>

Again, are these real experienced fears or just supposed? I certainly cannot dispute the fact that happy people are more productive than unhappy people. If you are not happy working in a pair programming environment, by all means, please do not work in one. We all have to work and to exchanging 8+ hours a day doing something you do not like just for money is foolish.

It has been my experience that coders who pair generally have less stress, are more receptive to change and more interested in coming to work each day. Pair programmers seem have the opportunity to be working on something new.

I have also seen unhappy coders toil away on components they were tied to since their hire date with no hope of relief except through resigning or being let go. Alternatively, I have observed coders get pigeoned holed into doing one type of work and just work on variations of the same thing over-and-over. These were not happy people and not that productive.

<Nettleton>
I agree that it is entirely possible, and proven, that a development environment you describe can, and does, produce as good, or in some cases better, code than code developed in pairs. The success of projects prior to XP-style pair programming (or even XP) cannot dispute this fact. I also do not dispute that on any give day, 6 coders working in pairs can work on only half as many physical tasks as 6 individual coders.

However, I disagree that pair programming is a giant crock. I believe you still get more out of pair programming than without. I will not recite a list of examples of how and what, but if you are interested I can explain some more of my ideas and see what you think. Perhaps they are really not as important or persuasive as I think?
</Nettleton>

Yes, I'd be interested in that, and I admit that I'm still a little confused. In the first paragraph, you say that you can get results as good or better than pairs without doing pairs, and in the second you say you can get more out of pairs. Perhaps some more insight into your ideas will make this clearer.

<Nettleton>
why did you think you went slower? What sort of things did you do to try to solve the problem of going slower? Or was it a problem that simply could not be solved in the time provided? Some things just take too much effort to care about.
</Nettleton>

I believe that using pairs is slower than my method, for a number of reasons I've already stated. In cases where I've seen pairs used aggressively and there were perceived slow downs in overall project progress, the answer was simple - don't pair so aggressively.

Certainly some tasks are complex and are going to take a fixed amount of time that you can't change. In those cases, if delivery date is important, the typical thing to do is to try to remove some requirements and eliminate some of the complexity. You can also see if you can parallelize some of the development, but this is usually very difficult for complex sub-systems (the mythical man month rules come into play here).

As to why slowness is bad - well, simply because most developers are judged by two criteria: how much they deliver, and the quality of what they deliver. Delivering lots of crap fast will give you a bad rep. Delivering a trickle of work of outstanding quality will give you a bad rep. Delivering a decent amount of work with good quality will give you a great rep.

And your rep should translate into $$$$ (although I understand that this isn't always true).

<Nettleton>
It has been my experience that coders who pair generally have less stress, are more receptive to change and more interested in coming to work each day. Pair programmers seem have the opportunity to be working on something new.

I have also seen unhappy coders toil away on components they were tied to since their hire date with no hope of relief except through resigning or being let go. Alternatively, I have observed coders get pigeoned holed into doing one type of work and just work on variations of the same thing over-and-over. These were not happy people and not that productive.
</Nettleton>

I've seen the same thing. The question is: is pairing the only way to break out of the rut? I don't think so. Pairing may break them out and make them less stressful. But simply assigning them to something new and fresh at times may also break them out of the rut, and may be even less stressful than pairing.

It seems to me the differences in our outlooks are pretty simple (and please correct me if my analysis is wrong). It looks like starting with a pretty awful environment, with people chained to a chunk of code indefinitely, and few if any quality checks on them. You then compare that to pairing - and pairing looks much better.

For me, I'm thinking of similar awful environments, and then comparing them to pairing and also comparing them to my style. As you say, pairing looks better than the original start point - but my style of peer programming looks even better than pairing.

<Spille>
Yes, I'd be interested in that, and I admit that I'm still a little confused. In the first paragraph, you say that you can get results as good or better than pairs without doing pairs, and in the second you say you can get more out of pairs. Perhaps some more insight into your ideas will make this clearer.
</Spille>

I don't see the confusion. To deny the fact that good code is written outside a pair programming environment would be disingenuous and ignore facts.

Here are some reasons why I think pairs are still better:
1) Increase your "bus number" as knowledge of key areas of the system spreads to more and more people. More people being capable of working on any part of the system only adds value.

2) A pair that gets stuck or lost are more likely to ask for help when they BOTH get stuck then a single developer trying to force a solution.

3) New skills, ideas and concepts are spread to the developers quickly. Pair programming encourages the concept of making everyone better developers by allowing everyone an opportunity to observe how the "experts" work. I don't care how good you think you are, you can ALWAYS learn something from your colleagues, even the green, fresh out-of-college CS grad.

4) All the code has been looked at by a second pair of eyes at LEAST once. If two people cannot understand it, then it is likely no one will "get it", even in a formal or casual code review.

5) Less risk of burnout ammong the developers since pairing almost certainly enforces people work a reasonable day and no one person has to stay late when Hell break loose.

6) Code is easier to understand and maintain. Two people are less likely to ignore coding conventions or rewrite a brand new interface when one already exists.

7) Quality goes up as more and more unit tests are written. Having the second person there encourages you not to skip on unit testing.

8) Two people working on a single task are less likely to wander off the requirements or misunderstand the purpose of the task. If two people do not understand it, maybe it wasn't explained well in the first place.

<Spille>
For me, I'm thinking of similar awful environments, and then comparing them to pairing and also comparing them to my style. As you say, pairing looks better than the original start point - but my style of peer programming looks even better than pairing.
</Spille>

I understand your position more clearly. It seems some of your ideas of development value speed, completing more checkmarks on the task completed list and giving developers a lot of flexibility in how and what they deliver. Some of the things I value is a high quality priduct delivered at a predictable rate while giving the customer as much felxibility as possible. For the types of projects I have experieced, I feel pair programming and XP does just that. That is not to say pair programming and XP will do the same for the projects you have had experience with.

<Nettleton>
Here are some reasons why I think pairs are still better:
1) Increase your "bus number" as knowledge of key areas of the system spreads to more and more people. More people being capable of working on any part of the system only adds value.
</Nettleton>

Pairs provide no advantage here. Individuals can be switched around in the code just as easily as pairs - in fact, more easily.

And I believe XP's aggressive collective ownership model means that while knowledge is spread, it's spread too thin. There are no true experts in the complex areas of the system, nor can there be - even if you're an expert at one point, an aggressive refactor by another pair can wipe out much of your knowledge.

<Nettleton>
2) A pair that gets stuck or lost are more likely to ask for help when they BOTH get stuck then a single developer trying to force a solution.
</Nettleton>

I find this not to be an issue on projects with short iterations. If someone is stuck, it's self-evident - they start slipping on their deliverables. In other words, on a short iteration project you can't hide.

<Nettleton>
3) New skills, ideas and concepts are spread to the developers quickly. Pair programming encourages the concept of making everyone better developers by allowing everyone an opportunity to observe how the "experts" work. I don't care how good you think you are, you can ALWAYS learn something from your colleagues, even the green, fresh out-of-college CS grad.
</Nettleton>

This is true initially. But after the first couple of iterations, you're going to know all you want to about how people work.

As for coding styles and methods - this is evident from the code. You don't need to pair to learn new coding techniques.

<Nettleton>
4) All the code has been looked at by a second pair of eyes at LEAST once. If two people cannot understand it, then it is likely no one will "get it", even in a formal or casual code review.
</Nettleton>

A valid point, but only if both coders are of excellent skill. If one of them's a newbie, quite frankly the newbie isn't going to know the advanced techniques, and won't be able to comment very effectively on them. Even after pairing on several XP projects, a newbie isn't going to magically float up to the expert level. It takes years to learn really effective coding. And in the meanwhile, in a pairing scenario, either the newbie is going to be shut out, or the expert is going to be slowed down constantly explaining things (and his/her patience will likely start to fray as well).

Net net - if it's two junior guys paired, the "two eyes" rule doesn't give you much. If it's a mismatched pair, "two eyes" might give you something, albeit very slowly. It also might not, if the senior guy is shutting the junior out. And despite what you might say here, on projects with short iterations senior people really don't have the time to _constantly_ explain things to someone new to the game. This doesn't mean they're above mistakes - reviewing is important. But constant review is, ahem, too extreme.

<Nettleton>
5) Less risk of burnout ammong the developers since pairing almost certainly enforces people work a reasonable day and no one person has to stay late when Hell break loose.
</Nettleton>

This is patently untrue. Burnout isn't about working crazy hours, burn out is when you're stressed out and no longer enjoy your job. This can happen as easily on a pair project as on others. Being forced to work 5 hours a day with someone you don't enjoy pairing with can easily burn someone out. Add in the loss of the little amenities as well - listening to music while you code, multitasking (e.g. surfing the web during a long compile, checking on a performance run in the background, etc).

<Nettleton>
6) Code is easier to understand and maintain. Two people are less likely to ignore coding conventions or rewrite a brand new interface when one already exists.
</Nettleton>

This is also patently untrue. Pairs can and do write bad code. Your assertion only works if the pairs get along very well and are excellnet programmers - which taken together is a rare thing.

Two guys who don't get along particularly well, a mismatched pair, or two junior people - in all these scenarios, you have no guarantee that the code is going to be readable and high quality.

<Nettleton>
7) Quality goes up as more and more unit tests are written. Having the second person there encourages you not to skip on unit testing.
</Nettleton>

I can swallow this one - but I still maintain that unit tests are too finely grained to be a good indicator of overall quality.

<Nettleton>
8) Two people working on a single task are less likely to wander off the requirements or misunderstand the purpose of the task. If two people do not understand it, maybe it wasn't explained well in the first place.
</Nettleton>

Quite the contrary. If the reqs are vague and the pair doesn't consult a knowledgable authority, the person with the strongest personality will "win". This is human nature.

<Nettleton>
I understand your position more clearly. It seems some of your ideas of development value speed, completing more checkmarks on the task completed list and giving developers a lot of flexibility in how and what they deliver.
</Nettleton>

Yes, especially on the last. But you left out one - quality. I don't believe in sacrificing quality for speed.
But I also believe that quality doesn't mean that you have to go slow.

<Nettleton>
Some of the things I value is a high quality priduct delivered at a predictable rate while giving the customer as much felxibility as possible. For the types of projects I have experieced, I feel pair programming and XP does just that. That is not to say pair programming and XP will do the same for the projects you have had experience with.
</Nettleton>

In my experience, the rate cannot be just predictable. It also has to be timely. If two comparable projects are delivered within a common acceptable range of quality, but one is delivered two months earlier, which team do you think is more successful? True, going at a fast clip and maintaining quality isn't a walk in the park, but with the right controls it can be done (and it can be done without resorting to techniques like pair programming). Quality doesn't have to mean that your progress is slow.

I think we are going to have to agree to disagree on this subjects of pair programming and extreme programming. Your experience suggests one thing and mine suggests another. We could go on-and-on, point-by-point disecting each other's positions, but that would be tedious.

Suffice it to say, I have seen extreme programming and pair programming work very well and not so very well. In both instances, extreme programming and pair programming added value to the project and product delivered. I have also seen very high quality code created in short periods of time using pair programming and extreme programming.

You on the other hand, have indicated no direct experience with pair programming or extreme programming, yet seem unwilling to be open to the possibility that there is anything to learn from pair programming and extreme programming. While I see opportunities, all you can see are obstacles. That is OK. That is simply your experience speaking to you.

All I can suggest is a series of "what if's" based on my experience. If those possibilities do not resonate with you, then it would seem as if pair programming and extreme programming would not add value to what you do where you currently work. Again, that is OK. Extreme programming and pair programming are not for everyone. You got to want to do it. If you don't want to do it, please do not. Life is too short to spend 8 to 10 hours a day doing something you hate just for money.

<Nettleton>
I think we are going to have to agree to disagree on this subjects of pair programming and extreme programming. Your experience suggests one thing and mine suggests another.
</Nettleton>

I'm sure you're right about that.

<Nettleton>
Suffice it to say, I have seen extreme programming and pair programming work very well and not so very well. In both instances, extreme programming and pair programming added value to the project and product delivered. I have also seen very high quality code created in short periods of time using pair programming and extreme programming.
</Nettleton>

Statements like the above aren't of much use to readers of this forum, and have muddied the conversation significantly. You've repeatedly said things like the above - if you allow me to paraphrase,it sounds to me like "sometimes XP and pairs work well, sometimes not so well. But it's all good! If it doesn't work for you, well, I guess it's not for you."

Perhaps this characterization is my mis-reading, and it's probably not what you're thinking, but it's how you're coming across to me. And it's of no use to people thinking about going to XP or pair programming. You admit that you've seen XP & pairs not work well - but do not elucidate on those situations. When you make some specific points in favor of XP, and people question some of your points good naturedly, you resort to the platitude "maybe it's not for you". Personally I fail to see the point of advocating a position if you're not willing to defend it.

<Nettleton>
You on the other hand, have indicated no direct experience with pair programming or extreme programming, yet seem unwilling to be open to the possibility that there is anything to learn from pair programming and extreme programming. While I see opportunities, all you can see are obstacles. That is OK. That is simply your experience speaking to you.
</Nettleton>

I haven't used XP or pair programming whole hog. Like others have done and indicated on this board, I've tried pieces of it in limited trials. I learned some positive things from those trials - for instance, that with pair programming you see increased collaboration overall, a very desirable trait. I've also learned negative things - people don't work well when they're constantly paired. And so I've attempted to strike a balance, as I've described exhaustively in other posts.

In short, it's not black and white. I don't evaluate things in terms of "It's all good!", or "It sucks!". I evaluate in-depth and pull out what is of value to me.

Indeed, black and white evaluations ("While I see opportunities, all you can see are obstacles.") have no place in software development. I have conceded that XP has many admirable traits - with qualifiers. Those qualifiers are at the heart at my job. If it wasn't, we'd all go out and buy the expert's books and live happily ever after.

<Nettleton>
All I can suggest is a series of "what if's" based on my experience. If those possibilities do not resonate with you, then it would seem as if pair programming and extreme programming would not add value to what you do where you currently work. Again, that is OK. Extreme programming and pair programming are not for everyone. You got to want to do it. If you don't want to do it, please do not. Life is too short to spend 8 to 10 hours a day doing something you hate just for money.
</Nettleton>

The most convincing arguments are made by enumerating the pros and cons of a position, and then showing how one side outweighs the other. I've tried to do this, and most likely have failed miserably. But at least I've tried to do it honestly and objectively. But, in all candor, I cannot find your arguments credible _because you never list cons_. All you state is a laundry list of benefits, with no indication that there is _any_ downside. Anything of interest in life has its plusses and minuses, it's pros and cons - no project or approach is a perfect failure, and likewise no project or methodology is a perfect success. By refusing to discuss downsides of your position, you've taken away everyone's ability to rationally consider your argument - because you leave nothing to consider.

It's like debates over app servers. There is no single "best" app server. There may be clear winners in certain contexts, perhaps even a clear "overall winner", but that conclusion can be reached only by comparing them in-depth, and listing what each is good for and where each falls down. And people can find out for themselves which is best by looking at the plusses and minuses of each, and evaluating that information in their own context.

Now imagine App server reviews with only positives - negatives are always elided. How useful would that be to you? Would you be able to make any sane evaluations based on that? I doubt it.

Likewise - what sane evalution can anyone make based on your "I see opportunities" arguments?

I concede there are some very real fears and costs associated with pair programming and XP. For many software development groups the costs of moving to these two ideas far outwiegh the benefits. If the costs outwiegh the benefits, my experience says, don't use pair programming or XP.

Pair programming and XP success are highly dependent on the willingness of the programmers and management to adhere to and follow through with the basic concepts of the process (communication, simplicity, feedback and courage). If those conditions are not present, my experience says, do not use pair programming or XP.

If way you develop software works then I really cannot see any reason to swtich to pair programming or XP. Why rock the boat, why cause so much change just to say you are using XP or you want everyone to pair program? If however, your process does not "work" or just needs some small modifications, I simply was advocating there are some things to learn from XP and pair programming. The key ideas that I think apply to most software development are unit testing, refactoring, automated customer testing, close customer collaboration, continuous integreation, small releases and customer controlling scope and release.

<Nettleton>
If however, your process does not "work" or just needs some small modifications, I simply was advocating there are some things to learn from XP and pair programming. The key ideas that I think apply to most software development are unit testing, refactoring, automated customer testing, close customer collaboration, continuous integreation, small releases and customer controlling scope and release.
</Nettleton>

I agree, and I believe I've said so several times. Your list also matches mine to a close order.

But most curious to me - your list has nothing to do with pair programming. You can easily do all those things (and myself and many, many others have) without ever even considering going down the pure pair programming path.

Pair programming is THE most contentious issue with respect to Extreme Programming. In fact, many people consider it the "extreme" part of Extreme Programming. I would have figured Collective Code Ownership, Refactoring or On-Site Customer to cause much more alarm. Go figure?!

Pair programming is just a part of Extreme Programming. You can do a lot of things described in Extreme Programming, but it you do not pair program all the time, it really is not being "extreme". You might be able to drop other things (metaphor, on-site customer, sustainable pace) and still call whatever you are doing Extreme Programming. Much else, I would not call it Extreme Programming. Agile, maybe, but certainly not "extreme".

<Spille>
<Nettleton>
I think we are going to have to agree to disagree on this subjects of pair programming and extreme programming. Your experience suggests one thing and mine suggests another.
</Nettleton>

I'm sure you're right about that.
</Spille>

A simple solution: you guys should Pair on something; then you should work independently on something else. Then you can compare experiences. :)

<Rainsberger>
A simple solution: you guys should Pair on something; then you should work independently on something else. Then you can compare experiences. :)
</Rainsberger>

Ironically, we could probably peer program quite well, despite the fact that I'm in NYC and he's probably not. Phone calls, rare face to face meetings, and e-mailing diagrams can be sufficient to co-design and then split the work up for two people to work on. Indeed, open source projects quite often work this way.

But assuming he's not in NYC, we could _never_ pair. Thanks for pointing out yet another situation where pair programming falls down!!

<quote>
Ironically, we could probably peer program quite well, despite the fact that I'm in NYC and he's probably not.
</quote>

I don't know why this is ironic. I don't say that Peer Programming (as you describe it) is a bad thing. I don't say that Pair Programming is the One True Way. There are benefits that one gets from Pairing that one doesn't get nearly as easily from Peering: knowledge transfer, catching defects as they're typed, "You drive for a moment; I'm tired", that kind of thing... still, I have done Peering and it has been effective when all that matters is getting a couple of already-quite-good programmers who already understand the system to just bang out some code quickly.

<quote>
Phone calls, rare face to face meetings, and e-mailing diagrams can be sufficient to co-design and then split the work up for two people to work on. Indeed, open source projects quite often work this way.
</quote>

Not all Open Source projects are successful. Good Open Source projects are that way because of good people. I can only imagine how effective those good people could be if they were in the same room... wow.

<quote>
But assuming he's not in NYC, we could _never_ pair. Thanks for pointing out yet another situation where pair programming falls down!!
</quote>

This seems like blaming humans for needing oxygen to breathe, because most of the universe lacks oxygen. Stupid humans! (Hint: humans either stay in oxygen-rich environments or simulate same. Humans simply don't venture into the vacuum of space without taking precautions first.)

<Rainsberger>
I don't know why this is ironic. I don't say that Peer Programming (as you describe it) is a bad thing. I don't say that Pair Programming is the One True Way. There are benefits that one gets from Pairing that one doesn't get nearly as easily from Peering: knowledge transfer, catching defects as they're typed, "You drive for a moment; I'm tired", that kind of thing... still, I have done Peering and it has been effective when all that matters is getting a couple of already-quite-good programmers who already understand the system to just bang out some code quickly.
</Rainsberger>

This again is where we disagree. You state "There are benefits that one gets from Pairing...". You seem to not acknowledge that pairing _does not_ always get you these benefits. You seem to not particularly care about the real road blocks towards even trying to pair.

<Rainsberger>
Not all Open Source projects are successful. Good Open Source projects are that way because of good people. I can only imagine how effective those good people could be if they were in the same room... wow.
</Rainsberger>

Of course they're not all successful. But they also wouldn't exist at all if we all had to use pair programming to get true quality.

As for "imagine how effective those good people could be if they were in the same room", I'd say you'd be surprised. Not everyone who can collaborate on code will be good pairing together. I know some people who contribute great stuff to open source, working in the same areas of code, who are only stiffly cordial to each other. They manage to work together and get things done because they don't have to deal face to face with each other all the time. If they did, there'd be fights and arguments constantly.

<Rainsberger>
This seems like blaming humans for needing oxygen to breathe, because most of the universe lacks oxygen. Stupid humans! (Hint: humans either stay in oxygen-rich environments or simulate same. Humans simply don't venture into the vacuum of space without taking precautions first.)
</Rainsberger>

Very, very poor analogy. Saying "pairing is difficult and doesn't always work out" is more like saying "going from Japan to New York at mach-15 on some sort of ballistic transport may be the fastest way, but rather hard to do in practice". If there just happens to be a mach-15 ballistic transport going my way, fine. But I'm not going to rely on it on a regular basis.

Your message hints that you are personally threatened by XP, for whatever hidden reason that you don't want to divulge. Could it be that you really suck as a developer, and god forbid someone else find out?

The best part of XP is that it helps get rid of the crap in the team. You can't hide, and you have to be productive, unlike the majority of shops out there where the losers like Larry can hide in their cube. I'm all for running it up the chain--once more people had to actually try to work day to day with many of the losers in management, they'd work harder at figuring out how to get rid of them.

<quote>
The best part of XP is that it helps get rid of the crap in the team. You can't hide, and you have to be productive, unlike the majority of shops out there where the losers [...] can hide in their cube. I'm all for running it up the chain--once more people had to actually try to work day to day with many of the losers in management, they'd work harder at figuring out how to get rid of them.
</quote>

This is an interesting thought, and something that I see as a positive aspect of XP: problems surface quickly. I believe that this is THE NUMBER ONE REASON why XP does not work well in large, slow-moving organizations. My past experience includes very small companies (12 people total) and very large companies (IBM). Agile concepts work better in smaller environments EVEN IN THE FACE OF SKEPTICISM; whereas even my small neck of the IBM woods couldn't grasp the benefits of Agile Software Development. The reason? Problems surface quickly and IBM is too slow to deal with them.

So a question: if XP is ever to succeed in the main (and perhaps it never will), I presume that we need to make larger organizations more agile in dealing with people problems. Does anyone know how to do that? Can it be done?

<Rainsberger>
This is an interesting thought, and something that I see as a positive aspect of XP: problems surface quickly. I believe that this is THE NUMBER ONE REASON why XP does not work well in large, slow-moving organizations. My past experience includes very small companies (12 people total) and very large companies (IBM). Agile concepts work better in smaller environments EVEN IN THE FACE OF SKEPTICISM; whereas even my small neck of the IBM woods couldn't grasp the benefits of Agile Software Development. The reason? Problems surface quickly and IBM is too slow to deal with them.
</Rainsberger>

I've seen general agile concepts succeed in large organizations. XP specfically has had problems because it has developers tilting at windmills - insisting on radical change with little proof of return for those changes. Even large organizations can deal with small iterations, shorter integration times, better & more integrated QA. The benefits are clear and the costs low. What they can't deal with are pure XP approaches that, to a high-level development manager, represent significant risks with no answer on how to mitigate them.

I also happen to believe that XP isn't going to work well in a product environment. There, the customer by definition can't work closely with the developers, requirements have to spelled out in extreme detail before development, and formal QA processes must be in place. Agile processes can benefit here - but XP can't.

<quote>
What they can't deal with are pure XP approaches that, to a high-level development manager, represent significant risks with no answer on how to mitigate them.
</quote>

Can you point to a specific risk that you have in mind here?

<quote>
I also happen to believe that XP isn't going to work well in a product environment. There, the customer by definition can't work closely with the developers, requirements have to spelled out in extreme detail before development, and formal QA processes must be in place. Agile processes can benefit here - but XP can't.
</quote>

In a product environment, it is customary to appoint someone to be the Product Advocate. There may indeed be more than one. At WebSphere Commerce at IBM, there were several advocates, one per Important Client, whose job was (in part) to lobby for features that their Important Client cared about most. The advocate would also clarify requirements as needed. It is not as easy as having the customer Speak With One Voice, but if that is what one has, then one makes do. The sum total of these advocates is essentially the Customer. It's not as good as a real, live, off-the-street end user (in many ways), but it can work and has worked.

I don't know why it is necessary to spell everything out in detail before coding, though. I have successfully delivered shrink-wrap software using evolutionary design. The broad strokes were set out in advance, sure, but technology choices, algorithm choices, low-level design choices, those all waited until I built the thing. QA spent six weeks and found one defect in a software component with around 150 classes. That's pretty good, if I may say so myself. My story is not an isolated one. (It's just the only one I know just now.)

It's Just One Example, sure, but I saw it with my own eyes. I felt in control as I built the thing. It worked, then it kept working and it still works today. (It's still in the product as of about four months ago and I built it in late 2000.)

Also, I don't understand why a formal QA process and XP are mutually exclusive. XP loves testing, so why not more testing? What part of a formal QA process does XP not play nicely with?

Or are you simply saying that XP cannot provide benefit to a project with a formal QA process? On the contrary, how can it not? If there are almost no easy-to-find defects in the system, then QA can concentrate on investigating the kinds of defects that keep us awake at night -- the ones that cause the computer to crash, but only on Tuesday under a full moon when it's raining and I tilt my head just so. In my experience, we have just prayed that those defects would go away, because we have too many easier defects to fix. Silly us: we should have fixed 'em when we made 'em!

<quote>
What they can't deal with are pure XP approaches that, to a high-level development manager, represent significant risks with no answer on how to mitigate them.
</quote>

<Rainsberger>
Can you point to a specific risk that you have in mind here?
</Rainsberger>

Sure. Keep in mind that I'm talking about pure XP approaches.....

Pair programming - there's a perceived risk that you may use more personnel to achieve less work. Further - is our environment conducive to pairing at all? What will have to change to make it conducive?

Lack of formal detailed requirements documents - how do we know the true scope of the project without defining requirements up front?

Lack of detailed design documents - how do we know how many people we need, how long it will take to build, etc without a detailed design up front?

Velocity-based measurement of progress - does this velocity thing match anything that the business can relate to?

I can go on, but I'll stop. These are the types of objections a conscientious development manager might have to "pure" XP approaches. There are lots of things that go against the grain, and when you add them all up XP becomes a very hard sell, with little to say about how to mitigate all of the risks involved (not individual risks in turn, but the whole lot en masse).

<Rainsberger>
In a product environment, it is customary to appoint someone to be the Product Advocate. There may indeed be more than one. At WebSphere Commerce at IBM, there were several advocates, one per Important Client, whose job was (in part) to lobby for features that their Important Client cared about most. The advocate would also clarify requirements as needed. It is not as easy as having the customer Speak With One Voice, but if that is what one has, then one makes do. The sum total of these advocates is essentially the Customer. It's not as good as a real, live, off-the-street end user (in many ways), but it can work and has worked.
</Rainsberger>

There's alot of value in customer advocates. But at the same time, a product company needs to put out a product in a timely manner. User stories and constant consults from development back to the product advocate(s) means that the company can't predict what will be in the next full release, nor when it will be delivered. Instead, the product company has to wait and see how the thing "grows".

Most product companies really, really don't like this sort of approach.

<Rainsberger>
I don't know why it is necessary to spell everything out in detail before coding, though. I have successfully delivered shrink-wrap software using evolutionary design. The broad strokes were set out in advance, sure, but technology choices, algorithm choices, low-level design choices, those all waited until I built the thing. QA spent six weeks and found one defect in a software component with around 150 classes. That's pretty good, if I may say so myself. My story is not an isolated one. (It's just the only one I know just now.)
</Rainsberger>

Ah, where shall I start:

- someone has to configure the thing
- paying clients have expectations for the next release
- the company is committing to service-level guarantees
- an Important Client needs a given server instance to support 100 TPS with 30 clients
- Documentation needs to be written
- The QA department doesn't want to deal with each development iteration containing major environmental configuration changes
- If the developer(s) hit a snag because of their just-in-time design, how long will it take to fix? How much revenue will we lose? Will XYZ corp's product beat us to market?

As an aside - something big enough to take six weeks to test, and with only one defect found by QA is very impressive. I'll leave it at that.

As an aside - did you build this alone or as part of a team?

<Rainsberger>
Also, I don't understand why a formal QA process and XP are mutually exclusive. XP loves testing, so why not more testing? What part of a formal QA process does XP not play nicely with?
</Rainsberger>

They're not mutually exclusive. My issue here is that many XP advocates blantantly state that XP lets you get away without formal QA if you'd like.

<Spille>User stories and constant consults from development back to the product advocate(s) means that the company can't predict what will be in the next full release, nor when it will be delivered. Instead, the product company has to wait and see how the thing "grows".

Most product companies really, really don't like this sort of approach.
</Spille>

That is just not true. The customer defines the release and knows exactly what is coming in the next release. Maybe you have missed the section in Extreme Programming that talks about Release Planning? I find many people miss this concept as they seem to think that an XP project lurches from iteration to iteration based on the whims and desires of the end users/customers/management. Not so.

Whoever this "customer" is sits with the team from time-to-time and describes all the features they want the system to have in the form of user stories. In that discussion, the customer indicates what the deadline is. While describing the stories, the programmers estimate the user story difficulty using points. Someone (customers or programmers, doesn;t matter..they just have to be good at adding numbers) adds up all the user story points and that is the scope of the release.

The team then does a simple calculation based on multiplying team velocity by the number of calendar weeks from that proint to the deadline. The programmers and the customers compare the points in the scope to the points the team is expected to complete (aka velocity). The team can then respond to the customer with, "Yes, we can do that in the time provided." OR "No, we cannot do that with the resources provided. To accomplish this deadline we need one or more of these things to happen:
- more people (aka money)
- reduce the scope (aka reduce or split the user stories)
- extend the deadline (aka give us more time)

I suppose the customer could say, "Thanks, but no thanks. I know a team who can get it done faster and I will ask them to do this project. You people are just too slow." That is OK, since that is the customer's decision to make. However, I believe most customers are reasonable enough to authorize more money for additional coders, prioritize which features they want or extend the deadline.

One problem some people might have with this approach is asking an end user to do all the planning for an XP release. In a custom solution, this might be OK. You are building something that must suit the needs of a specific group of end users, then you better ask them what they want and get it into their hands quickly.

However, a big company like Intuit would be foolish to let their end users to completely drive their business strategy for a program like QuickBooks or Quicken. In this case, the business people of product/shrinkwrap companies are going to let their analysts proxy for end users and the analysts will act as customers fo an XP team. These analysts will know and understand the corporations goals and create releases that make sense for both the company and the end users.

In light of what I describe, can you please explain how a company will not know what is in the next release? Perhaps there is something else this company needs to know that I missed?

<Nettleton>
That is just not true. The customer defines the release and knows exactly what is coming in the next release. Maybe you have missed the section in Extreme Programming that talks about Release Planning? I find many people miss this concept as they seem to think that an XP project lurches from iteration to iteration based on the whims and desires of the end users/customers/management. Not so.

From "www.extremeprogramming.org"....

"A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration."

"Individual iterations are plannedin detail just before each iteration begins and not in advance. The release planning meeting was called the planning game and the rules can be found at the Portland Pattern Repository."

...and the clincher...

"User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document.....They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.... One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face."

In other words - the "plan" created under XP is a collection of user stories, each of which is 2-3 sentences. "When the time comes to implement the story", developers then get detailed descriptions of the requirement.

The above is directly on-point to my argument. Developers only know vague 2-3 sentence requirements for each user story when planning starts. They do not find out the detailed requirements until it's time to implement the user story. So if user story "123" starts 2 months after project inception, the developer will not know the detailed requirements until 2 months into the project.

And as anyone who works in software knows, the devil is in the details. 2-3 sentences per user story does _not_ cut it for knowing how a software project will look in its final form. It only gives you the vaguest idea. And that's not going to be acceptable to a product company.

<Nettleton>
The team then does a simple calculation based on multiplying team velocity by the number of calendar weeks from that proint to the deadline. The programmers and the customers compare the points in the scope to the points the team is expected to complete (aka velocity). The team can then respond to the customer with, "Yes, we can do that in the time provided." OR "No, we cannot do that with the resources provided. To accomplish this deadline we need one or more of these things to happen:
- more people (aka money)
- reduce the scope (aka reduce or split the user stories)
- extend the deadline (aka give us more time)

In the above scenario, the "point" system is going to get thrown out, very very early in client discussions. Pardon my language, but a typical client is going to say "**** these fucking points - explain this to me in terms of what features I get when for how much". If you refuse and say "5 + 3 + 2 + 4 = 14", most people will throw you out the door.

<Nettleton>
....

However, a big company like Intuit would be foolish to let their end users to completely drive their business strategy for a program like QuickBooks or Quicken. In this case, the business people of product/shrinkwrap companies are going to let their analysts proxy for end users and the analysts will act as customers fo an XP team. These analysts will know and understand the corporations goals and create releases that make sense for both the company and the end users.

In light of what I describe, can you please explain how a company will not know what is in the next release? Perhaps there is something else this company needs to know that I missed?

Yes, this is simple - you missed the fact that user story detail is not defined until the developer is ready to implement a given user story.

The point of view you describe sounds fairly reasonable, actually. The problem is that the XP books and definitive web sites flatly contradict you. The official XP way is minimal documentation, minimal planning until it's time to do something now. In the case of requirements, no detail is communicated until a developer's ready to start writing code for that piece. Similar ideas attach to other points of the XP approach and lifecycle.

And this is why so many people ridicule XP, and also why so many people are confused by XP. You spin a decent story about XP, but it doesn't match the XP expert's opinions. And the expert's opinions are so minimalist, and so encouraging of delaying communication and decisions, that it flies in the face of most experienced developers.

Bringing things back to my original point - imagine Intuit (or whoever) doing things the true XP way, as per extremeprogramming.org et al. There plan for the next release is a stack of index cards, each representing a user story of 2-3 sentences. Do _you_ honestly believe that this stack of index cards will tell a product company what's really going to be in their final next release?

<Spille>
The above is directly on-point to my argument. Developers only know vague 2-3 sentence requirements for each user story when planning starts. They do not find out the detailed requirements until it's time to implement the user story. So if user story "123" starts 2 months after project inception, the developer will not know the detailed requirements until 2 months into the project.

You missed two key points to user story generation. One, each user story has an acceptance test. Two, before each user story is written down, there is a conversation (with most, if not all, the programmers taking part in) that explains, in some detail, what the story is supposed to do. The user story only records a 2 to 3 sentence summary of the conversation and the acceptance test. Don't forget the estimation that is there too.

<Spille>
In the above scenario, the "point" system is going to get thrown out, very very early in client discussions. Pardon my language, but a typical client is going to say "**** these fucking points - explain this to me in terms of what features I get when for how much". If you refuse and say "5 + 3 + 2 + 4 = 14", most people will throw you out the door.

As to points, I think you still miss the point. Team of 6 programmers each making $1500/week estimates feature A to be 4 points and the team can complete 16 points in a week. Therefore, the feature will be delivered to the customer in one week time and cost $2250 [(6 * 1500) * (4/16)] to create. Additional costs for QA and documentation are added later.

I am surprised you let customers and/or supervisors swear at you. I find that behavior unacceptable and I would tell someone that. Did this actually happen or are you using this for hyperbole?

Also, I really do not think they would refuse, but let them. It is THEIR money, let them spend it the way they think. If they do not think Team A can deliver what they want, when they want it, why must the customer choose Team A? Better for the customer to know that Team A cannot meet their needs "very very early in client discussions", than two months into it and $72,000 later.

"It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to."

<Spille>
"Individual iterations are planned in detail just before each iteration begins and not in advance. The release planning meeting was called the planning game and the rules can be found at the Portland Pattern Repository."

"When the final release plan is created and is displeasing to management it is tempting to just change the estimates for the user stories. You must not do this. The estimates are valid and will be required as-is during the iteration planning meetings. Underestimating now will cause problems later. Instead negotiate an acceptable release plan. Negotiate until the developers, customers, and managers can all agree to the release plan."

<Spille>
"User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document.....They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.... One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face."

<long quote defining a user story by Don Wells>
"User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax."

"User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented."

"One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest
difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face."

"Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning."

"Another difference between stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts."
quote defining a user story by Don Wells>>

When I first started to look at XP -- this was early on, maybe 1998/99 time frame, about when John Vlissides interviewed Kent Beck in the C++ Report, I was primarily interested in automated test techniques, since we were trying to apply the then somewhat radical idea of C++ test frameworks to the development project I was working on. The whole pairing thing just seemed disturbing -- I had much the same reaction as Cedric and others, but had never really tried to pair in conjunction with other XP practices. Over time, I started to adopt more and more practices -- continuous integration, refactoring, reliable test baseline -- that Beck advocated. It wasn't until maybe 2001 that I first started to experiment with pairing in a serious way and it was largely involuntary. I was an architect at Bluestone Software (or maybe HP by that time) and one of my co-workers basically insisted that we try it. We did. And it didn't work. At least that what's I thought.

However, I noticed myself and others doing things together more often. And doing them faster and better. The ability to pair was there and the rationale for supporting it as an acceptable practice was liberating for a simple reason: it allowed developers to tell each other they didn't understand something and needed help, with the expectation that they'd get help, without feeling like they were doing anything wrong or weren't smart.

Another thing we found about pairing was that it didn't work at all when people of widely different abilities were pairing together. One person only had so much to give in exchange for nothing in return. XP is deeply wrong in the sociological model it wraps itself in. Beck's Mountain People are the demons of an unreal, even silly, egalitarian mythology. Beck may not understand this, after all, he pairs with Ward Cunningham, guys like Eric Gamma, whatever; his other hat is mentor were he expects to sit in a position of superiority. Pairing allows extremely smart people to get past the boundaries that are often defined by their own egos so they can work in tight collaboration. That's a very powerful tool.

<Spille>
Velocity-based measurement of progress - does this velocity thing match anything that the business can relate to?
</Spille>

Velocity is the ammount of work the team completes in a single fixed length iteration. Each time the team completes a user story, that estimation on the user story is added to the velocity.

At the beginning of an iteration of one week, the team has a velocity of 0. They complete 6 user stories of 5, 2, 3, 2, 1, 4 units, respectively.

Velocity for one week = 5 + 2 + 3 + 2 + 1 + 4 = 16 units

How does this help business people or how can they use it? Depends on what they want. One simple calculations is that in 6 months we can estimate this team will complete is 384 units (6 months * 4 units * 16 unit).

What are somethings that you think business people need? Maybe I can help you with some metrics the velocity can help provide.

<Nettleton>
Velocity is the ammount of work the team completes in a single fixed length iteration. Each time the team completes a user story, that estimation on the user story is added to the velocity.

At the beginning of an iteration of one week, the team has a velocity of 0. They complete 6 user stories of 5, 2, 3, 2, 1, 4 units, respectively.
Velocity for one week = 5 + 2 + 3 + 2 + 1 + 4 = 16 units

The problem I have with the above is that "units" is such a sterile term. It's not going to have any meaning to business people.

On the projects I work on, here's what typically happens:

- Major milestones are set. Each milestone is a combination of features that, together, represent an important chunk of functionality to the business. Each milestone is assigned a date.

- It typically takes multiple development iterations to hit a milestone.

- Lower-level management (e.g. a project manager) watches the "burn rate" at each iteration, and progress against milestones. Adjustments are made at each iteration involving the relevant people. The relevant pieces - how's our actual progress vs. the plan, and what's our burn rate (how much money are we burning per iteration?). The adjustments are usually adding people (increasing burn), extending dates, or pushing features back to other iterations (or milestones).

- High management wants to know the cost/burn rate and progress at the milestones. They typically don't care about the iterations.

The important bits are how much money are we spending, how are we progressing against plan, and what business value are we getting at various points in the project life cycle. Everything here is tied back directly to business value in one way or another.

So a project status report at milestone 2 might say "we're burning $8,000 a week, milestone's been pushed back 2 weeks, and these features have been pushed back to milestone 3. We were burning $5,000 a week, but progress against milestones was slower than we wanted, and it was clear that adding two people would have a positive impact - so we increased burn to improve our progress".

Compare this to project velocity - we finished 40 units in 7 weeks. This tells you nothing about the costs involved, nothing about the important milestones, nothing about tradeoffs involved.

"Project Velocity" is a somewhat useful measurement of how efficiently your developers are working, but alot of translation needs to happen to make it meaningful outside of the development group.

<Nettleton>
How does this help business people or how can they use it? Depends on what they want. One simple calculations is that in 6 months we can estimate this team will complete is 384 units (6 months * 4 units * 16 unit).

What are somethings that you think business people need? Maybe I can help you with some metrics the velocity can help provide.

What does 384 units in 6 months tell the VP in charge of the business unit that represents the end user? Are they on-time, or slipping? What major milestones have been hit, which ones missed? How much is this costing us?

Think of it this way. In the method I've outlined, a business person can meaningfully compare projects. "OK, these features took us this long, and cost this much. The value of the features to the company is 'X'. Now let's look at this other project...".

In the velocity world, the business person sees "OK, we've completed 384 units. Our velocity is 80 units/month. What value do these units represent? Dunno. How much did it cost? Dunno. How does it compare to this other project over here? Dunno."

The real value in the system I've described is that everything is grounded in reality, which serves as a self-check. People can back-check the value of the various milestones, and quanitfy them. Dates and burn rates are straightforward.

But with velocity? What if you've done a bad job of estimating the fundamental "unit"? How can you tell that you made a bad estimate? What if a quarter of your unit estimates were bad? Can you tell?

<Spille>
Compare this to project velocity - we finished 40 units in 7 weeks. This tells you nothing about the costs involved, nothing about the important milestones, nothing about tradeoffs involved.

"Project Velocity" is a somewhat useful measurement of how efficiently your developers are working, but alot of translation needs to happen to make it meaningful outside of the development group.

You are exactly right here. For velocity to be something meaningful to people outside the immediate team of (coders, testers, customers, end users), it needs to be translated. XP is completely nuetral on how to translate the measured progress of your team. Hopefully, the person most qualified to do this translation is the project manager.

However, I continue to disagree that "40 units in 7 weeks...tells you nothing about the costs involved". You know exactly how much you have spent in salary, wages, taxes, rent, social security, phone bills, etc., etc. in 7 weeks. If you don't, then the business has a serious problem keeping a balance sheet.

<Spille>
The important bits are how much money are we spending, how are we progressing against plan, and what business value are we getting at various points in the project life cycle. Everything here is tied back directly to business value in one way or another.

I think you have missed a few key concepts about user stories in XP and this section illustrates that. Each story has business value, otherwise it is not a story. In addition, an XP team works on the stories that produce the most value first. Assuming the user stories remain static, the stories you complete at the end of a project, have trivial value compared to the stories completed in the beginning. In fact, if you dropped them/pushed them to another milestone, it would make no difference to the customer. We are only talking about wishful thinking.

Even if the stories are not static and more important stuff is added later, then the XP team will work on that the next iteration. I suppose a customer could add a really important story on the very last day of the last iteration ("I totally forgot this needs to send our DB container as a text file to everyone in the world in their native language."), but that is highly unlikely. They would have seen the system at most every iteration and hidden requirements would have surfaced then.

<Spille>
What does 384 units in 6 months tell the VP in charge of the business unit that represents the end user? Are they on-time, or slipping? What major milestones have been hit, which ones missed? How much is this costing us?

If the 384 units completed represent 400 unit release plan with a 6 month deadline. Then it means you are 96% complete with the project.

If this happens on the last day of this 6 month project, then horray! We are on time and none of our milestones have been missed! I can tell the end users to expect delivery tomorrow.

If this happens after month 3, the hip-hip-horray! We are three months ahead of schedule and only "burnt" half the money budgeted for the project. Now, I, as a VP, have to decide if I want to release early or not.

If however, we have only completed 100 of 400 units on the last day of our six month project, then we have got a bit of a sticky problem. The good thing is that on an XP project, our VP would have known about this very early and not on the last day. Our thoughtful and responsible project manager would have told the VP about this months in advance and the VP would have time to do something about this. You would easily know this about 1 to 2 months into this. Since the VP knows this 4 months before the deadline, he/she could decide the following:

1) Increase our "burn" and get more people on the project.
2) Keep the "burn" steady and tell the customers to expect delivery in 18 months (100 units per 6 months).
3) Cancel the project.

<Spille>
In the velocity world, the business person sees "OK, we've completed 384 units. Our velocity is 80 units/month. What value do these units represent? Dunno. How much did it cost? Dunno. How does it compare to this other project over here? Dunno."
<Spille>

If the project management provides this information to business people. If project managers cannot provide this information to the business people, then why are they project managers? I am not evading the question, but how XP reports to people outside the team is not part of the XP. The project manager must conform to the requirements of their boss.

<Spille>
The real value in the system I've described is that everything is grounded in reality, which serves as a self-check. People can back-check the value of the various milestones, and quanitfy them. Dates and burn rates are straightforward.

All XP measurements are based in reality. Every week or two weeks you know if you are going to reach your goal or not. Stories are done at the end of each iteration. Software is delivered at the end of each release. Each iteration/milestone ends on a specific date and software is released on a certain date. XP teams generally do not miss their dates and encourage the customer not to change the date

<Spille>
But with velocity? What if you've done a bad job of estimating the fundamental "unit"? How can you tell that you made a bad estimate? What if a quarter of your unit estimates were bad? Can you tell?

You can only know if you made a bad estimate AFTER you have completed the work. Does the method you have the most experience with able to predict a bad estimate BEFORE the work is done? There is no way to determine before you work the problem if the unit is calibrate right. All you can do is rely on experience.

However, isn't that what project managers do when they scope a project currently? They say this project took 8 months with 6 people and cost $100K. Well, I only have four, so that is gonna be about 11 months since 1/3rd of 8 is about 3 months. So, I will say 12 months to be safe. Now 1/3rd the $100K is $33K. I know there are gonna be overruns that are around 10%, so 10% of $100K is $10K. I might have to add one or two at the end, so let's say that extra is about another $10K, no $15K. OK, so I got $100K + $33K + $10K + $15K equals $163K. OK, that is DEFINITELY too high, so I will make it $150K for a nice round number.

I have to say a big NO here. XP is not a buffet. XP is what you know after you've become so good at its practices that you can do them effectively when you need to. XP is also a philosophy based on the five values of Courage, Feedback, Simplicity, Communcation and Respect.

You can do some of the XP practices and be successful, but please don't call is XP. I make this distinction ONLY because some people tend to do some (small) collection of the XP practices, fail, then say, "I tried XP. It sucked." The bottom line is that they didn't try XP. It is awfully unfair to the XP community to blame their failure on XP and it's just downright counterproductive for the industry in general. It keeps people who would otherwise benefit from XP from trying it in the first place. That's irresponsible.

I didn't mean to pick at one detail of your otherwise wonderfully honest response; but it stood out at me so much that I had to comment.

Well.. I've heard this from Kent B. himself - the XP practices don't matter (and as usuall, he got some support from his trusty sidekick Ron J. :) ).
At the same time he said what really matters are the values you mention (and Ron followed up with "in fact, it's really just the courage that matters").
I could still dig out his position paper (from last November at OOPSLA) on XP practices, where amongst the other things he says that XP practices as he defined them had not taken into account quite a few things (he gives a list of examples), so it is definitely not one-size-fits-all.
Regards,
Vlad

Kent and Ron are XPerts, so they've gone past the need to know the XP practices. The rest of us mere mortals have not. :) Ron calls XP "What you know once you've done the practices long enough to be very good at them and know how they interact." I haven't done this yet. Kent calls XP "A community of practice of programming based on the four values." He's right, but I'm not sure that most people can do a great job armed with just the values. Perhaps they can.

One thing that I have never seen Ron promote, though, is doing some of the XP practices, then calling that XP. He is wont to say, "They are doing something different from Extreme Programming, which they also unfortunately call 'Extreme Programming'."

Of course, we all admit that XP is not one-size-fits-all. I think this is an area where the general community has misinterpreted our efforts. It is natural for a new process (of any kind) to go through a period where its practitioners try it everywhere and in every situation possible. The goal is to stretch its limits, see where it fails, thereby learning when and where to apply it.

Much of the community is still testing the limits. In a few years, we'll be better able to definitively say what works when and what doesn't work when. This is actually happening, as evidenced by the papers coming out so far. At that point, we'll look less like we're trying to convert the universe and more like we're thoughtfully applying our techniques.

That will go a long way to reverse the general perception about XP. We may still be the hippies of the programming world, but at least we'll be happy and our customers will be happy. I don't much care about the rest.

<Rainsberger>
One thing that I have never seen Ron promote, though, is doing some of the XP practices, then calling that XP. He is wont to say, "They are doing something different from Extreme Programming, which they also unfortunately call 'Extreme Programming'."

Of course, we all admit that XP is not one-size-fits-all. I think this is an area where the general community has misinterpreted our efforts. It is natural for a new process (of any kind) to go through a period where its practitioners try it everywhere and in every situation possible. The goal is to stretch its limits, see where it fails, thereby learning when and where to apply it.
</Rainsberger>

When it comes down to it, people want a process that they can apply in their environment, for their own projects. And the smart ones will start with someone else's approach and tweak it to their own needs.

In the above context, I believe XP is a miserable failure. I understand that's a provocative statement, but I think it's justified in this case. Far too often I hear the terms "...well maybe XP isn't for you", "If you're not willing to radically change your environment, you can't reap the benefits of XP", etc etc. When I see the volume of responses like the above, it tells me that XP is designed to work in a narrow development domain, and that it's very fragile if any of the core principals are changed.

This wouldn't be such a big deal - but XP advocacy approaches being rabid at time. Myself and others are constantly barraged by various media outlets screaming out that XP is the way to go, and when we probe it deeply one on one the response is often "Hmm, maybe it's just not for you...". It's a decidedly mixed message that's probably got its roots in some deep conflictedness in XP itself. The trouble is no one has articulated just what that is yet...

<Rainsberger>
That will go a long way to reverse the general perception about XP. We may still be the hippies of the programming world, but at least we'll be happy and our customers will be happy. I don't much care about the rest.
</Rainsberger>

With that attitude, XP won't get very far. The implication in your statement above is that if you do XP "right", you'll be happy and your customers will be.

It's far more enlightening to be honest and state where it _doesn't_ work as well as the successes. Until you make that leap, you're going to limit your converts to optimists and consultants out to make a buck.

<quote>
When I see the volume of responses like the above, it tells me that XP is designed to work in a narrow development domain, and that it's very fragile if any of the core principals are changed.
</quote>

I can understand that you'd have that point of view. There are mixed messages, mainly because there are many people trying very hard to do XP and get others to do XP. Too many voices yelling at once.

I see it this way: the XP practices are mutually-supportive. Doing them all together amplifies the effectiveness of doing any one on its own. Some practices have holes that other practices fill. I wouldn't want to do Collective Code Ownership without Pair Programming, because PP provides the necessary peer pressure to ensure that people don't mess up the code base. There are several such examples.

Many of those who say "XP is not for you" are probably being a little lazy. They don't know the answer, so they give up on you and save their energy to convince someone else. That's human nature and I don't think it's fair to hold that against them NECESSARILY. (Some of them should be shot, sure, but let's assume that they're generally not useless people. For useless people, nothing works.) XP isn't for teams that can't communicate with one another effectively, or that have irrevocable internal strife. But then, nothing team-oriented would work in that case.

<quote>
This wouldn't be such a big deal - but XP advocacy approaches being rabid at time.
</quote>

ALL advocacy reaches that point at one time or another. Please don't single out XP for that.

<quote>
Myself and others are constantly barraged by various media outlets screaming out that XP is the way to go, and when we probe it deeply one on one the response is often "Hmm, maybe it's just not for you...". It's a decidedly mixed message that's probably got its roots in some deep conflictedness in XP itself. The trouble is no one has articulated just what that is yet...
</quote>

Part of the problem is as I wrote above: so many of us want to do XP, but are having trouble finding places to do it. We want to see for ourselves how good it can be, so we want to force it in where it may not belong. I have seen the effects of that first-hand and learned from it. I will be more careful next time.

Installing XP requires almost universal buy-in within the organization. XP demands organizational effectiveness and does not try to cope without it. This may be XP's Fatal Flaw, but it may be the driving force behind rehabilitating some ineffective organizations. Time will well.

<quote>
With that attitude, XP won't get very far. The implication in your statement above is that if you do XP "right", you'll be happy and your customers will be.

It's far more enlightening to be honest and state where it _doesn't_ work as well as the successes. Until you make that leap, you're going to limit your converts to optimists and consultants out to make a buck.
</quote>

I have been talking IN THIS THREAD about the times that Pair Programming hasn't been successful. To state that I haven't been honest is just silly: first, you have no way to know whether I've been honest (prove that I haven't); and second, to imply that I would be dishonest in this conversation does nothing but invalidate the exercise. I assume that you are sharing your experience and observations directly and honestly in an attempt to stop the pro-XP folks from running away with things. I do the same from the opposite site. Why assume otherwise? Can this be effective or useful otherwise?

<Rainsberger>
I can understand that you'd have that point of view. There are mixed messages, mainly because there are many people trying very hard to do XP and get others to do XP. Too many voices yelling at once.

I see it this way: the XP practices are mutually-supportive. Doing them all together amplifies the effectiveness of doing any one on its own. Some practices have holes that other practices fill. I wouldn't want to do Collective Code Ownership without Pair Programming, because PP provides the necessary peer pressure to ensure that people don't mess up the code base. There are several such examples.
</Rainsberger>

My point is that XP seems to have an unusually high number of interdepencies, and as a result people try to sell the whole smorgasboard to management. And selling full-blown XP is difficult. Other strategies which to me are equally effective are not nearly as hard of a sell.

In otherwords - XP is more trouble than it's worth, and you can get the same effects using similar-but-different methods.

<quote>
This wouldn't be such a big deal - but XP advocacy approaches being rabid at time.
</quote>

<Rainsberger>
ALL advocacy reaches that point at one time or another. Please don't single out XP for that.
</Rainsberger>

OK, you got me there.

<Rainsberger>
Part of the problem is as I wrote above: so many of us want to do XP, but are having trouble finding places to do it. We want to see for ourselves how good it can be, so we want to force it in where it may not belong. I have seen the effects of that first-hand and learned from it. I will be more careful next time.

Installing XP requires almost universal buy-in within the organization. XP demands organizational effectiveness and does not try to cope without it. This may be XP's Fatal Flaw, but it may be the driving force behind rehabilitating some ineffective organizations. Time will well.
</Rainsberger>

See my comments above on this. And let me add - we should not expect a fairly low-level, developer-oriented methodology(*) to rehabilitate organizations. Business needs to accomodate some quirks of IT development, but ultimately the business should be driving IT, not the otherway around.

(*) - Some may argue the phrase "developer-oriented methodology", but I'll stick to my guns here. XP has some hooks for other players, and Beck et al have been doing things lately to remove the developer-centricness of the model, but ultimately I think XP favors developers heavily over other players in software analysis, design, implementation, and roll-out.

<Rainsberger>
I have been talking IN THIS THREAD about the times that Pair Programming hasn't been successful. To state that I haven't been honest is just silly: first, you have no way to know whether I've been honest (prove that I haven't); and second, to imply that I would be dishonest in this conversation does nothing but invalidate the exercise. I assume that you are sharing your experience and observations directly and honestly in an attempt to stop the pro-XP folks from running away with things. I do the same from the opposite site. Why assume otherwise? Can this be effective or useful otherwise?
</Rainsberger>

I have shared in this thread and elsewhere both the upside and the downside of my own approach to software development. I've tried to be as candid as I can on both sides.

In comparison, many of your statements have been an unmodified rah-rah speech for XP. Your one concession to failures is "sometimes it doesn't work". When I say "honest", I mean "fairly-full disclosure". If you want people to take your view seriously, you have to explain the bad with the good.

Certainly little can be verified in this forum - a certain amount of trust is involved in this sort of debate. But at the same time, if someone unendingly gives me the rah-rah speech and seems unwilling to point out flaws in their own favored approach, then I'm forced to conclude that they're not telling the whole story.

As with everywhere - truth isn't black or white. And despite lack of verifiability here, some people's writings have more weight in my mind because they show internal consistency and appear to objectively weigh the issues. And other posts (ahem) clearly lack objectivity.

I think that Extreme Programming has made at least three major contributions to the way that we understand and build systems.

1) Test-cases first. I think that the XP community drove home the promise of test-driven design. This practice is now broadly accepted well beyond the world of XP.

2) Continuous integration. We now understand that delaying integration means an exponential increase in the total pain associated with integration. XP programmers were among the first to integrate the tools needed to make continuous integration go, and the practice has broadly become a staple.

3) Code the simplest solution that will work. It's been my experience that better programmers are scaling back complexity in favor of simplicity. Rule 1 makes it possible to trust yourself enough to refactor a simple solution as you move forward, because you've got the safety net of an automated test in case you break something badly.

I do think that several XP practices are practically very difficult to sell to a management team. The first is the on-site customer. The second is pair programming.

In the end, I believe that XP has made a lasting contribution to software development, and I'm thankful for it.

I prefer to say "Active Stakeholder Participation" over "OnSite Customer". The former is Scott Ambler's term and I think it's more palatable for management. Most people agree that the stakeholders need to have ongoing input into the process of building software for the project to deliver business value.

The problem with ASP and PP is that management doesn't see the hidden cost of not doing it; they only see the up-front cost of doing it. Not only that, the hidden cost of not doing it is difficult to quantify, whereas the up-front cost of doing it APPEARS easy to quantify -- although it is easiest to quantify the cost incorrectly, such as "PP = 2x cost of my current project", which has been shown to be nonsense. (If your team costs you double to pair compared to solo, then you don't have a team -- you have a group, and if that's what you want, that's cool, but don't call it a team. :)

The challenge for us is to make the hidden costs visible and quantifiable, and I have no idea how to do that effectively. My worst fear is that, even if we did, management wouldn't buy it, because it's easier to say "PP would cost us double", "our customer can't be here" and so on. It's easier (as always) to maintain the status quo.

We're currently gathering "Voice of eXPerience" stories from people that have seen the problems that occur in XP projects. If anyone here would like to share their experiences and observations as part of the book, please let me know:

Anyone that follows any process like a religion is going to fail. Over the last 10-15 years, I've watched processes that presage RUP fail again and again, including one that followed the ICONIX model to the letter. I've also seen an number of agile process advocates do really stupid things, but I've yet to see the same failure rate that I normally would attribute to projects that crank up with a RUP-like process. Frankly, process is never a substitute for solid judgement, experience, or team leadership. If you have those things, you can probably succeed with any "process" as long as there is some structure. I personally would be very interested in this book, but I would be disappointed if it winds up being an advocate for a religion that has at least as many flaws as XP.

>> We're currently gathering "Voice of eXPerience" stories from people that
>> have seen the problems that occur in XP projects. If anyone here would like >> to share their experiences and observations as part of the book, please let >> me know:

Why not call it:

"XP Refactored: If People find out XP works, no one will buy my ICONIX books or pay big bucks for my consulting services?"

No actually, if his book did that, he might have to use metrics. That would mean using a calculator. Having grown up in the age of Current Affair journalism, looks like such 'thinking' (lack thereof) has metastacized to our industry. O joy.

I've posted a message on JUnit test cases and code generation. At a high level, this mail is related to how XP practises, such as writing unit tests, can be brought into projects that are developed using non-XP methodologies. I would like to believe that there are quite a few such projects and people using such a combination. Please give your thoughts on the same.

PP - OK - so you hate it. You make many scenarios where the pair is ill matched and in every case, if I were the lead developer, I would solve it with PP. If you have a weaker developer you can't afford to risk development time waiting for them to mess up so you MUST pair with someone who knows the ropes, even if it is the lead developer/architect. If I had a developer who on their own used an editor and was slow, task one would be to retrain them. If one developer was not to be trusted with micro-architecure decisions I would not want him/her solo.

So I think you make a case for PP, and if you hate it, I would say the project comes before your likes/dislikes. If you can't work with other people you are the problem!

I was doing my masters when I hopelessly engaged in a software project. I was unaware at that time that i was aiming pretty high. This struck me when i got the design and start implementation, and things went pretty bad for months. That was when Ozgun joined into the project. Without even heard about PP, we started doing it, programming in parallel when things are easy, and tackling harder problems with PP. It helped us a lot, so as the project grew we started preaching it to the other people and start pairing with them too.
Ok, this was an academic project, not really enterprise level, but PP made it possible for two inexperienced students to team up and produce ten thousands of source code (with good quality IMHO) in a few months. And socially i enjoyed it very much.
But i also agree that when the people i paired up with is not as fast as i am/ do not know the architecture enough/ gets stuck in the details yeah PP can be very very frustrating. But then those people start learning the ethics of pairing and start coming up to sessions prepared then it is again all fun.
Until that time I didnt pair with people which i find socially repulsive, so i can not comment on that issue, yet you do not need to be a genius to guess that pp wouldnt work, but hey that team wouldnt work anyway.

< Demir>
But i also agree that when the people i paired up with is not as fast as i am/ do not know the architecture enough/ gets stuck in the details yeah PP can be very very frustrating. But then those people start learning the ethics of pairing and start coming up to sessions prepared then it is again all fun.
Until that time I didnt pair with people which i find socially repulsive, so i can not comment on that issue, yet you do not need to be a genius to guess that pp wouldnt work, but hey that team wouldnt work anyway.
>

As I've said before, I think pair programming is a valuable practice when applied _very_ judiciously. And it should never be forced. In short there's nothing wrong with two programmers working together for awhile to solve a particularly vexing problem.

Going back to your statements, I rather disagree with your last point. While pairing obviously isn't going to work with people you don't socially get along with, I've found over and over again that you can successfully collaborate in general with people, even if you don't like them. Or even actively dislike them. The difference is that collaboration typically involves small, well-defined areas of interface, and large areas that are the domain of one person on the team. Yes, you do have to interact, but only when doing initial design or when issues come up. In that sort of environment, if you're reasonably professional you can work with almost anyone and still be very productive.

This is why I'm against _mandated_ pairing on projects - there are too many combinations of people that won't work out, and it seems to me to be a formula for failure most of the time. Allow people to work together when it suits them and makes sense, but please don't force them to do it!!

This kind of stuff just makes a charade out of our community. All we learn is that Cedric doesn't like to work with other people, and plus managers want productivity. Dude makes Ebert and Roper look like Shakespeare. There is a LOT more to XP than pair programming. Plus, pairing as an idea has been around for much longer than XP. Go read Larry Constantine's book in which they used METRICS to determine that buddy teams got work done faster. How about the claim to flattening the change curve? What about the iterative notions. It's pointless to even engage people like this. Has Cedric read Scrum, or Cockburn's Agile? Clearly not. And his experience is in what? Following a spec that someone else stipulated and just finding a way to implement it? I'm impressed. No need for stories, no need for features and complexity growth. What is his methodology? RUP? Sure. I bet.

I worked for a few months in an XP shop, and just recently learned that I was the first to go of all the senior programmers. I couldn't take pair programming for one. Either you're watching some double-speed genious code like his hands are on fire, or you're dragging some novice along with you as you try to get some work done. Also, it's like being on stage all of a sudden. Sit down, have someone stare at you expectantly, and try to think out a complex problem that you have to solve. I don't work that way. I work best alone, and I like to design stuff. XP hackers just like the SLAM stuff together like they're all on speed. I had this consultant (supposedly an XP expert), who was the senior XP coach on the team, tell me to implement localized text by putting all the translated text directly into the method calls, AS STATIC TEXT. When I suggested RESOURCE BUNDLES and told them that they were all insane, I got a lot of dirty looks. Nobody was interested in spending five SECONDS of time designing anything. It was just HACK AND REFACTOR, and the code and the progress showed it. It was total bullcrap. The pair programming alone drove me crazy. Then there were the stupid useless little story cards, intead of real specs. Nobody has to make any decisions. Just write all the thoughts you're currently having onto little index cards, and then change your mind tomorrow about them. No big picture, no "velocity", it was all total hyped bullsh*t as far as I could see. Then the head programmer would program by himself and tell everyone else to pair. Pairing was mandatory and nobody had their own computers (total crap also). This methodology will DIE within five years, or at least I hope so. I've never seen such garbage in the twenty years I've been coding. It's a fantasy turned into a bunch of book deals, all emerging from a failed project at Chrysler. What a joke. Read this book if you're even THINKING about XP on a project you're responsible for. They'll tell you about that failed Chrysler project (four years without a finished product -- HA!) and much much more in: http://www.iconixsw.com/xprbook.html

I worked for a few months in an XP shop, and just recently learned that I was the first to go of all the senior programmers. I couldn't take pair programming for one.

I don't know why folks consider XP and pair programing as synonymous. The true genius of XP lies in its distrust of the future and premature extensibility. XP demands that engineering focus entirely on current requirements and exclude any notion of future evolution, such as extensibility or vaguely anticipated requirements. This genius obsession with only current requirements lives on in more modern methods such as Scrum. A big part of agility is not being burdened with hypothetical future requirements (eg, analysis paralysis, etc).

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.