The Software Wiki

Extreme programming

Properties2
tagsprocess, framework, methodology
aliasesXP, Extreme Programming

3 min read

Extreme programming

By Allen Jay Bercero

Extreme Programming (XP) is an agile framework that concentrates on engineering practices, how the code is actually written and delivered, rather than on project ceremonies. Its premise: take the practices known to make software better and dial them up to the extreme. If code review is good, review continuously (pair programming); if testing is good, write the test first, always (test-driven development); if integration is good, integrate many times a day (continuous integration).

It was created by Kent Beck in the late 1990s (the Chrysler C3 payroll project) and laid out in Extreme Programming Explained (1999). Even teams that never say “we do XP” use its inventions daily. XP is where TDD, CI, and pairing entered the mainstream.

Also known as

XP

Don't confuse with

“Extreme” ≠ long hours. XP’s practices are demanding, but one of them is explicitly sustainable pace (originally the “40-hour week”). The “extreme” refers to turning good practices up to the maximum, not to crunch or heroics.

The five values

XP’s practices all serve five values: communication, simplicity, feedback, courage, and respect (respect was added in the second edition).

The practices

The practices reinforce each other. That’s the whole design. A representative set:

  • Pair programming: two developers, one workstation: one writes, one reviews and thinks ahead. Continuous review.
  • Test-driven development (TDD): write a failing automated test first, then the code to pass it, then refactor.
  • Continuous integration (CI): merge and build/test the whole system many times a day, so integration problems surface immediately.
  • Refactoring: continuously improve the design of existing code without changing its behavior.
  • Simple design: build the simplest thing that works now; don’t speculate about the future (YAGNI: “you aren’t gonna need it”).
  • Small, frequent releases: ship tiny increments often.
  • Collective code ownership: anyone can improve any part of the code; no gatekept silos.
  • Coding standards: a shared style so the collectively-owned code stays consistent.
  • Sustainable pace: no routine overtime; tired developers write bad code.
  • On-site customer: a real customer representative available to answer questions continuously.
  • The planning game: collaborative estimation and prioritization of work.
  • System metaphor: a shared, plain-language story of how the system works.

In plain English

XP is the “how to actually build the thing well” framework. Scrum tells you the meetings and roles; XP tells you to test-first, pair up, and integrate constantly. They’re often used together.

XP and Scrum together

Scrum is intentionally silent on engineering practices. It says organize work into sprints but not how to write good code. XP fills exactly that gap. Many strong teams run Scrum for the process and XP for the engineering, which is why so much “modern agile” is really Scrum’s ceremonies plus XP’s practices.

Legacy

XP’s biggest impact isn’t teams formally “doing XP”. It’s that its practices became industry defaults:

  • TDD and automated testing are everywhere.
  • Continuous integration grew into CI/CD and modern DevOps pipelines.
  • Refactoring became a first-class, named discipline (Martin Fowler’s Refactoring).
  • Pair programming (and its descendant, mob programming) is a standard tool.

See also

References

Graph View