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. If you are considering adopting it in your shop or are simply interested in what it is, then this book will help show you the way.
