Every year or so, I get an urge to read some computer programming books and see if I can jolt myself out my current set of habits. Extreme Programming (XP) has been a big buzzword over the last few years. I had some vague ideas about what XP was (pair programming, writing tests first), but I never really gave it much thought.

The environment that I program in does not lend itself to software development practices involving lots of detailed planning. I work alone or in a small group, with ever-changing program requirements, and my deliverables are working prototype code and high-level documentation. So, the "embrace change" part of this book's title got my attention. However, this treatise on XP is not going to help me much. I'm convinced of the necessity of automated unit and functional testing, and I know that I need an approach that can react well to changing requirements, but I'm not convinced by the author's arguments in favor of XP as a solution. I'm also not that impressed with his facile writing style.