Ron Jeffries - Extreme Programming Installed

There are three things I like about this book (well, lots more than three, but I only have a foreword's worth of words to work with).

One: It's concrete. Extreme Programming Explained is a manifesto, a call to arms. "Hey gang, over there might not be so bad." The problem with manifestos, as history shows, is that execution of them is often fraught with difficulties (or outright impossibilities) that are not obvious from ten thousand meters away.

Extreme Programming Installed is all about really doing itprogramming extreme. Here you will find a hundred little techniques for making the high-minded ideals of XP real and practical. And they are concrete, so you'll know from the first minute whether you are doing them or not.

Two: It's from experience. I had the great good fortune to work with Ron and Chet (and to a lesser extent with Ann) for an intense, frightening, challenging year at Chrysler. I learned a tremendous amount from them as we battled to figure out the details of delivering high-quality, high-value software. We had technical problems. We had people problems. We had management problems (and to be fair though, a whole lot of support). Our first year together was a microcosm of what can go wrong on a project. Software Engineering Reality 101.

Out of those experiences came a fountain of solutions. Funny, you put a team together and get most of the artificial obstacles out of their way, and you'll get good thoughts along the way to success. Since the C3 project at Chrysler, each of the authors has gone on to run extreme projects elsewhere. What you get in this book isn't a narrowly effective slice of practices, but rather the best of what worked for us there and elsewhere. When any technique in our field generates lots of press, charlatans and coat-tailers are bound to be close behind. We've already seen the fruits of the first consultants following the letter of XP but completely missing its spirit. XP Installed comes from folks who've done it, understood it, and expanded it.

Three: My friends wrote it. Don't get me wrong. I like writing books (witness Planning Extreme Programming, which I just finished writing with Martin Fowler). But I don't want to write them all. It would be the death of XP if I did write them all.

One of the failure scenarios for XP is if it turns into a cult of personality. "Sure this works for Kent, but thank goodness there's only one of him" is a charge leveled against XP by those who are afraid to try something different. XP Installed demonstrates that others can do XP, others can understand XP, and others can communicate about XP.

So, thanks, Ron and Chet and Ann, for writing this book. And reader, thanks for taking the time to read it and apply its principles. This book won't make your project for you. Only you can do that. But applying the lessons in these pages will make your project better.

Kent Beck

Merlin, Oregon

We've now covered most of the programming aspects of XP. Here's a summary of things we doand things we don't do.

Extreme Programming is about doing. For each key aspect of software development, XP prescribes a few simple practices aimed at helping you know when you are done and know when you are right.

But XP is also about not doing. Over the years, software development methodology has become encrusted with practices that, for most projects, do not advance the actual effort of producing the product that is wanted: the software.

The result of an XP project should be a computer program. Not just any computer program, but a well-crafted, flexibly structured, properly documented computer program, shown by testing to meet known and documented requirements.

Remember that if you're doing XP right, at the end of the project you will have a computer program that is

• well designed

• well crafted

• flexibly structured

• properly documented

• tested

• meeting known and documented requirements

Some of the things that we advise against doing are a bit controversial. As you review the simple XP processes, we're sure you'll that the other things aren't always necessary after all. Use your own best judgment.

Here are some recommendations:

• Don't try to design the whole system before you start implementing it. Usually requirements changes alone will make this impossible. In any case, no existing design methodology is effective enough to prevent problems during implementation, and a process of design a little, build a little will allow you to learn faster and get a quality system done sooner.

• Do design all the time. Begin simply, and as you learn what the design should be, refactor to make it so. Never stop designing, never stop making the code agree with what the design should be.

• Don't try to freeze requirements before you start implementing. Requirements changes show that the customer is learning! Sure, it would be nice if they knew just what they wanted before you started building things, but the fact is that when they what you're building, they'll learn what they meant. XP lets you use a development and planning approach that allows for change, without a big up-front investment in frameworks or flexibility.

• Do get comfortable with taking on any story in any order. Sure, sometimes order makes a difference, but more often than we programmers think, it doesn't. Just tell the customers the cost of every story, and let them choose.

• Don't produce voluminous design documents at the beginning. Don't even produce them in the middle: produce them at the end, when you actually know something. Extreme Programming teaches you how to keep the design flexible, for rapid change and fastest implementation. The design documents you produce at the beginning will go out of date very quickly (they always do, even on non-Extreme projects), and you'll either waste time updating the docs or let them get out-of-date. Either is bad.

• Do focus on communication. A few diagrams can help. A big picture on the wall can help. More important, however, are clear code and talking, talking, talking.

• Don't produce documents or other artifacts that aren't being used. If you couldn't resist writing up the design or drawing some UML, notice whether anyone is really using the documents. If they aren't, stop producing them. For extra credit, erase the ones you have already createdthey're out of date anyway, aren't they?

• Do pay attention to your metrics and your key reporting graphs. The project's progress needs to be published frequently. Most of the design probably does not.

• Don't separate the team into designers and coders. Let everyone reach their own level in design and coding.

• Do let everyone get involved in design. Do group design, using CRC, for everything important. This will let everyone learn and participate. And let's face it, the most junior person on the team is as likely as anyone to spot a design flaw.

• Don't build for tomorrow. When you hear yourself elaborating or generalizing a design, stop. Implement the simplest design that could possibly work to do what you have to do right now. When you say, "We're gonna need," you're wasting precious time, and you're usurping the customer's right to set priorities.

• Don't build for tomorrow. When you read the preceding paragraph, you may have said, "But it'll be harder to put it in later." That turns out to be incorrect almost every time. If you leave the code simple and true today, improving it tomorrow will be easy. And you'll be smarter tomorrow: you'll know more about what is really needed, and you'll know more about how to do things.