Introduction

Before we get started, we want to draw attention to some of this book s very unique elements. This isn t your normal, run-of-the-mill computer science book! The subject matter is, we feel, worthy of a satirical treatment, so that s what we ve set out to give it. In addition to the satire , there s also lots of dry humor. We do occasionally get serious and give a systematic breakdown of the flaws and dangers inherent in Extreme Programming (XP).

Having said that, this book isn t an outright slam piece. As we point out later, not all of XP is bad. So we do aim to provide a balanced critique and to signpost the parts of XP that we feel can be salvaged or refactored into something that achieves the same agile goals in a more robust kind of way.

XP has received more than its fair share of hype, and new XP books continue to appear at an incredible rate. The industry is being affected by the inflated claims surrounding XP in all sorts of ways (some of them positive, as we explore, but many of them negative). With this in mind, we feel a book that swims against the tide and rejects XP is important.

Here s one small example of how XP is affecting the industry. Matt (intrepid coauthor of this book) received an e-mail from a consultant who had just recently lost an important contract because he refused to launch into a project without doing some detailed requirements analysis and up-front design first. The customer had read about XP and told the consultant that if XP says it s okay to run a project like that, then we ll find someone who will skip requirements and up-front design!

Although some businesspeople hear about XP and instantly go insane (as the consultant story seems to suggest), others dig their heels in and reject change. In fact, a major problem faced by teams wanting to introduce XP into their organization is that XP requires a significant mind shift in the entire organization, from the way teams are organized to the way the company does business with its customers. This book analyzes XP s flaws and proposes an alternative approach to agility that requires much less change in existing organizations, while still retaining XP s agile goals. You can use this alternative approach as a crib sheet for when you tailor your own agile methodology. (Near the end of the book, we also provide some pointers to other agile processes that we feel to be more rigorous than XP.)

Most of all, though, this book aims to shatter some of the myths that are beginning to spring up in the wake of the XP tidal wave, such as it s okay not to document your work, an on-site customer and a bunch of automated tests are a sufficient replacement for a written requirements spec, the needs and comfort of the individual are secondary to the project (i.e., pair-program with us or get another job ), and so on. And we aim to do this in an entertaining and humorous way because . . . well, because the subject matter calls for it.

Who Should Read This Book?

XP is often introduced into organizations by the programmers. This isn t surprising, because XP is a remarkably programmer-friendly methodology. It raises the profile of programmers (not a bad thing in itself) and puts them on a level footing with the customer. So if you re a manager or a customer who is being sold the idea of using XP in the next project, this book provides a valuable contrary viewpoint.

If you re a programmer who is introducing XP into an organization, this book should help because it outlines a lot of the dangers that tend to get brushed over in other XP books but that can be potential project-killers.

If you re thinking about tailoring XP to extract all its good bits, but you want to avoid the house of cards effect, where one small change to the process brings the whole lot crashing down, this book provides some valuable guidance.

Also, if you re a software developer and just want to read some good old sidesplitting satire, this book should fit the bill!