Questioning Extreme Programming

Questioning Extreme Programming (ISBN 0-201-84457-5) is part of Kent Beck's XP Series. Pete McBreen is the author of Software Craftsmanship : The New Imperative which was also published by Addison-Wesley.

This book is somewhat dated now in that is addresses many of the questions related to adopting XP, comparing and contrasting XP to some of the alternatives to XP. Unfortunately not all of the alternatives are that common any more, eight years has been a long time in the software methodology world.

Foreword by Kent Beck

Pete and I go way back. I can't remember exactly when we met, but I do remember being impressed with his experience and ability to communicate. When I heard that Pete was writing a book that takes a critical look at XP, I was glad — another set of eyes, particularly those of a thoughtful and self-professed outsider, could only help all of us as we try to improve our own development cultures.

Pete pulled it off. Some of XP's critics fall into shrill, reactionary jeremiads: "It'll never work. You have to design my way, or you'll die. Listen to me. I know how to yell." This book is thorough, thoughtful, and conservative. Pete only makes claims he can back up with experience.

This is not to say I agree with his conclusions. I absolutely do not. XP started out with a fairly limited audience in mind — small teams working on business software. Adventurous pioneers, to use Ken Auer's picturesque metaphor, have carried XP far from its roots:

• Atomic teams as large as 50 (customer side and development side together)
• Teams of teams, often distributed worldwide
• Embedded systems
• Product development — in which the customer side has to represent a wide range of interests

Pete claims that the more he looks at XP, the smaller he sees its scope. I see just the opposite. I won't refute his argument point by point — this is a foreword and I'm supposed to be polite. I will suggest that as you read this, you keep in mind one mistake of early XP thinking for which I am entirely responsible — "the customer" doesn't mean one person. It means a team, as big as or bigger than the development team.

I trust you will make your own conclusions about the contents of the book. If you agree with Pete's conclusion, you will find here evidence and reasoning aplenty. If you disagree with Pete's conclusion, you will find tough questions that will force you to reexamine your own experience and conclusions. If you don't have an opinion about XP, you will find here a program for coming to your own conclusions. That's why I'm delighted to welcome this book to The XP Series. It's a "make-you-think" book, and XP is supposed to be a "make-you-think" development culture.

Kent Beck
Three Rivers Institute

From the Preface

Extreme Programming sounds great - can we do it without changing our process?

...

This book sets out to question Extreme Programming in an attempt to understand and explain the controversy that surrounds Extreme Programming. My goal for this book is to allow you, the reader, to determine if Extreme Programming is applicable and appropriate for your projects, to investigate what lessons can be learned from Extreme Programming and to enable you to be more reflective about your software development practices.

...

As much as is possible I have tried to present both sides of the debate surrounding Extreme Programming without getting into the continual flame-fest that discussions on usenet newsgroups and email lists often contain.

I have written this book as a practical guide for four different audiences:

• people who are thinking of adopting Extreme Programming
• people who are resisting the idea of adopting Extreme Programming,
• people who are looking for alternatives to Extreme Programming
• people who are interested in improving their current software development process

As a practical guide this book is focused on identifying issues surrounding software development and discussing how Extreme Programming interacts with these issues. As this is a practical guide, you will not find much in the way of detailed studies and experimental data. This book focuses on clarifying the issues so that you, the reader, can determine the fit between Extreme Programming and your specific circumstances.

From the Epilogue

"I come to bury Caesar, not to praise him." William Shakespeare, 1599. "Julius Caesar. Act 3 Scene 2"

This has been a very interesting book to write. When I first heard about Extreme Programming I was very excited because I actually enjoy programming. Over time my questioning of Extreme Programming has lead me on a journey that is practically the opposite of Anthony’s eulogy for Julius Caesar as told by Shakespeare.

At the end of Anthony’s eulogy, the mob is on Caesar’s side and are lusting for revenge on the conspirators who killed Julius Caesar. In my case I started off very enthusiastic and over time became much less so because of the very narrow applicability of Extreme Programming. Sure XP teams have managed to do great things, but suitable projects are few and far between. I have yet to work on project that was really suitable for XP and I suspect that few other developers have.

Some Interesting Ideas to play with before you read this book

• All processes are situational. Software development is not a mechanical process and as such you will never be able to adopt a process without doing some adapting to fit with your circumstances and team. Before adopting Extreme Programming you need to have a deep understanding of the values that drive it so that the adaptations you make match the overall spirit of XP.
• Extreme Programming is a different kind of software development process, it is one that many programmers actually want to use. All too often however this means that some programmers end up pushing the idea of adopting XP when for one reason or another it does not really fit the organization.
• Extreme Programming is a great fit for some projects and organizations, but one size does not fit all. There are many other software development approaches, and with all of the exposure that Extreme Programming is getting, these alternatives are getting somewhat lost. Using an Agile Methodology does not necessarily mean using Extreme Programming.
• Adopting a new software development process can be hard. The organization has to learn how to effectively apply the new process and there is the transition period when some projects are using the new process while the rest are still using the old process. Sometimes it just makes sense to retain your existing process and to try to improve it by dropping parts, changing parts and adding new parts.

Some reviews

• I think it's a good book. I don't agree with all of it, but it is level-headed and Pete is nobody's fool: he's self-employed. -- Ron Jeffries on XP mailing list 8-Aug-2002