Extreme Programming Pocket Guide

Part I. Why XP?

[The] cost of fixing things increases profoundly the longer we wait.

Stretching out design just makes the errors cost /more/, whether found inside design or in a later phase.

The right lesson is [to] find out right away whether we’ve made a mistake. The best way to do that is to take an idea through analysis, design, code, and test in the shortest possible time.

— Ron Jeffries^[1]

Many software development methods assert that change is expensive. A bug caught in the maintenance phase of a project tends to cost more than a bug caught in the planning phase, as shown in Figure 1. Extreme Programming makes a different claim: it’s possible to keep the cost of changing software from rising dramatically with time.

What kind of software would you develop if you had the freedom to adapt to changing requirements and environments with grace and ease? Given sufficient time and resources, what could you accomplish? Is your goal even realistic? If so, how can you achieve it? XP attempts to answer all of these questions.

Figure 1. The traditional cost-of-change curve

^[1] 8 July 2002, on the XP Mailing List (http://groups.yahoo.com/group/extremeprogramming/message/55241).