"Extreme Programming Installed," by Ron Jeffries, Ann Anderson, and Chet Hendrickson

Pros: Interesting ideas; good writing; lively sense of humor
Cons: A few oversimplifications, redundancies, and appearances of pebble-snatching
Rating: 4 out of 5

“Extreme Programming Installed,” explains in detail how to implement XP. The explanation of XP practices is excellent; readers of the book should have little confusion over how to play their role in an XP project. However, Extreme Programming does have some dark corners, and it was disappointing to see them glossed over rather than dragged into the light. The book is entertaining, easy to read, and mostly well organized. Overall, I would recommend it to someone looking for a guide to practicing XP.

The Important Stuff

The book explains how to conduct an XP project. Requirements are written on story cards, and a proxy method is used to estimate development effort. Developers estimate effort to implement a story based on similar previous stories. Developers write tests first, then code that makes the tests pass. All this work is scheduled in short iterations and small releases, providing quick feedback to alter the course of the project as needed. These practices and the others that make up XP are clearly described in the book. Bottom line up front: the book serves its purpose. Keep that in mind as I complain for a while.

Limitations and Missed Opportunities

Every development process has limitations, including Extreme Programming. I had hoped to see those difficult scenarios tackled head on. I was disappointed. Some of the hard problems were raised, but they were glossed over.

For example, the advice for deploying XP on an existing project is to adopt the practices one at a time to address the team’s most pressing needs. Many of XP’s practices are mutually reinforcing. A detractor of XP once described it as a ring of poisonous snakes biting each others’ tails. All is well as long as all the practices are in place. When just one snake lets go, the project is in danger. There was an opportunity here for helpful guidance of the form: by the time you start using collective code ownership, you really ought to have pair programming in place. Or, if your current process uses code reviews, try not to give those up until you’re ready to put pair programming in place. If these aren’t concerns, why not?

Neither did the book address application of XP to a firm fixed price contract. Typically, this kind of contract fixes the work to be done, the cost, and the schedule up front, depriving XP of necessary degrees of freedom. Does that mean XP isn’t suitable on an FFP contract? If it can be used, what are good approaches?

What about the situation where the developers of code aren’t the maintainers? XP seems to rely on the idea that the same team responsible for developing software will be responsible for its maintenance. Producing clear, readable code that expresses every necessary idea helps, but I’ve seen the effects of handing a development group a code base that they haven’t seen before. XP eschews the specification, design, and traceability documentation that helps make sense of the code. I’m skeptical XP adequately prepares a project to be thrown over the fence to a separate maintenance group.

The chapter advocating small releases features several examples intended to show that systems can be broken into small releases. Every example deals with a legacy system. The solution is always to interoperate with the legacy system and gradually deploy new functionality. What about a system that appears to be “all or nothing” that has no legacy parts, such as a complicated analytical calculation, like radar track processing? Or for a more familiar example, what about a compiler? Should that be broken up to parse but not translate to machine code? That doesn’t sound like a complete story. Should it completely compile, but only one or a few instructions from the language’s instruction set? I think there are good answers to keep the releases small in these cases, but I would’ve liked to have seen them in the book rather than four examples with the same answer.

Possibly Exaggerated Benefits

The book also exaggerated the benefits of particular XP practices in places. For example, the authors contrast written requirements specifications with asking questions of an on-site customer. The aim is to show that face to face conversations resolve questions far faster than email traffic, telephone calls, or detailed specifications. Perhaps it was the example used, but writing the correct software behavior into a good specification would’ve been faster and easier than the conversation shown in the book. Moreover, a later passage in a section titled “Stories are Promises for Conversation,” notes that conversations will be captured as additional documentation. How much time and effort is really saved? Is it faster to write up information to document the conversation or have the conversation to clarify the specification?

Later in the book, in a section on simple design, the authors make the claim that code being in one place only makes it easy to change. This overstates the benefit of not duplicating code. Duplication of code certainly makes changes harder, but even without duplication, code may be difficult to change. For example, the existing code might be complex, the code might rely on a buggy COTS API, or the change might add difficult to understand functionality. Sometimes programming is hard simply because the problem to be solved is hard.

How do the benefits of user stories extend to error handling, particularly errors arising from infrastructure? The book advocates only developing as much infrastructure as is necessary to fulfill user stories. Undoubtedly, there is benefit to keeping designs simple. However, no mention is made of how to handle extra errors that the infrastructure introduces. Suppose a user story involves displaying a ticketing reservation. The user doesn’t care that the information has to be fetched from a database. How should one get stories for error handling when the database is down?

Nuts and Bolts; Writing and Organization

The writing is quite good, keeping a lively pace and a good sense of humor. However, the next technical book I read that describes someone snatching a pebble from someone else’s hand is going to get folded, spindled, and mutilated. Folks, take a deep breath. We write software. We are not zen philosophers. We are not buddhist monks. We are not martial artists. We do not have magical powers. We write software. (Unless, of course, in your off hours, you’re a zen buddhist monk with skill in martial arts and magical powers, in which case you can ignore this.) I know everyone wants to feel special, like they’re part of a several thousand year tradition, capable of physical and mental feats at the limits of human capacity, or even like they wield magic. You’re all beautiful individuals, just like the snowflakes that the wiper blades obliterate from my windshield. But you don’t have magical powers. You do have a discipline for writing software. Believe me, that’s enough of an accomplishment that you don’t need to dress it up any farther.

In the good column, both XP and the book have a good sense of psychology. There’s a subtle emphasis on frequent positive reinforcement. For every software delivery, there’s a small ceremony or party that shows the team how far they’ve come. For every completed story, there’s a short victory dance to acknowledge the success. (Note: parties and victory dances are okay – no mystical powers or hands with pebbles here.) As an aside, I once saw an article written for video game designers on the use of rewards and accomplishments in game design. The way rewards are paced during game play has a strong impact on the addictive quality of the game. People respond best when they have frequent small rewards for little successes and then larger, more meaningful rewards less frequently. For example, think of a fantasy game where new armor and magical items are acquired fairly often, alongside more spectacular but less frequent advances in innate character skill and ability. It’s not surprising the same basic psychology works for developers. Seeing the test bar run green at the end of each task or story gives frequent reinforcement that progress is being made. Iterations and releases give less frequent but more powerful reinforcement of success. There’s good insight here for any team, whether using XP or not.

The organization of the book is fairly good. The sections have descriptive names, which makes the book more navigable as a reference than many I’ve read. For example, “Customer Defines Release,” provides a much more intuitive prompt about the contents of a chapter than “Release Process.”

Some of the material on planning, story cards, and steering projects is repeated a little too often. This is particularly true in the “Bonus Tracks” at the end of the book. Although some of the bonus material useful, I’m not fond of this section as a whole. Many of the ideas have already been explained in detail earlier in the book. Of those that weren’t, if the ideas there are important enough to include, then digest them down, work them into the organizational framework of the manuscript, and write them into the book. That’s what your loyal readers are paying for. Don’t just tack them onto the back of the book as a collection of papers, testimonials, and observations. Perhaps this section bothers me so much because if the relevant ideas were distilled from the bonus tracks and worked into the book, enough space might have been freed up to some of the things that seemed to be missing.

The Settled Dust

I do think well of this book and recommend it. For a second edition, I’d definitely make some changes, primarily eliminating some duplication and expanding coverage of some of the topics. However, the goal of the book is to explain how to work on an XP project, and I believe that goal is accomplished.