Home (All Topics) → Technology → Methodologies → Extreme Programming (XP) Methodology

Extreme Programming (XP) Methodology

The main goal of XP is to lower the cost of change in software requirements. With traditional system development methodologies, like the Waterfall Methodology, the requirements for the system are determined and often “frozen” at the beginning of the development project. This means that the cost of changing the requirements at a later stage in the project — something that is very common in the real-world — can be very high.

XP Core Practices

The core practices of Extreme Programming, as described in the first edition of Extreme programming
Explained can be grouped into four areas (12 practices) as follows:

Fine scale feedback

Test driven development
Planning game
Whole team
Pair programming

Continuous process rather than batch

Continuous Integration
Design Improvement (a.k.a refactor)
Small Releases

Shared understanding

Simple design
System metaphor
Collective code ownership
Coding standards or coding conventions

Programmer welfare

Sustainable pace (i.e. forty hour week)

In the second edition of Extreme programming explained a set of corollary practices are listed in addition to the primary practices.

The core practices are derived from generally accepted best practices, and are taken to extremes:

Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritizes work for the team, and who can answer questions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their code.
If simple code is good, re-write code when it becomes complex.
Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-driven development.

It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons. However, XP has been used successfully on teams of over a hundred developers. It is not that XP doesn't scale, just that few people have tried to scale it, and proponents of XP refuse to speculate on this facet of the process.

XP Controversy

Detailed specifications are not created or preserved.
Programmers are required to work in pairs – not all software developers expect to be asked to work this way.
There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with “the simplest thing that could possibly work” and adding complexity only when it's required by failing tests. This could result in more re-design effort than only re-designing when requirements change.
A customer representative is attached to the project. This role can become a single-point-of-failure for the project and some people have found it to be a source of stress.

References
Wikipedia, The Free Encyclopedia

Other Methodologies