Inside the World of Extreme Programming

Webi writes ""XP[http://www.extremeprogramming.org/] works best for medium-sized teams where a product can be delivered in stages, and where there's freedom to experiment with some of the more controversial techniques," author Ron Jeffries said. http://www.newsfactor.com/perl/story/20348.html"

Comments

Correct link..

[Anonymous Coward]

is http://www.extremeprogramming.org/ of course

Pair programming

[Lumpish Scholar]

I've always found the whole "buddy programming" concept (part of XP), where one person watches the other code and points out errors, to be incredibly annoying.... you're wasting a good programmer having them sit there and call things out

Right, that would be dumb; but that's not what XP calls for.

Pair programming calls for two people working together. At any given instant, only one person has the keyboard and mouse; but they get passed back and forth, and the person who's not typing is doing a lot more than "watching." It's as natural as two people designing together on a blackboard, once you get the hang of it.

Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).

Does it always work, for everyone, in every project? That's an open question. The only way it'll be answered is if more people try to program in pairs.

The definitive book on the subject is Pair Programming Illuminated by Laurie Williams and Robert Kessler (Amazon.com, BN.com); recommended.

Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.

Re:the weakest link in XP

[Lumpish Scholar]

Is the degree of customer involvement that they expect.... How many clients are willing to assign an employee to work with/at the software/website vendor full-time?

It makes more sense for in-house development projects, where the "customer" already has an office in the building, and just reports to the programming bullpen* rather than to his/her own office/cube/whatever. The first serious XP development effort was an in-house project called Chrysler Comprehensive Compensation; the "customer" was the payroll department, and relatively easy to get "on site." XP has been strongly influenced by the patterns from that project.

*A lot of XP gurus like open space plans for development teams. YMMV.

The most common alternative to Customer On Site is Victorian Novel Requirements: the customers write hundreds (thousands) of pages of requirements (which can take as many staff hours as Customer On Site), throw the book "over the wall" to the development staff, and then complain when they didn't want what they originally asked for.

I agree Customer On Site may not always work. Lots of constant communications with the customer, in some form or another, is necessary for any successful software project, XP or otherwise.