Individual Xp Practices

I've recently heard a number of criticisms of ExtremeProgramming that start with the following assumption...

: "XP is built from a number of individual practices that individually would do nothing but hurt your project but together, due to the magic of reinforcing each other, result in great results."

and then attack the reinforcing idea, thus "proving" that XP is bad.

While XP says that you have to do all the practices to get the full benefit, due to the fact that they reinforce each other, the assumption that any particular practice is bad on its own is just misinformed. KentBeck's original description was that XP starts with known good practices and takes them to extremes.

So let's take a look at the ExtremeProgrammingCorePractices (and maybe other XP-isms), to see if the individual practices are good or bad:

Can anyone find a single XP practice that if applied intelligently all on its own would consistently produce bad results in projects? I think not!

But any "intelligently" applied practice will always produce good results, by definition. And there are no reasonable practices that will "consistently produce bad results". This is a silly question.

Yes, it's silly. But even more silly is the number of people who start with true statement that "XP practices reinforce each other, so you have to use them all to get the full benefit" and assume from that that "each practice on its own must be unworkable."

From what I've seen, each XP practice, on its own will give some benefit. So, if the practices did not reinforce each other, you'd expect XP to be beneficial -- possibly improving development by 2 or 3 times. But the practices do turn out to reinforce each other, so the actual benefit is more on the order of 10 times.

Is CopyAndPasteProgramming, applied consistently across a project, more likely to result in a more maintainable system, or a more unmaintainable system? How about the other AntiPatterns?

RefactorMercilessly, without UnitTesting would be an AntiPattern. But refactoring (I claim) would not.

Is there any XP practice that when applied in isolation and in moderation would normally be an AntiPattern?

Does the PlanningGame make sense if you don't also have an OnsiteCustomer? (Yes - but you have to spend more time understanding the stories up front)

UnitTests / RegressionTesting:

There are books on the subject of automated regression testing. People make careers advocating just this one practice. The Institute for Certification of Computer Professionals (ICCP) includes a number of regression testing questions on its certification exams.

All of this is quite independent of XP.

Automated RegressionTesting is a well established "best industry practice."

RefactorMercilessly / RefactoringImprovingTheDesignOfExistingCode / RefactoringLanguage

If improving existing code was such a bad idea, then why are respected vendors signing up do do it? (See CategoryRefactoringBrowser, particularly RefactoringBrowserForJava)

Testimonial: "For almost 20 years, I have done refactoring (without other XP practices) on dozens of projects in a number of computer languages -- always to profoundly good effect. Even without UnitTesting, refactoring is a good thing. (But without UnitTesting you have to limit the refactoring you can do, and hence the level of benefits.)" -- JeffGrigg

But what about the corollary, namely CollectiveCodeOwnership, which means everyone can change anything? I am all for refactoring, but without UnitTests, wouldn't it be easy for one programmer's refactoring to (1) break lots of other components and (2) introduce bugs into the system?

Without CollectiveCodeOwnership, you'll find that you can't refactor everything that needs it. You can't remove code smells without getting into protracted negotiations with the owners of the foreign code and often their PointyHairedBosses.

Without UnitTests, even conservative refactoring will occasionally introduce bugs into a system. But then, without UnitTests, even the most minimal and short-sighted maintenance tasks will regularly introduce bugs into the system. But I've found that in practice, the maintainability improvements that refactoring gives you quickly override the risks -- on the order of 100 bugs fixed or avoided for each one bug introduced by refactoring.

Would you be comfortable with RefactorMercilessly if you didn't also have UnitTests to verify that the refactored system works as it did before?

No, I wouldn't be comfortable; yes, refactoring mercilessly would be a problem in the absence of unit tests. But the point is that even without unit tests, conservative refactoring can be a significant benefit to a project.

OnsiteCustomer

Now who would not want good communication with an authorized customer representative?

SmallReleases / IncrementalDevelopment/IncrementalIntegration/IncrementalDelivery

XP did not dream up this concept; it's well established in the industry. Even Rational, and other established "big" methodologies preach the advantages of incremental development and delivery of functionality.

PairProgramming -- possibly the most controversial practice

Has proven effective in other engineering disciplines. Was mentioned (positively) in MythicalManMonth. Has been proven effective in scientific experiments.

CategoryXpCritique