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

Re:Correct link..

[fredrikj]

XHTMLC (eXtreme HTML Coding) might have saved us from that mistake.

Buddy Programming kind of annoying

[0x0d0a]

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. Maybe you're going to fix something in five seconds (a typo), and it gets called out. Maybe you have a syntax error that the compiler (which isn't getting a salary) could easily catch, but it gets called out. Plus, it makes me nervous to have people watching me and constantly interrupting my flow.

Also, you're wasting a good programmer having them sit there and call things out.

Maybe it's just me and some people really like XP...

It is when you do it wrong

[Anonymous Coward]

The 'buddy' isn't supposed to second guess you or the compiler, they are supposed to think strategically while you think at a tactical level.

Switching thinking modes is incredibly difficult to do by yourself but imagine your 'buddy' as 20/20 hindsight in advance. Remember: a stitch in time saves nine.

Oh and if the 'buddy' has something tactical to offer (i.e. code) then give him the keyboard and take a step back (mentally, of course).

the weakest link in XP

[josephgrossberg]

Is the degree of customer involvement that they expect.

To quote their site:
"One of the few requirements of extreme programming (XP) is to have the customer ... be a part of [the development team]. All phases of an XP project require communication with the customer, preferably face to face, on site. It's best to simply assign one or more customers to the development team."

WTF? How many clients are willing to assign an employee to work with/at the software/website vendor full-time? None, in my experience.

Unless you're dealing with an utterly massive project for a heavily-staffed client, their IT guy leading this effort has more responsibilities than this one project.

Re:the weakest link in XP

[budalite]

If the customer is not willing to commit (somebody's) significant time to the project, it's pretty much a dead horse, waiting to fall. If the customer is not , at the least, completely involved in defining the requirements and the acceptance tests the final product will not be what the customer wants. Period. It might be what you have on record as what the customer asked for, but it will never "fly" for simple lack of interest, and you will have no follow-on work. If you are not serving the customer, you will not have a customer. This has been my experience, anyway. (Perhaps you have been luckier. If so, don't count on it to stay that way. Lots of out-of-work developers out there.) ttfn

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.

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:Driver's Seat

[phamlen]

It's definitely not trivial - it's one of the reasons that people continually mention how to arrange office space to help XP.

We put the computers on a wide table in the center with enough space for two people to sit. When someone wants to switch, the other person slides to the side.

The other key element is to provide breath mints at every station.My personal belief is that pair programming is best done when there's enough space and breath mints for everyone involved. :)