Pros: Detailed Examples, Acknowledges Open Questions
Cons: Open Questions and Metaphor as Architecture
Rating: 3 out of 5
I have split feelings about “Extreme Programming Explored.” The book provides a very detailed exploration of XP in some areas. In fact, in a lot of ways it’s the most balanced presentation of the process I’ve seen yet, as there’s a good discussion of some of the drawbacks and pitfalls with XP’s practices. However, some practices get lighter treatment. The sour note for me, though, was the treatment of design metaphors; I hadn’t really given them much thought before, but now I’m quite certain I don’t like them.
Chapter 2 has a fairly involved example of refactoring. There’s a lot of detail there, and it’s a good introduction to the subject. Pair programming also gets a thorough explanation. The book walks through a typical day in the life of two pair programmers, showing what they do and how they do it. These are pages well spent, as pair programming is one of the most difficult practices of XP to which to adjust. My favorite chapter is at the end of the book, describing the roles and responsibilities of the various participants in an XP project. This may be the first coherent description I’ve seen of what a coach actually does for a team (other than submitting timely invoices for large consulting fees). In these areas, there’s a lot of good material in the book.
Some areas of the book felt light weight, though. Perhaps it’s not so much that coverage of the topics was thin as that there were some interesting questions that didn’t get addressed. For example, when discussing the open office area preferred for an XP project, there’s no description of the impact on reaching a state of “flow,” which is described as a benefit of offices on the very same page. Chapter five’s description of spikes, short investigations of potential solutions, briefly addresses spikes that affect hardware choices, but there’s only a very weak discussion of how to minimize the risk of (or recover from) making the wrong choices. One of the fundamental tenets of XP is that the cost of change is not prohibitive, but that hypothesis was formed for software changes, not for changing out hardware. There are a few other examples as well, but the theme is the same. In a number of places I felt like this book should’ve been about twice it’s length so that more of the questions raised could’ve been discussed more thoroughly.
Lastly, there are a handful of points where I just disagree with the author (and/or XP). The biggest of them is metaphor. I really dislike the idea of metaphor as a means of architecture and design. How much does it really buy the team, and with what cost or risk? A shared vocabulary? Yes, but if the team doesn’t have enough domain knowledge to share a vocabulary about a subject, they’re in trouble with or without the metaphor. Architecture? Yes, the metaphor shapes the system, but so would a good… I dunno… architecture, or high-level design. The dictionary definition of metaphor quoted often in the book notes that a metaphor is a deliberate comparison of dissimilar things. Why pattern your system after an admittedly different domain? The last benefit can be a solid contribution: that the metaphor stretches one’s thinking and encourages brainstorming about possible system behaviors that would otherwise be ignored. However, the same benefit can be achieved by reasoning about the system using the metaphor, then throwing the metaphor away and keeping the design.
I’ll even argue that there’s some confusion in chapter 6 over what’s design and what’s metaphor. The author uses the example of text editors, pointing out a number of metaphors and models used over the years. The thing is, the examples are design models. It’s not just that emacs uses the metaphor of a long string of text for its editing buffer — it actually uses a long string of text. A sequence of similarly formatted runs of text isn’t a metaphor, it’s a design choice. I’m all for good thought being put into design, but it looks to me like good design work is being confused for metaphor here, perhaps in order to make the concept of a metaphor seem more useful. The book calls these “naive metaphors,” but really there’s no metaphor involved at all. Those things that are genuine metaphors, such as describing an accounting system as a manufacturing line, seemed to me to be more likely to cause confusion than prevent it.
“Aha!” the devotee of metaphors will say, “But what about the very famous and successful examples of metaphor you use every day? Why, your operating system’s ‘desktop’ is a metaphor, as is the ‘shopping cart’ you used to buy the book from Amazon.” Yes, those are metaphors. However, they are metaphors at the level of the user interface in order to make the software more understandable to the user. If you’re going to tell the user they have a file folder, it’s perfectly reasonable to design your software with objects like “Files” and “Folders.”
UI metaphors used to ease the transition of users from a familiar system should not be confused, though they often are, with the kind of purely internal design metaphor XP uses for architecture. If you can’t see the difference, go to a school teacher and explain that the school’s new report card system won’t accept test grades: it takes “movie reviews of students.” Do not expect to get two thumbs up.
As I said above, my opinion on this book is split right down the middle. In some ways, I prefer it to the rest of the XP books I’ve read. I certainly find it more forthright about the potential problems and pitfalls with applying the method. On the other hand, there’s plenty I disagree with and even more I wish was discussed in sufficient detail to meaningfully agree or disagree.
Leave a Reply