Andrew Binstock, a columnist at SD Times, makes some very valid and interesting points concerning the software methodology known as Extreme Programming (XP) in his article 'Not So Extreme Programming'.  As one that has (in limited fashion) used Extreme Programming in the past I have been privvy to some of the benefits as well as some downfalls of the technique.  There are some definite key tenets of Extreme Programming of which I am a fan.

For example, I am a proponent of the 'Stand up Meetings' in which developers gather at the beginning of each day to set in order their tasks and resolve any foreseen roadblocks.  It's a great opportunity to make sure all of your ducks are in a row and everyone is ready to proceed with the days activities.  I am a big fan of test-driven development (TDD); I feel, however, that oftentimes developers will get too bogged down in writing tests so much that actual productivity is sacrificed.  I also am a fan of the story design technique in which a task or an activity is designed and the key actors and players are identified though I think the implementation should be different (not 3x5 cards).

I feel, however, that its disadvantages outweigh its advantages.  To begin with, in the XP way of things, applications are designed bottom-up which makes it very difficult to reach your intended destination with a solid packaging; it's a bit like building a skyscraper starting with lots of little bricks without a solid, preenvisioned foundation.  This lack of scope and real design can be detrimental to the end product.  XP projects seem to be especially geared towards smaller products; large applications are often too complex.

Refactoring, as a practice and a principle is paramount to programming and good software design - a tenet not overlooked by XP.  It seems, however, that it promotes refactoring ad nauseum.  Constant refactoring can be detrimental to the success of an application as developers are often dealing with minutiae that frankly are not that important or can be optimized later or in different ways.

Andrew to me hits his point home when he says the following:

The foundation of XP, in my view, is part of the problem: It is a radical embrace of an approach that goes from the particular to the universal. It is the purest form of bottom-up development: You never design more than what is immediately needed, you write the least amount of code that will fulfill your next test, and you design the test to provide the least amount of incremental change. After you’ve written lots of tests (frequently thousands), you clean up your code by using one of 72 refactorings—which are specifically analyzed techniques for cleaning code without changing its functionality.

The fundamental problem with this approach is that software today is complex and large, so it cannot be designed properly by using the least-increment approach and hoping that a sound product will eventuate through the organic accretion of lots of small design decisions (followed up by code cleaning).

Large, complex projects have to be designed top-down and the code must be developed to that design—regardless of its complexity.

Now, after having said all of this, I don't purport to be an XP expert by any stretch of the imagination.  Our embracing of the XP methodology was scattered at best and we picked and chose that which we saw as relevant to our team and our environment - much of it worked for us, though not everything did.  I'd welcome your comments and insights.