Matt Stephens & Doug Rosenberg:
Extreme Programming Refactored -- The Case Against XP
2003, Apress, ISBN 1-59059-096-1, 400 pages
reviewed by Conrad Weisert, November 2, 2003, ©Information Disciplines, Inc.
This is surely one of the most enjoyable books on programming methodology. The authors write in a friendly style with plenty of humor, while still conveying serious insights and advice. I found it hard to put the book down before finishing it.
Parodies of songs by the Beatles and others escaped me, since I was acquainted with very few of them. If you're a fan, you may be amused by them.
Despite the irreverent tone, the authors treat both the topic and their methodology adversaries with respect and fairness. Chapter 15 offers practical guidance on combining the best ideas from XP with common-sense good practice, a more balanced treatment than the recent Boehm & Turner book, which proclaims its balance. One could learn XP from this book.
An apt title
In case you've managed to avoid hearing about extreme programming (XP) I should explain that "refactoring" is the XP community's euphemism to describe what XP software developers do when they realize that they've made such a hopeless mess of their design that they need to throw it away and start over. The authors put it in their title in imitation of the deluge of Addison-Wesley titles such as Extreme Programming Explained, Extreme Programming Installed, and Extreme Progamming Applied. I'm surprised that any past participle was still available.
"Of course, they wouldn't have to spend all day refactoring if they had designed the thing properly in the first place."—p. 98
The book is loaded with references to web sites containing both pro and con material on XP. If you expect to be rereading this book five years from now, you might ask your secretary to print or download the content before the links expire. (Yes, I know that few development teams still have secretaries; assign this clerical task to anyone on your team who has juniority.)
Stephens and Rosenberg make a compelling case against the XP practice of not documenting users' requirements. Unfortunately, the authors1 then go on (Chapter 10) to advocate the discredited unstructured discrete list approach. The cure for no documentation is hardly bad documentation.
Very highly recommended
(I can't quite characterize this as a "must" for every programmer, since it's a book that shouldn't have had to be written.)
Return to book reviews.
Return to table of contents.
Last modified February 28, 2013