The Case Against Extreme Programming

By Matt Stephens
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. www.extremeprogramming.org and www.xprogramming.com, and compare them with the criticism levelled here.

Introduction

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.

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.

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