XP as Over-Reaction (Redux)

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.

2 thoughts on “XP as Over-Reaction (Redux)

  1. I would strongly disagree. To me, there is far more of a fundamental difference between XP and waterfall than there is between XP-as-lightweight compared to heavyweight methodologies.

    Documentation, processes… all of that is fairly irrelevant compared to the main thrust of any agile process, as compared to bad- [oh sorry – I mean] -traditional processes

    Traditional processes work on the assumption that it is POSSIBLE to predict the course of a software development.

    It is not. And it’s not a surprise that more than 95% of all software projects fail.

    The fundamental, and only really important tenet of all agile processes is they toss that [stupid] assumption, and say “requirements, directions, plans, acceptance, timelines, resources and everything else can and will change throughout the project – let’s set up a structure to deal with it”

  2. I think the lightweight vs. heavyweight is a reasonable criteria, though not the only one, on which to base comparisons of methodologies these days. Most modern methodologies basically accept that software development projects cannot be effectively predicted. I know of no one who thinks water fall methodologies work, so we have won this battle.

    But among the remaining methodologies what differentiates them? For me the primary feature of XP is that it attempts avoid all unnecessary work. To the point that it modifies really basic processes, like requirements gathering and coding. I am all for avoiding unnecessary work, but I think it is worth thinking critically about whether each particular bit of work is really unnecessary or not.

    To be clear, my post was specified targeted at XP, not agile methodologies in general. On the whole I prefer agile methodologies. I just think XP might be a little too extreme.

Comments are closed.