Extreme Programming Pocket Guide

Preface

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 ...