Extreme Programming

Extreme Programming (XP) is Kent Beck’s discipline of software development, first published in 1999 and rewritten in 2004. Beck opens the second edition by refusing the tidy answer: “Extreme Programming (XP) is about social change.” The methodology definition comes later, and he presents it as a path rather than a rulebook: XP is “a path of improvement to excellence for people coming together to develop software.”

The 1999 definition was crisper and Beck quotes it before retiring it: “a lightweight methodology for small-to-medium-sized teams” building software under vague or fast-changing requirements. True about XP’s origin and intent, he says, but no longer the whole story.

Three levels, not one list

The second edition is organized as a ladder of abstraction, and the ladder is the point. Values are the criteria of judgment (five of them). Principles are the bridging ideas, fourteen of them, for when no practice fits your situation: Humanity, Economics, Mutual Benefit, Self-Similarity, Improvement, Diversity, Reflection, Flow, Opportunity, Redundancy, Failure, Quality, Baby Steps, Accepted Responsibility. Practices are the concrete things a team does on a Tuesday.

A practice without its value is cargo cult; a value without practices is a poster. Beck’s claim is that the practices “complement each other, amplifying their effects,” which is also the awkward part: adopt one in isolation and it may cost more than it returns.

Primary and corollary

The structural change from 1999 is that the practices are split in two. Thirteen primary practices are the ones generally safe to start with, one at a time and in any order: Sit Together, Whole Team, Informative Workspace, Energized Work, Pair Programming, Stories, Weekly Cycle, Quarterly Cycle, Slack, Ten-Minute Build, Continuous Integration, Test-First Programming, and Incremental Design.

Eleven corollary practices are riskier and need the primary ones underneath them first: Real Customer Involvement, Incremental Deployment, Team Continuity, Shrinking Teams, Root-Cause Analysis, Shared Code, Code and Tests, Single Code Base, Daily Deployment, Negotiated Scope Contract, and Pay-Per-Use.

That split is the second edition’s real contribution. The 1999 book presented twelve practices as an all-or-nothing system, which made XP easy to dismiss as impossible and easy to adopt badly. Two names from that list are gone: Metaphor was largely dropped, and Simple Design and Refactoring were absorbed into Incremental Design. Refactoring survives as a technique everywhere in the book without being a named practice.

Reading it through intent and mechanism

XP rewards the intent-and-mechanism lens as well as DDD does. Sit Together is a 2004 mechanism, a shared physical room, wrapped around a durable intent: raise the bandwidth and lower the latency of team communication. Reject the open-plan office and you have rejected the mechanism, not the intent. Stories were index cards; the card is mechanism, the conversation is intent. Most arguments about whether XP “still applies” are arguments about 2004 mechanisms.

Signal: you can name which value a practice serves, and you adopted the practices one at a time rather than declaring an XP transformation.

Sources

• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004), ISBN 0-321-27865-8. Chapter 1 and the table of contents are in the publisher’s free sample: the definitions and all four lists above (5 values, 14 principles, 13 primary and 11 corollary practices) are taken from it verbatim.
• Bill Wake, Overview of “Extreme Programming Explained, 2/e”: the changes from the first edition, including the primary/corollary split, the addition of Respect, and the near-elimination of Metaphor.
• Martin Fowler, Extreme Programming: XP as “the primary catalyst that got attention to agile methods”, and the note that the two editions differ enough to matter.