There’s a word for software that cannot be changed after delivery. That word is hardware.
In the early days of computer programming, processor time was expensive. If you had an error that kept your program from running, it could be days or weeks before you had the chance to try again. Any change could ripple through the rest of your program. To save time and money, you’d have to be completely sure your program would work before it reached the computer. You could spend hours poring over your code.
The obvious lesson was change is painful and expensive.
A few decades later, Extreme Programming (hereafter called XP) claims otherwise. It’s possible to develop high-quality software despite—or even because of—change. XP’s great assumption is that a little bit of planning, a little bit of coding, and a little bit of testing let you decide if you’re right or wrong while it’s still cheap to change your mind. You still need some idea where you’re going, but you don’t have to commit to an exact itinerary. You can change your mind along the way without spending a fortune.
XP is a software development method that emphasizes simplicity, feedback, courage, and communication. It’s partly a reaction to the pervasive belief that change is bad and avoidable. Kent Beck introduced XP in Extreme Programming Explained (Addison-Wesley) as a collection of 12 fundamental XP practices. Few of these practices are new—they’ve been part of the canon of best practices for decades. What is unique to XP is how they build on and reinforce each other.
In the past few years, thousands of programmers and companies have discovered that XP helps them produce better, more reliable software with less stress. XP concepts have even infiltrated vocabularies and toolsets outside of XP teams. Consider, for example, the renewed interest in testing and testing tools among software engineers.
Effective software development is difficult, no matter what your method. Being able to adapt to change at a moment’s notice requires tremendous discipline and care. The strength of your team—your good habits and best practices—are vital to the success of your project.
There are many ways to write good software. Straight, by-the-book XP is one of those ways. A well-disciplined, extremely smart, and highly motivated team can probably produce the right software that does the right thing at the right price with any reasonable development process. The rest of us need something more.
Any reasonable process has its strengths and weaknesses. Many software development teams pick and choose practices from many approaches. XP has an edge because its 12 core practices reinforce and draw upon each other. The strengths of one practice fill in for the weaknesses of another. Understanding XP’s values and practices and their relationships will help you adopt it successfully. You must play to its strengths and avoid its pitfalls. (Thankfully, if you’re doing XP as a whole, its pitfalls are few.)
XP is ideal for a small group of developers within a company, writing software for that company. It’s easy to find a real customer. The software can be delivered frequently. The outcome isn’t obvious from the start; change is normal.
XP tends to add little value to projects that know exactly what they must build. Why optimize for change if it rarely happens? Of course, several XP practices can help any software project.
This book explores XP and its parts. It’s arranged topically, exploring the assumptions, practices, artifacts, events, roles, and guidelines individually. Each section stands alone as much as possible. Though XP was carefully crafted to fit together as a whole, exploring each idea on its own allows this book to serve as a reference in the heat of a project.
This book is aimed primarily at developers. Many development methods treat programmers almost as interchangeable cogs in a machine. XP is different, partly because it evolves with the experiences of practicing programmers, and partly because it strips away so much nonessential work. Of course, XP also puts developers and customers in close proximity, so sections of the book apply to customers, too.
Ideally, you will be able to adopt XP completely on your project. Practically, changing your team and your organization will take time. You may decide to adopt XP in stages or adopt only a few practices. XP may be too extreme for you to adopt right now, but understanding how it fits together can help you improve an existing process or create a new process.
The goal of software development is to create good systems that meet business needs with the available resources. XP can help you do just that.
This book contains eight sections, arranged topically:
Describes XP, the problem it’s intended to solve, and its values
Explains the 12 core practices of XP
Details the events of an XP project
Excavates XP’s physical artifacts
Introduces the major and minor roles people play in XP
Defines XP’s coding principles
Suggests a plan by which you can adopt XP
Lists further resources
This book uses the following typographic conventions:
Used for new terms where they are defined and for emphasis
Used for class names and any literal text
Please address comments and questions concerning this book to the publisher:
|O’Reilly & Associates, Inc.|
|1005 Gravenstein Highway North|
|Sebastopol, CA 95472|
|(800) 998-9938 (in the United States or Canada)|
|(707) 829-0515 (international/local)|
|(707) 829-0104 (fax)|
There is a web page for this book, which lists errata, examples, or any additional information. You can access this page at:
To comment or ask technical questions about this book, send email to:
For more information about books, conferences, Resource Centers, and the O’Reilly Network, see the O’Reilly web site at:
To start, I’d like to thank Tim O’Reilly for proposing this idea and my editors, Linda Mui and Tatiana Diaz, for helping to make it a reality.
The size of this book belies the hard work of many friends and colleagues who provided reviews and advice. In alphabetical order, they are Kate Agena, Ann Barcomb, Tony Bowden, Sarah Breen, Ward Cunningham, Schuyler Erle, Nick Forrette, Jim Little, Rob Nagler, Aleatha Parker, Karen Pauley, Curtis Poe, Allison Randal, and Dave Thomas. With people this smart, any remaining errors and omissions are obviously mine alone.
This book is dedicated to my nephew, Jacob Edward, whose release date somehow preceded mine. I’m trying to make the world better for you, buddy.