No. In college, I followed the c2 wiki where XP was crafted, out of the ashes of the Smalltalk-based Chrysler payroll system.

It was a bunch of practitioners sick of being told by MBA-types (or modelling "architects" that couldn't code) of the proper way to write software.

Almost everyone in modern software development has been impacted by XP, if you think through some of the practices that almost no one mainstream had heard of or were discussing in 1999 until XP:

- Customer is on the team (Often the biggest factor in IT projects)

- Test driven development (now BDD)

- Continuous integration (now Continuous delivery and Devops)

- Design improvement (refactoring)

- Small releases (now "Lean Startups")

- Planning game (or estimation without Gantt charts and WBS)

Detractors focus on the controversial practices like pair programming as if they were lunatic. Or on consultants making money flogging a crap methodology. I don't think consultants could make money on XP back in the day - it was too foreign and extreme.

Agile was born off the fumes of XP, to give people methodological freedom while agreeing to the same principles. This unfortunately enabled legions of consultants to invent their own whatever-the-hell method for their client and subject employees to it. But it also helped some teams to deliver faster and higher quality than they would have otherwise.

XP - to actually be XP - is no less prescriptive. Either you follow the 12-step program, or you're a heretic. Now small-a agile is certainly a good thing - but like Nietzsche I am suspicious of any attempt to systematize what should be organic.

One of the XP rules is "fix XP when it breaks". I dispute that it is prescriptive. Retrospectives provide a mechanism for changing process.

For the curious [1]. Which brings up a point that I try to make with colleagues about any method/process. If you apply them blindly you might get lucky, but you'll probably get terrible results. They have to be modified to suit the personalities and capabilities and needs of the team, the company, the industry.

[1] http://www.extremeprogramming.org/rules/fixit.html

Even if Extreme Programming isn't followed exactly, many of the practices that these reviews attack are common in today's development.

But the very core of XP was that it did have to be followed exactly. That there was 12 specific things you had to do. All of those things were existing things, that people already did. It was precisely the "doing all 12 of them exactly as we say" that was XP. And it was total BS.

I think the essence of extreme programming is still with us.

Have a look at http://en.wikipedia.org/wiki/Extreme_programming

Many of those principles and practices are followed by my team. They don't all suit every project, but many do.

> Who does "extreme programming" nowadays?

Xp compared to the things that came before it, or to the things that came after it?

If you compare the opposite poles of Xp, and the things advocated in those 1-star reviews, the way that a lot of successful bushinesses develop software is a lot closer to XP than "pre-Xp" software methods.

It was a watershed for many. In fact, I would agree that the XP and TDD side of the argument won the intellectual debate.

I do. I might be biased as my first work experience was using it extensively (and we were quite successful doing it). So far, it is not rare that I can find mission where people, once the mess cleaned a bit with their current environment and trust established, are willing to give it a try, progressively and in good conditions. The general feedback I got is quite positive.

It's an amazing way to bill extra hours as a consultant without being held to any standard of quality :)