In an earlier entry I said, “XP is an over-reaction to water fall development methodologies.” I was wrong. I still think XP is an over reaction but I think it is reacting to heavy-weight methodologies rather than water fall methodologies.
The primary difference between XP and other methodologies is that it is that XP urges you to not do a lot of things you have been told to do in the past, because “you are not going to need it”, such as design documents and anticipated features. This mentality definately has some benefit — it is very easy to over-engineer software — but I think that most implementations of XP take it too far. It is easy to just decide not to do anything you do not need at this very moment. I think this sets you up for trouble in the future.
For example, I have been told that it is uncommon for Java code implemented using XP to have javadoc comments. This follows from the basic principles of XP, if you apply them with little thought. You do not need the comments when you are writing the method — you just wrote the test and you know what the method is suppose to do — so writing a comment is a waste of time. However I think that method and class comments are invaluable, they allow for much easier maintenance and refactoring in the future.
I suspect that most of my issues with XP come from poor implementations of the process. On the other hand, it almost does not matter. XP is intended to produce better software more reliably and if it is difficult to use correctly then it is unlikely to achieve that goal.