Book review: "Extreme Programming explained" by Kent Beck

I got familiar with the whole topic of eXtreme Programming a couple of years ago. You know, it's one of the hot topics now, and one tends to hear about hot topics. I've never really read anything "formal" on it, so I got curious when I god my hands on this book. It's written by one of the fathers (if not *the* father) of XP, so this is first-source information. What follows is my views on a few selected topics of XP, the way they are presented in this book:

Small releases - When you write code, getting feedback is very important. This feedback can come on several levels. On the lowest level, you check that any piece of code you write compiles and works correctly. On the highest level, you want to get feedback from the customer to be sure that as a whole the system is functioning correctly. XP encourages "small releases" in order to receive such feedback as often as possible. It's a good idea, since feedback adds to confidence, and condifence adds to productivity (similarly to testing). It's not very simple to implement "Small releases" though. The customer is not always delighted to cease all work, re-install a newer release and combat its problems, so it doesn't always work.
Testing - I can't say enough good things about the habit to test a lot. It's a blessing, it makes programming much easier. I just wish that every piece of software was easy to test. How do you test graphical components, UIs, etc ? How do you test reports when their format changes often ? But wherever possible, testing should be embraced. I'm not sure one must write tests first, IMHO if one's disciplined enough, tests can be written after the code as well.
Refactoring - I wrote a whole review about *the* Refactoring book (Fowler's), just just a quick one: Without a testing suite, refactoring is extremely dangerous. Paired with a good, thorough testing suite, refactoring is terrific.
40-Hour week. I'm a big believer in Parkinson's Law (work expands into the time limits assigned to it), so 40-hour weeks sound good. We should always take work not too hard... there are many *truly* important things in life, long work hours is not one of them. Naturally, spurts of overtime are sometimes necessary, so Beck puts it very accurately: a little overtime here and there is OK, but if your team is working overtime the second week in a row, it smells like trouble.
Pair programming - It's funny to note that I've experienced pair programming long before XP came to the headlines. Circa 1998, when I just learned to program (in C), a friend of mine (who also just learned to program...) and I got to write a text soccer simulation program. It's a few KLOCs, and we wrote it together - *real* pair programming. Sometimes I'm "at the wheel" an he's sitting by my side, throwing ideas and correcting small errors on the fly, sometimes he's "at the wheel", etc. It was really nice, and I think it proved itself, since it really had very few defects, and those were simple. Back to the book though...
I think that the image Beck presents in the book is an over-simplified perfection. I find it hard to believe that in a 1 million LOC project every programmer will know every part of the code because of pair programming - this is just too much code/complexity to keep in the brain. This is another point that questions the validity of all-pair-programming on very large projects. To Beck's defense, in chapter 25 he raises the point that XP doesn't work well with big teams. But small projects are simple anyway, people ARE looking for solutions for big teams/projects. On the other hand, one may argue that many of the best software projects we now use were developed by a small team of very skilled programmers. This is not the point though. Big projects often involve a large number of mostly mediocre programmers, and the "silver bullet" everyone is looking for is some way to make these big teams work to deliver good results.

In general, the book is written well and is quite easy to read. I felt that it slows down towards the end though. In many places, it seems that the author refers specifically to the XP team he took part in, rather than some arbitrary XP team in some arbitrary company. Especially in chapter 22, "Big boss" paragraph, which reads a little like an open letter to his boss trying to explain the team's attitude and performance during the project. Chapter 24, "Why XP is hard" is really "in place" though. It addresses some of the problems I raised above, and generally tries to answer some of the difficulties teams may encounter when starting to use XP (or converting an existing project to XP). To conclude, if you're interested in XP look it up the net, there are tons of information out there. If one of your friends has this book and you've got a few free evenings to kill, it's not bad. I wouldn't *buy* it specifically, however... for one who already knows a little about XP it won't bear much new information.