The Case Against Extreme Programming
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.
August 26, 2001
Updated January 26, 2003
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.
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
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.
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
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