Chapter 1: XP in a Nuthouse (Oops, We Mean Nutshell)

Overview

You Say Design, I Say Just Code

(Sing to the tune of Hello Goodbye by The Beatles)

We write tests
We write code
Up-front design
No no no no no

We just . . . write code
You say design
I say write code

Just code, just code
I don t know why you say design
I say just code

Requirements

Are just code
So s design

Code is all we know

QA . . . smell the code
You do design
I just write code
Just code, just code
I don t know why you do design
I just write code

Extreme Programming (XP) has become something of a phenomenon . Currently, almost 20 books are available on XP, with more on the way. A quick search on the Web reveals a world of activity and discussion surrounding XP. In many ways, XP is the new pop-culture software process, increasingly trendy with programmers all around the world and vociferously defended by its followers.

In this book, we examine the sorts of problems that XP is trying to solve, and we discuss why we feel XP is more fragile than other agile methodologies. Think of this book as a lighthouse for wary travelers.

It would be wrong of us to suggest that XP can t possibly work, because reports of successful XP projects do surface every now and again. Even a stopped clock is right twice a day. So we re not saying that XP can t possibly work, because sometimes it does (although we refer you to the night gunner scene in Chapter 8 for our thoughts on this. In addition, bear in mind that the most loudly proclaimed XP success story was rather dubious to say the least. We analyze that particular project in Chapter 2).

So our primary message in this book is that XP is inherently high-risk, brittle, and prone to certain failure modes. It s also suited only to a very small number of project types (mostly small-scale projects with a very small team of programmers). We explore these points in more detail in the upcoming chapters.

To round off the book, in Chapter 15 we explore various ways to achieve the goals that XPers aspire toward (software agility, rapid development, simple design, feedback, customer satisfaction, and so on) using safer processes that XPers claim to be unworkable but that we ve used successfully and seen used successfully over and over again. ^{[1 ]} We also present a case study of a real-life project that is in many ways XP-like and fits the agile bill, but that has been tailored to address XP s many failure modes.

^{[1 ]} We include a summary of our refactored process at the end of this chapter.