Extreme programming (XP) is a software development methodology introduced by Kent Beck in 1996. The core idea is to take practices that are known to work — testing, code review, frequent releases, collaboration — and push them to their logical extreme. If testing is good, test everything. If code review is good, review code continuously by having two people write it together.
The defining practices of XP:
Pair programming: two developers share one machine. One writes code (the driver), the other reviews and thinks ahead (the navigator). They switch roles frequently. The result is continuous code review and knowledge sharing.
-
Continuous integration: integrate and build multiple times per day.
Small releases: ship working software in small increments, weekly or even daily.
Refactoring: improve the design of existing code continuously, supported by the test suite.
Simple design: do the simplest thing that could possibly work. Add complexity only when it is needed, not in anticipation of future needs.
Collective ownership: any developer can modify any part of the codebase. No code belongs to one person.
Sustainable pace: work at a pace you can sustain indefinitely. Overtime is a signal of a planning failure, not a solution.
On-site customer: a real user or customer representative is available to answer questions and clarify requirements throughout the development cycle.
XP had significant influence on the Agile manifesto, which was written in 2001. Many XP practices — especially TDD and continuous integration — became mainstream even in teams that do not follow XP as a complete methodology.