Xp Lite Considered Harmful

Refactored from XpLite and XpJr by BenAveling

This page is a discussion of the damage XpLite may do to the ExtremeProgramming message.

XpLite does not make XP better by its inventors' standards, it makes it worse. XP is designed carefully to be the least methodology that works.

Just as C++ has been beating Smalltalk because it is easier to adopt but then locks people into an inferior language (spoken as a C++ user), we must beware that XpJr or any such inferior but easier to adopt pseudo light weight methodology does not become a blocker to Xp. Having a derivative name is part of that problem, as discussed in XpJr.

I believe this issue may merely represent one's belief on ContinuousImprovement versus "Paradigm Shift" improvement. If one believes that improvements are best done by making adjustments to one's current environment, then XpJr or XP-Lite is an inevitable result. If one believes in improvement through major paradigm shifts, then XpJr is inappropriate. I don't want to argue which approach is correct, just highlight that there are rational arguments for either.

Having a derivative name is a symptom of: a - XP is popular in discussion groups; b - it is hard to get adopted. Therefore, an AlmostExtremeProgramming discussion is inevitable. Anything with a different name will be different, and hence not XP-ish and not fit in the popular discussion.

Having said that, I'll join RonJeffries in the thought that "almost XP" or "XP minus something" entirely misses the point of XP. XP says, "Do this and all of this, and if you do all of that, good things will happen. Leave bits out and you are on your own." There are chunks of that discussion all over wiki. XpLite is not "lighter" than XP, it is just less disciplined, and when you remove the discipline, you will have to substitute other, less efficient and probably less effective mechanisms, and live with that.

But doesn't this miss the point that TransitioningToExtremeProgramming is difficult and in most cases can't be done all at once? It's not adequate to condemn the name if an alternative is not suggested in its place.

p.s. I flog CrystalClearMethodology as an alternative to XP for those who can't or won't do the real XP. For me, the consequences of using a different name are apparent... on the plus side, you won't mistakenly think you're doing XP if you use Clear. On the negative side (for Clear), you won't naturally think of CrystalClear if you decide to not-quite do XP. You might think of AdaptiveSoftwareDevelopment or Scrum or FeatureDrivenDevelopment or, or, or...

-- AlistairCockburn

The "all or nothing" mentality of XP is really what seals it away for me. The buzzwords and tone all create an "IT Fad" smell to it, but this is something to be expected from any new methodology. But a methodology so brittle that it can't brook the slightest deviation is not one I would dare to inflict on a development team. Thankfully for XP, there is no need for such a Nicene Creed, because real world examples have shown that cherry-picking bits of XP still results in measurable, repeatable, and sustainable performance gains in spite of the doom prophesied for those who stray from the true and complete path. I aim for daily review, but not pair programming. The customer phones in to meetings, but they don't have to pitch a tent. Etc.

Indeed. All these years later after the methodology was introduced, I still cannot bring myself to use the term "eXtreme Programming" (in fact it sounds even more like a parody of Mountain Dew ads now), and I simply introduce story cards, close collaboration, pair teams (can't do it on my latest project since I'm the only programmer) and so on. Cherry picking. I can simply point to this very page as a prime example of the ills that result from drinking the entire glass of koolaid. I'm sorry that that's illogical, ad-hominem, what have you, but the True Believers are bringing it on themselves. I've never had to reserve any quantity of ridicule for RationalUnifiedProcess, for example.

CategoryAdoptingXp