Extreme Programming Pocket Guide

Part II. Extreme Programming Practices

XP’s 12 practices rely on and support each other. Their feedback helps guide your decisions. Their interactions help you to achieve high levels of productivity and quality. It’s possible to write good software with only a few practices, but XP works best with every piece in play—the whole is much greater than the sum of its parts.

Each practice can have several roles. For example, testing influences design and encourages small, controlled experiments. It also applies conservative pressure for stability. Picking and choosing a few practices without appreciating how they support each other can lead to dramatic failures—refactoring without a rigorous test suite can introduce subtle bugs that need extensive debugging. Although this chapter attempts to explain the ideas behind each practice and how it fits into XP as a whole, the best way to understand XP is to practice it in its entirety.

Doing XP by the book requires discipline. While a team of the world’s very best developers might practice test-driven development fully, the rest of us need the positive peer pressure of a programming partner to resist the temptation to put off testing. Though many of the practices can improve your software on their own, they’re less effective when removed from their supporting framework.

If XP as a whole is truly impossible and not merely impractical for you, be cautious about adopting XP piecemeal. With the right team, you can find a combination of natural talent ...