Response to The Case Against XP

I mentioned in passing that I had read an article titled The Case Against Extreme Programming, written by Matt Stephens. The article starts with the following:

There are a lot of misconceptions about XP. [...] This confusion doesn’t help the cause, either for or against. XPers are understandably annoyed when their methodology is criticised for being something that it is not.

My opinion is that he too has misunderstood things. This is a problem with XP, that it is too hard to understand. Some parts of XP – like how design and exploration actually works in XP – took me well over a year to get the hang of, and there are still parts, after studying XP for nearly 2.5 years, that I feel I don’t understand well enough.

The trouble I have with Stephens’ article is his tendency to drop sarcastic remarks – “Never mind, [the customers will] cheer up when they discover how cool all the refactored algorithms are behind the scenes.” – or “Changes can often mean a change in design: let’s build a car, no a kettle, no an aeroplane, oh it doesn’t matter does it? It’s all stuff…”. It’s clear that he thinks XP is stupid, but commenting in this way, to use his own words from the intro, doesn’t help the cause, either for or against. It’s a pity, since his article could help people understand XP better.

Making software is about finding out what to do and then doing it. XP is based on incrementally finding out what to do, based on feedback from things actually produced, acknowledging that both programmers and customers learn new things about the problem to be solved during the course of the project, and also that this learning is valuable. XP’s standpoint is that documents and diagrams doesn’t do anything for the customer, so what matters is the software produced, and if you can achieve good quality software without those diagrams, by doing other things instead, this would be a good thing.

Every process or methodology has a different way of finding out what to do and doing it, which is more or less suitable depending on the circumstances of the project. Finding out what to do is tricky, and it’s bound to involve lots of communication between people from the development team and the customers. Often you do a prototype for feedback purposes at some stage. XP does prototypes, but not as much for the customer as for the developers to learn about possible designs. Instead, XP strives to produce real, non-throwaway, software as soon as possible, also for feedback purposes.

Since XP is highly incremental, you have to have access to the customer during the course of the project. To me this is good, because the customer gets a solid feel for the progress, and there’s little room for misunderstandings between the parties, which would result in wrong things being built. But I have had my share of resistance from customers – particularly one time when where we were brought in to a crashed project, where there was a lousy requirements spec and the customer was really fed up with all the troubles and refused to discuss anything, since “all answers could be found in the spec”. In cases like these, it would be to pour gasoline on the fire to try to get the customer to be on-site.

But there are problems with getting the customer on-site. I’ve been in projects where I feel it was inevitable to have a project manager to mediate between the developers and the customer. The customer was definitely involved frequently, but more as a discussion partner than as an active participant in planning activities. But it’s a fact that the more you communicate with the customer, the greater the benefit for the project. But depending on the customer and the type of problem to be solved, the communication would have to be different.

There are also problems with the impression people get about XP: that you don’t do any design, that you just plunge ahead and hope to end up with something good. XP does lots of design: the planning game is a design activity, and so is test-driven development in pairs. And you need to regard the beginning of the project as an exploration period, where you establish a metaphor (which can be thought of as an informal overall architecture) from sketching a plan for the entire project and doing a number of architectural spikes (prototypes).