Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

XP Article

The Case Against Extreme Programming

By Matt Stephens
August 26, 2001
Updated January 26, 2003

Please note, this article is just one programmer's opinion: but it's an opinion that I truly believe to be correct. It's based on my own experience of software development, plus from talking to many people who have been involved in real XP projects, and from applying many of the Agile/XP practices to my own projects.

I would always encourage people to think for themselves. Do take a look at the various and disparate XP websites, e.g. and, and compare them with the criticism levelled here.



XP is a symbiotic process: that is, you really need to do all of XP or none at all. There’s no in-between (with the possible exception of unit tests). The theory is that each of its individually flawed practices reinforces each other to produce something stronger.

"Teams are drawn in by XP's 'low discipline' practices"

Unfortunately, as we will explore in this article, this can also work in the other direction - stop doing one practice and the chain unravels. In the real world it proves difficult to adhere to the XP practices for the duration of an entire project.

Agile proponent Alistair Cockburn describes XP as a "high discipline methodology". In a discussion on the Wiki web, he also suggested that most teams that say they're doing XP don't actually do all the practices.

As XP increases in popularity and hits the mainstream, more and more teams will attempt XP, probably without a clear understanding of what is really involved. They will most likely be drawn in by XP's "low discipline" practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).

In fact, I observed one XP project in which the management had warmed to XP because they saw the lack of an up-front design phase as a way of saving money. However, they refused to allow the team to perform any refactoring on the morass of badly formed code that emerged, because they felt that now the code was written, spending more time on it would be a waste of money.

"Not everyone out there is a process eXPert"

The programmers also finished-off each code module too quickly because they hated to pair program. The result was a monolithic city of heavily interwoven code with huge amounts of duplication, coupled with unit tests that took literally hours to run and left the database in an "unclean" state (i.e. needed to be picked apart manually after running the tests).

Of course, this project could not be described as "real" XP because they were not following all the practices. However, it's a good indication of what happens when XP hits the mainstream software development world.

Not everyone out there is an XP process expert. Not everyone has time to read all 20 XP books, scour the XP newsgroups for vital information not contained in the 20 books, and so on. Not every team will have access to an eXPert Coach (either full or part-time). In other words, the amount of hype that surrounds XP is not matched by the requisite skill-set needed to succesfully execute an XP project. I suspect that the result (as XP's promises entice more and more teams) will inevitably be confusion, and a dirty underbelly of (mostly unreported) failed attempts at XP.


>> Next: A Self-Referential Safety Net (Ring of Snakes)

Why not leave a message on the Software Reality XP Forum?

<< Back to XP Central

<< Back to Lifecycle



All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.