Beck's strategy worked. By 1997, Chrysler had a new payroll system, and Beck and Jeffries were writing the first of many books on the XP "methodology" and convincing others to give it a try.

XP's ensuing rise from ad hoc method to next big thing is as much a testament to the evangelization skills of Beck, Jeffries et al. as it is to the virtues of the XP method itself. Five years after the fact, the number of XP testimonials trails well behind the number of XP books -- currently numbering more than a dozen on Amazon.com.

Such numbers prompt skeptics to wonder if "extreme programming" shouldn't be changed to "extreme hype." Doug Rosenberg, president of Itrix Software, a Santa Monica, Calif., company whose consulting and tutorial services now compete head-to-head with the growing number of XP tutorials in the marketplace, likens the XP phenomenon to a "brush fire" -- heavy on the flash but light on the fuel.

"Some of the ideas are actually pretty interesting," says Rosenberg. "They've actually contributed positively to the industry in terms of having people pay more attention to unit testing and automated testing frameworks. [But] the way they've marketed it, creating this whole fad phenomenon is objectionable to me."

Matt Stephens, another XP critic, prefers to zero in on the weaknesses of the XP approach itself. His August 2001 essay "A Case Against Extreme Programming" is the one that likens the XP approach to a ring of poisonous snakes. The ring analogy comes about, Stephens says, because of the XP proscription against "dabbling" -- adopting only certain elements of the XP approach. In order to make the XP methodology work, project managers must employ all the elements, according to XP proponents.

But Stephens considers certain elements risky. For example, XP places a low priority on source-code documentation, a common developer bugbear, on the rationale that well-written, well-tested code will be easier to understand by third party programmers than well-documented, poorly written code.

"If everything goes according to plan, XP might just get you there," Stephens warns. "If something goes wrong (e.g. your key programmer leaves; the on-site programmer, who is essentially the walking requirements spec, is hit by a bus; the janitor accidentally vacuums up your pile of story cards) then things can really go awry."

Beck downplays the argument that XP is an all-or-nothing approach. Still, he does note that the project leaders who report the most success with the methodology tend to be the ones who put aside the cultural obsession with rigid specs, an obsession inherited from less flexible fields such as civil and mechanical engineering, and approach XP's design-on-the-fly philosophy wholeheartedly.

"My strategy has been to say, 'Let's push it,'" Beck says. "If you think you're doing XP, but all you're really doing is a little bit of testing and weekly planning sessions, you haven't fundamentally changed the social contract yet."

After all, Beck notes, it was the gaping disconnect between management and software development that prompted him to develop XP in the first place. Rather than paint XP as yet another revolutionary trend in the software business, Beck prefers to describe it as a much-needed "return to civility." After nearly two decades of working on both sides of the line, Beck says he was looking for a way to eliminate, or at least diminish, the sociological disconnect that seems to characterize most software projects.

"Going into XP, I was very conscious that this had to be good for both sides," he says. "The suits can't say, 'We need these three things by Friday,' and the geeks can no longer say 'That's impossible.' With XP, you've got a situation where the programmers come back and say, 'We can give you two out of three. Which do you prefer?' Then the negotiating begins."

Whether or not other programmers and managers accept the bargain, XP is already lowering stress levels in some corners of the industry. Tom Clarke, the Union Square Internet Development programmer currently using techniques such as pair programming to fulfill his company's latest development contract, a Web site rebuild, says his first brush with XP was a very positive experience.

"I was working on a project for another company that involved sending out 50,000 e-mails every night," says Clarke, recalling his first brush with XP. "I'd go to bed wondering if the e-mails were going to the right addresses or if they were even going out at all. I had no way of knowing for sure. When I stumbled onto the notion of unit testing, I started experimenting with it. By the time I was done, I came up with a few tests that verified that, yes, the software did what I said it did. Suddenly, I found I was sleeping a lot better."

Since then, Clarke has helped to form a New York City XP interest group which meets in the Union Square Internet Development offices one night a week. As for his programming mate, Eli Collins, he reports a similarly positive take on the XP methodology.

"There's none of this worry about breaking things three days before release, which is a serious concern on most projects," he says. "[With XP], you can sit down with a client and if they say they want to do something new, you can say, 'OK. We're ready.'"

Recalling the earlier pair programming episode, Collins adds with a smile, "It's also a confidence booster when you know that stuff like a missing 'i' isn't going to come back and bite you."

Recent Stories