Extreme programming

Extreme programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) project in the mid-1990s. Beck, along with Ward Cunningham and Ron Jeffries, developed the methodology to address the challenges of rapidly changing requirements and to promote a disciplined approach to software development. The term "extreme" refers to taking common software engineering practices to extreme levels, such as code reviews becoming continuous pair programming and testing becoming test-first development.

The methodology was formalized in Beck's 1999 book Extreme Programming Explained: Embrace Change, which introduced the core values and practices. XP gained widespread attention in the early 2000s as part of the broader agile movement, which was codified in the Agile Manifesto in 2001. XP's emphasis on technical excellence and customer collaboration made it a foundational influence on other agile methods like Scrum and Kanban.

XP is built on five values: communication, simplicity, feedback, courage, and respect. These values guide the behavior of the team and stakeholders. Communication ensures that all parties share information effectively; simplicity means doing the simplest thing that works; feedback is obtained through frequent testing and customer involvement; courage enables team members to make difficult decisions and embrace change; respect fosters a collaborative environment.

From these values, XP derives a set of principles, including rapid feedback, assuming simplicity, incremental change, embracing change, and quality work. These principles are operationalized through specific practices that are designed to be mutually reinforcing. For example, test-driven development provides rapid feedback, while continuous integration ensures that changes are integrated frequently to avoid integration hell.

XP defines a set of 12 core practices that teams are encouraged to adopt. These include planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards. Each practice addresses a specific aspect of software development, from requirements gathering to code quality.

Pair programming, where two developers work together at one workstation, is one of the most distinctive XP practices. It is intended to improve code quality and knowledge sharing. Test-driven development (TDD) requires writing tests before code, ensuring that every piece of functionality is verified. Continuous integration mandates that code is integrated and tested multiple times a day, reducing integration risks. These practices are designed to be used together; omitting one can weaken the effectiveness of the whole.

XP has been adopted by many organizations, particularly in the 2000s, and has influenced numerous agile frameworks. Its practices have been shown to improve code quality and team productivity in various studies. However, XP also faces criticisms. Some argue that its practices, such as pair programming and on-site customer, are difficult to implement in distributed teams or in environments with strict regulatory requirements. Others contend that XP's focus on simplicity may lead to insufficient architectural planning for complex systems.

Despite these criticisms, XP remains a significant methodology in software engineering education and practice. Many of its practices, such as test-driven development and continuous integration, have become mainstream in modern software development, even outside explicit XP adoption.

Beyond the well-known practices, XP has several lesser-known aspects. For instance, the planning game involves customers and developers collaboratively deciding on the scope and priority of features, but it also includes a 'spike' concept—a time-boxed investigation to reduce risk. XP also emphasizes 'system metaphor', a shared vision of how the system works, which is often overlooked in modern agile practice.

Another niche aspect is the '40-hour week' practice, which was later revised to 'sustainable pace' to accommodate varying work rhythms. XP also has a 'customer team' concept, where a group of stakeholders, not just a single person, represents the customer. Additionally, XP's 'collective ownership' encourages any developer to improve any code, which contrasts with other methodologies that assign ownership to individuals.

Pair programming

A practice where two programmers work together at one workstation, one writing code and the other reviewing in real time.

Test-driven development (TDD)

A development process where tests are written before the code that makes them pass, ensuring that code meets requirements.

Continuous integration

A practice of frequently integrating code changes into a shared repository, with automated builds and tests.

Planning game

A collaborative planning session where customers and developers prioritize features and estimate effort.

System metaphor

A shared conceptual model that guides the design and communication of the system's architecture.