Extreme Programming Examined

This is the book to read after you understand enough XP to question its radicalism. Does it really make sense to abandon UML-style modeling? No, suggests OO guru Martin Fowler in an essay reconciling XP with heavyweight design. Is XP's Planning Game the ideal way to bring customers and IT management together? Maybe, but at Ford Motor Company it was "a total disaster." Nearly all of the essays in this uneven but illuminating text advance XP's cause, not through blunt evangelism, but by questioning the new process and building bridges to it from traditional practice. I happen to believe in class diagrams and other OO model artifacts. In contrast to other books in the Addison-Wesley XP Series, Examined shows that there plenty of smart, like-minded professionals out there striving to gain XP's benefits without jettisoning their tried-and-true belief systems. The sections "Methodology and Practice," "Flexible Techniques and UML" and "Practical Experiences," consisting of five essays each, were especially useful in this regard. I found other sections, notably the one on "Tools for XP Development," less distinctive. While XP's 'extremity' may be a selling point in some circles, in others it is sure to provoke the same kind of immune response as 'hacker'. If you feel itchy at the prospect of spike solutions and pair programming, "Extreme Programming Examined," with its collection of balanced voices seeking rapproachement, is the book for you.

Unlike the other books of Addison Wesley's The XP Series, this is a collection of 33 papers, presented at an XP conference held in 2000. As one might expect, not all 33 papers are of the highest quality, and some of them are of interest only to a few specialists.However, the book includes many outstanding contributions covering more advanced aspects of XP than the other books of the XP series. In my opinion, these are the chapters written by M. Fowler, P. Merel, D. Riehle, M. Collins-Cope, J. Eckstein, J. Kerievsky, A. Cockburn, T. Mackinnon, R. Johnson, T. Schummer, D. Wells, K. Boutin and A van Deursen (I quote only the first author). Many of them will become XP classics.Also the Parts on XP and UML, Testing, and Practical Experiences are full of useful ideas and hints.Overall, I found the book very helpful: it gave me all what expected, and more.

When I first read a book about Extreme Programming (XP) a little over a year ago, I was unimpressed. Part of this was due to what I viewed as the inaccuracy of the title, but most of my skepticism was based on scalability and personality conflicts. XP is a style of development where programmers are paired and the program is built by iterating the sequence: small change, construct test, perform test, debug. In projects that involve millions of lines of code, I could not see how this would work. Granted, it is possible for the team to test the actions of their code, but performing such iteration testing on a package where the work of several programming teams has been merged seemed to be too tall an order. The second and more fundamental difficulty I see is the act of pairing the programmers so that they can work together. In any set of developers, there will generally be a wide set of skills and personalities. Splitting that set into pairs that are matched so that they can effectively work together requires a wisdom that exceeds that of Solomon combined with a stick much bigger around than your thumb. As a veteran observer of the "style wars" at several companies, I have seen fierce arguments over where to put a curly brace, so the idea of paired teams of programmers working together all day every day seemed beyond expectations. However, as I continue to read more, my skepticism fades and I am slowly moving to a conversion, although I am not there yet. The articles in this book moved me a good deal closer to that level, as some of the papers address those very concerns. Several of them deal very specifically with the problem of using XP in very large projects, describing in detail how it can be used and where it is of dubious value. The other problem, that of personal differences, is also examined but the arguments are not as convincing. One paper in particular describes a situation where the programmers were initially skeptical but after being paired, spontaneously began working well together. While I certainly will accept that it is possible, my experience indicates otherwise. I need to see more evidence before I will be convinced that this is an obstacle that can easily be overcome. The basic principles of XP make a great deal of sense, although some of the arguments in favor have been known for many years. Evidence is put forward that pairing programmers causes an increase in productivity in both that is higher than if they worked separately. I have yet to meet a programmer who has not struggled for hours trying to find a bug only to show it to a colleague and have them find it in a matter of seconds. Sometimes, the action of simply talking about the problem is enough for our mental guards to be dropped long enough for the solution to appear. Despite having already read three books on XP, I learned a great deal from the papers in this one. XP holds a great deal of promise, but like all other development strategies, it has limitations.