Search in Book Reviews

Maybe you like big books with long chapters composed of long paragraphs made up of long sentences littered with long words, I do not. One curious characteristic of all the books I have read on XP is that they are almost all short books (under 250 pages, composed of short chapters made up of short paragraphs (well not too short) composed of short sentences (well not always) with few longwords. Well actually that last bit is not true, I suspect the average word length is larger than average, but it feels that way.

Why is this? Is it some characteristic of XP that attracts people who know how to write readable books? Or does the XP discipline spill over into writing. I suspect that it is a bit of both but with more of the latter than the former.

In this book three authors (I bet they practiced pair writing) present XP with a liberal dose of personal experience. There aren't many war stories but there is a wealth of experience freely shared with the reader.

One of the problems with XP is that there is an awful lot of religious resistance to it, coupled with an awful lot of proselytising by the enthusiasts. One side simply looks at it and declares that that could not possibly work, not least because human nature will get in the way (e.g. concepts of team responsibility, and not claiming personal glory seem to require participants to behave unnaturally). The other side tries to persuade us that XP will solve all programming problems.

In reality there is a good deal of selfishness around these days (probably always has been, but it feels like there is much more now than there used to be) and XP is certainly not for the glory hunter, it is for the person who understands the reward of quiet satisfaction with a job well done. But on the other side there are certainly programming tasks that are not suited to XP's short delivery cycle and incremental releases. Of course you can force it onto unsuitable projects and then blame the resulting failure on a lack of commitment by those involved.

By now you are beginning to wonder why I am not writing about the book under review. Well that is because I find it very difficult to summarise books such as this one. I cannot write about its technical accuracy, I cannot tell you how beneficial or damaging reading it will be to you. Let me give you an example.

Chapter 12 is five pages long. It starts on an odd numbered page, as does every chapter as well as the frequent inter-chapter side-bars. The first page (in common with every other chapter) consists of a heading giving the chapter number, a title (Pair Programming) a short explanation (On an Extreme Programming team, two programmers sitting together at the same machine write all production code.) and a black and white sketch (two pears buddying up to each other)

The meet of the chapter is about pair programming, how to get started, and how to overcome the initial reluctance some have with this method of working.

Not quite four pages topped off with a two line summary:

Two programmers working together are more effective than two working alone. Team knowledge grows faster and the work is more fun.

The sample chapter was one of the longer ones. I think that reading this book may improve your programming/software development process even if you do not practice XP because much of XP is simply taking good things and doing more of them. Just go to your local bookshop and read chapter 17 (Experience Improves Estimates). It will only take a couple of minutes. Now consider buying the book. And please think about how useful it was to be able to browse the book before buying, and reward the shop that made this possible.

Whether you are a devotee of XP, a newcomer, a curious outsider or certain that it is a load of rubbish, I think reading this book will be both a pleasure and instructive.