Why Call It Xp

I don't understand WhyCallItXp. (Is it appropriate to start a page with a statement of the title's negation? :)

If it had a buzzword-compatible name, it seems like it would be easier to sell to many of the people I've tried to explain/sell it to. Something that made it sound more old school... In fact, I've been tempted to brand our particular version of XP with some acronym like "Disciplined Evolutionary Architected Development", or DEAD, for short, and sell it that way until we were actually doing it.

So given that the name of the practice is XP, why is it like that? Why choose a name that makes 50% of all people I talk to about it have to say "What, programming with a laptop hanging one handed from a cliff face?" I'm not kidding, I've heard this EXACT joke about the name XP in just about every third interview, and at least half make some crack about extreme sports generically.

-- JeffBay


ExtremeProgramming was a term developed by a manager to sell his development methodology to programmers. Knowing that they liked extreme sports such as snowboarding, he called it ExtremeProgramming. It worked. Now programmers want to use it.

Extreme programming is really BusinessValueOrientedProgramming. I prefer to call it that because that is what it really is. -- JonGrover

That wasn't my experience of it, but you may be right. Here's my experience of it.

I had this stuff going at Chrysler that was really interesting, because it flouted ConventionalWisdom. I kept telling my friends about "this stuff I have going at Chrysler" until I got sick of it. I needed a name.

Here is the difficult part. You have no money with which to spread the name you create. You have no money with which to protect the name from charlatans. You are certain of the value of thing you are naming. How do you pick a name which is simultaneously: So, "extreme" as in ExtremeSports? (see DeepPlay? [1] for an excellent introduction). Extreme athletes prepare themselves and their gear meticulously. Then they go and, without letting fear interfere with their performance, do impossible things. And "programming" to remind us all that at the end of the day it is the running program that matters. This is in reaction to a boatfull of predecessor methodologies that forgot programming. -- KentBeck

[1] http://www.amazon.co.uk/exec/obidos/ASIN/189857314X/ (and not ISBN 0679771352 )

I didn't mean to offend you. Extreme Programming has been successfully sold to programmers. Now it needs to be sold back to managers. Since the real value (to mangers) of extreme programming is to manage the resources allocated to various business values, rather than having one business value drive out the others, I thought BusinessValueOrientedProgramming might be a good name to sell Extreme Programming back to managers. BVOP is accurate, not catchy, not short, not easily nicknamed, and hijackable so it only passes one of the criteria. -- JonGrover

Well maybe 'BOP' might be a good nickname. Or maybe not, perhaps 'BOP' might make programmers think of what managers would do to them it they don't toe the line:-)
"I don't think many people would be excited about a book on "Moderate Programming". New markets, new technologies, new ideas aren't forged from moderation but from radically different ideas and the courage to challenge the status quo" (JimHisghsmith? in AgileSoftwareDevelopmentEcosystems).

Lots of reasons not to: DontCallItExtreme.


When I heard about XP I was immediately excited. I especially loved the name, because it puts the focus back where it belongs: on the only thing that is truly essential to producing software. (Other things are useful, but you can create great software without them. You cannot create great software without great programming.)

I also think the name is great for the very reason you describe with this statement. It stands a good chance of excluding the very people that we need to push out of the software industry.

Am I one of the people who needs to be pushed out of the software industry? Who? -- JonGrover

I don't know. That depends on whether you purvey the idea that manufacturing management "know-how" like CMM or ISO is part of great software creation, that building software is like building spark plugs: design and construction should be done by different people, that non-programmers should define the process of *how* programmers create software. Are you among the endless parade of non-programmer process managers, non-programmer configuration managers, non-programmer designers, and non-programmer architects who have insinuated themselves into the field of creating software? Do you believe that subject matter experts should be set in a room for weeks or months - perhaps with a few other non-technical "analysts" who couldn't possibly create the end product - to produce a specification tossed over a wall to the waiting hoard of dozens of incorrigible, overpaid typists (programmers)? Do you think that creating software is a repeatable, mechanical translation of "captured" knowledge from specifications into computer mumbo jumbo? Do you think that excruciatingly precise UML is critical to success, or that designs can be worked out perfectly on paper prior to writing code by people who don't write code? Do you think that processes create great programs? Do you run a "software development organization" where technical skill is not considered a "core competency" but something best purchased by an infrastructure vendor?
