Extreme Programming in Practice: The Voice of eXPerience

Well, we ve given you a quick overview of the theory underlying XP and we ve tried not to interject too much commentary thus far. But, as you might have guessed from the title of the book, we ve got some pretty good reasons to believe that XP in practice is often radically different from XP in theory. Scattered throughout the book you ll see sidebars containing descriptions of real XP project experiences. Some of the people who submitted these descriptions have asked to be kept anonymous, for fear of incurring the wrath of their employers or XP teammates.

The concerns of the people who wished to remain anonymous aren t entirely unreasonable, as we ll discover in Chapter 4.

 

As we discuss later, XP s idealistic practices tend not to gel particularly well with real-world project conditions. The result is often a bastardized adaptation of XP, in which the process becomes warped into something altogether scarier. This experience shows through in pretty much all of these descriptions.

One thing to note about the Voice of eXPerience (VoXP) contributions you ll read in this book: When we started the book, we had no plans for any of them. As word began to spread that we were writing the book, people started sending us their contributions. To the occasional consternation of our publisher, we adjusted our schedule and increased the length of the book by about 25 pages to make room for these firsthand accounts because we feel they re tremendously important.

To kick off, the description in the XP from the Trenches sidebar comes from an XPer who has asked to use a pseudonym. Note that not everything described here is pure XP ”but that in itself gives a good indication of what really happens when XP hits the mainstream.

VoXP
XP from the Trenches

by Rich Camden

The opinions I share with you aren t those of someone who has simply read some of the XP books and disliked their content; rather, they re the opinions of someone who has read the books, practiced XP for over 7 months, and participated in XP user groups.

It s also worth noting that I m not someone who came into this work with a negative opinion of XP and an attitude set to prove my opinion correct ”quite the opposite 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 XP book prior to joining the company. It s 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. XP s main tenets are all very programmer-centric and often fail to consider the larger scope of a software development project. XP programmers typically spend little time considering design and analysis issues at a project scope level.

Here are some of my opinions on a number 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 it s 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 next to them, 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 doesn t occur when you have another programmer sitting next to you, trying to take control of the keyboard.

• 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 (DTSTTCPW): The biggest problem with this statement is that it doesn t 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, low-quality software. Following a good design is often not the simplest thing to do at the time, but strategically it s quite often the superior thing to do. This tenet seems to be borne out of programmers who are averse to strategic design, analysis, and modeling and simply want to code.

• 40- hour week: This is an admirable goal that I support. Unfortunately, I believe this becomes too engrained in XP programmers heads, and even on projects in danger they don t 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 codecentric. 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 provide the equivalent of very detailed documentation for how the module works. What s missing is the bridge to that level of understanding, though. Someone coming onto an XP project that relies upon code to document its modules is in for a very difficult time in trying to grasp the structure of the code and its higher-level functionality.

  XP s philosophy is that all programmers should be well balanced on all technologies employed by the application. Again, although this sounds admirable as a goal, the reality of this is that you kill the enthusiasm of an expert and encourage amediocre understanding of all technologies in all your programmers. It s 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, and so on, are discouraged.

  XP s popularity is growing not because it s converting followers of other software methodologies, but because it s 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 hasn t 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 ve become convinced that XP isn t a methodology that benefits customers in the long run.