Methodologies & SDLC Deep Dive · 5 of 10

Extreme Programming — Engineering Discipline as Method

Kent Beck's 1999 book Extreme Programming Explained took good engineering habits and turned the dial up to "extreme." If code review is good, do it constantly (pair programming). If integration is good, do it many times a day (CI). If testing is good, write the tests first (TDD). XP is where most of modern Agile's engineering practices come from.

Pair programmingTDDCIRefactoringSimple designYAGNI
← Back to Methodologies & SDLC
Anatomy

The Twelve Practices

  • Pair programming — two devs, one keyboard. Continuous review, knowledge sharing.
  • Test-Driven Development (TDD) — red → green → refactor.
  • Continuous Integration — merge to main many times a day; never have a big-bang merge.
  • Refactoring — small structural changes preserving behavior; the safety net is the test suite.
  • Simple design / YAGNI — "you ain't gonna need it"; build for today's known requirements.
  • Collective code ownership — anyone can change anything; the tests catch you.
  • Coding standards — formatters, linters, conventions enforced.
  • Small releases — ship something every 1–3 weeks, get user feedback.
  • Planning game — collaborative scoping with the customer.
  • On-site customer — a real user is part of the team to answer questions.
  • Sustainable pace — 40-hour week; tired devs make broken software.
  • Metaphor — a shared analogy that gives the system coherent vocabulary.
Why It Still Matters

The Lasting Influence

  • TDD went mainstream because of XP — JUnit was originally an XP tool.
  • Continuous Integration is now table stakes; XP put the term on the map.
  • Refactoring as a named, disciplined activity comes from the XP community (Martin Fowler's book).
  • "Mob programming" and modern ensemble programming are direct descendants of pair programming.
Tradeoffs

What Doesn't Always Fly

  • Pair programming is exhausting all day every day. Most teams pair on hard problems and solo on routine ones.
  • "On-site customer" is rarely available — Scrum's Product Owner is the modern compromise.
  • TDD has a learning curve — new TDDers write brittle tests that pin down implementation details.
  • Hard to scale beyond one team — XP doesn't say much about coordination at 50+ people.
  • Cultural resistance. "I have to share my keyboard?" is a real conversation.
Continue

Other Methodologies

← Kanban Lean → SAFe / LeSS → DevOps → ↑ Back to Methodologies & SDLC