Well, I finally fell victim to the Extreme Programming (XP) buzz. I’ve been reading articles about XP for about a year, so when offered the chance to review the book A Practical Guide to eXtreme Programming, I couldn’t resist.

XP in action
One of the best qualities of this book is that it provides useful information for both the development manager and the software engineer in the trenches. It’s very readable (I actually read it cover to cover) and offers an easy-to-follow explanation of XP and how to make it work for your organization.

The authors identify and define all the necessary roles, such as Storytellers, Big Boss, and Acceptors. Then, they lay out the steps to implement XP, starting with the Vision and finishing with the Delivery. The appendix presents a complete project—a software system built for an electrical contractor to manage invoices and quotes—that was solved using the XP methodology. All deliverables from this project, including the Java source code, are provided as a case study.



A Practical Guide to eXtreme Programming

By David Astels, Granville Miller, Miroslav Novak
Prentice Hall PTR
February 2002
347 pages
ISBN: 0-13-0674826
Cover price: $29.99

XP in 27 pages
The first 27 pages of this book provide you with a fairly solid understanding of XP. That’s right, you heard me. All the terminology you need to intelligently talk about XP at your next high-tech networking social is presented in these few pages. So find this book at your local bookstore and loiter amongst the bookshelves while you read the first two chapters. Then you can decide if you want to take the plunge.

Your rights in XP
Lightly sprinkled throughout the book are the rights of each team (customer and developer). These rights touch on many of the major philosophies involved in the XP development process. I only wish the book had compiled them in one location, since it would really give the reader a sense of XP’s beliefs. For instance:

  • Customer Conceptualization Right #1: You have the right not to have to conceptualize the entire system up front.
  • Customer Delivery Right #3: You are always right if there is a problem with the use of the system; the system is the problem, not the user.
  • Programmer Development Right #2: You have the right to ask for and receive help from peers, superiors, and customers.

Some of the rights are original and others are from outside sources listed in the bibliography, which provides a large and wonderful list of additional XP resources.

Find a buddy and grab a keyboard

Have you ever sat down with someone and let one person drive while you both program? If you have, you’ve participated in one major part of the XP development process: pair programming. If you haven’t, you don’t know what you’re missing. I was able to participate in a development project where I experienced pair programming (way before it was known as pair programming) and found it to be an enjoyable experience. You feed off each other’s energy and produce a design along with code that has already been peer-reviewed. In my opinion, the end product will always have a stronger design and more stable code.

Development section chock-full of goodies
Without a doubt, the chapters devoted to the development aspects of XP were my favorites. This section breaks out the major themes behind XP development and presents hands-on examples, walking you through each topic. For instance, the section on refactoring, the art of rewriting code and not affecting external users, actually takes you through the exercise of rewriting some Java code. You can see the before and after views of the code, which illustrate what authors were thinking, why they made their choices, and how to “smell.”

The writers cover XP-flavored design extensively in this section too. Although no hands-on examples are given here (it’s sort of hard to walk you through a design in a few pages), you get a healthy dose of XP design philosophy. All of it is easy to understand and explained in detail.

This section also discusses Agile Modeling (AM), a new movement within XP. In short, AM provides a commonsense approach (values, principals, and practices) when modeling for a software development project. For instance, Working Software vs. Comprehensive Documentation is a characteristic of AM that refers to the fact that the end goal of software development is a working piece of software that does what the user wants. It’s not a piece of documentation for a model of a software system that’s really only a snapshot of the design. Design snapshots eventually become outdated and of little value. These documents are seldom used after being written, so AM suggests letting the code become the model. Many of you might frown at this, but I would have to agree that the document becomes outdated after the next developer comes through and adds a feature.

These are just a few of the topics covered in this section of the book. You’ve probably already been using many of the ideas presented there, but others will be new and make you go “hmm.” What I like most about the book is it leaves you with new ideas to try in your development world regardless of what you might do with XP.

A few of my favorite things
Despite some editorial glitches in the book (if I’m spotting typos, you’re in trouble), I found A Practical Guide to eXtreme Programming to be quite readable. It’s a how-to resource that takes you through the steps needed to pull off your first XP-based project. If you don’t think you can convince upper management to go fully XP, you can at least pick up a few best practices that might turn your next project into a big success. I recommend adding this book to your personal library.

Want to review a book?

Do you have a favorite book? Contact the editors about submitting a review or post a comment below.