Book review: “Extreme Programming explained” by Kent Beck
June 8th, 2004 at 5:50 pmI 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 adresses
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.
Related posts: