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:




The Case Against Extreme Programming

XP From the Trenches

By Rich Camden
15 December, 2002

The opinions I share with you are not those of someone who has simply read some of the XP books and disliked the content, but rather someone who has read the books, practiced XP for over 7 months, and participated in XP users groups.

It is also worth noting, that I am not someone who came into this work with a negative opinion of XP and an attitude set to prove my opinion correct. Rather, quite the opposite case is true. Although I had never practiced XP prior to joining my current company, I came on board enthusiastically and excited that I would get an opportunity to use XP on a real project. I had read one of the books prior to joining the company. So it is directly through experience with the XP methodology that my negative opinions of it were formed.

XP is a methodology created by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. Their main tenets are all very programmer-centric and often fail to consider the larger scope of a software development project. They typically spend little time considering design and analysis issues at a project scope level.


Here are some comments on some of the main tenets of the XP methodology:

On-Site Customer
This is a utopian dream. Sure, every development project would love to have a customer full-time at their location participating with the development team, but in the vast majority of projects, this is simply unrealistic. Thus this ends up being a tenet that is quoted to make XP look good but is seldom practiced.

Pair Programming
This is the worst of the XP tenets. To recommend pair programming across the board for all developers involved in XP is to not understand the people/personality side of programming. Yes, there are those who will benefit from having another programmer constantly sitting over their shoulder assisting and reviewing their work. But, there are many more who will feel uncomfortable and restrained with another programmer watching everything they do. Unfortunately, this tenet above all others tends to dampen creativity and heroics in XP. Many of the best programming gems come after absorbing oneself in a problem, and much deep thinking. This does not occur when you have another programmer looking over your shoulder.

Unit Testing
This is a tenet that I do support completely. I believe that thorough unit testing increases the quality of any software project. XP programmers truly are good at religiously writing unit tests. This should be transitioned to non-XP projects as well.

Continuous Integration
I have few problems with this tenet. I do believe that integration should be done in small steps as opposed to only at the end of a software project, which is the heart of this tenet.

Do The Simplest Thing That Could Possibly Work
The biggest problem with this statement is that it does not stand up well on its own. Sure, if defined properly this could be a good thing, but I have seen XP shops paste this "motto" on their walls and disassociate it from a deeper explanation. Taken alone, this statement leads to poorly designed, difficult to maintain, and low quality software. Following a good design is often not the simplest thing to do at the time, but strategically it is quite often the superior thing to do. This tenet seems to be borne out of programmers who are adverse to strategic design, analysis, and modeling and simply want to code.

40 Hour Work Week
This is an admirable goal that I support. Unfortunately, I believe this becomes too engrained also in XP programmers' heads, and even on projects in danger they do not feel the motivation to put in extra work hours.

 

A big problem that I see with XP projects is that they tend to be very code-centric. Because of the lack of focus on design and analysis in XP projects, all decisions made related to the development are very code-centric and often neglect to take into account a larger project scope. What you end up with is code that may look very good under a microscope, but the further you step away from the code modules, the bigger the mess you have. You end up with poorly documented and poorly designed applications.

Documentation on XP projects is poor. XP advocates that the software documentation be the code itself. They say that the code along with its tests should be sufficient documentation for any code module. Well, the reality of this is that yes, the code plus its tests provides the equivalent of very detailed documentation for how the module works. What is missing is the bridge to that level of understanding though. Someone coming onto an XP project that relies upon code to document their modules is in for a very difficult time in trying to grasp the structure of the code and its higher level functionality.

XP also does not believe in the need for "experts". Their philosophy is that all programmers should be well balanced on all technologies employed by the application. Again, while this sounds admirable as a goal, the reality of this is that you kill the enthusiasm of an expert, and encourage a mediocre understand of all technologies in all your programmers. It is simply not realistic for all programmers to become experts in all of a project's technologies. Individuals who want to gain expertise in a specific technology, such as security, GUI design, databases, etc. are discouraged.

XP's popularity is growing not because it is converting followers of other software methodologies, but because it is attracting all the programmers who previously adhered to no formal methodology and now proudly tout that they adhere to XP methodology. I believe this is essentially a "way out" for them. They get to claim a methodology while adjusting their programming style very little.

Finally, XP has not been around long enough for many of those projects to have reached maintenance phases. This is where I believe many of the flaws in XP will become apparent.

I have become convinced that XP is not a methodology that benefits customers in the long run.


About the Author:
Rich Camden is not the author's real name. He has used this pseudonym because he is currently working on an XP project, and does not want to jeopardize his position there.


>> XP From The Trenches 2: Vanilla XP

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

Also check out the feedback to this and our other XP articles.

<< 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.