What is XP

Extreme Programming, or XP, is a lightweight discipline of software development based on principles of simplicity, communication, feedback, and courage. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements.

XP was developed by Kent Beck, who wrote the original book on the subject, Extreme Programming Explained. Two new books will reach the market by October, Extreme Programming Installed, by Ron Jeffries (your host), Ann Anderson, and Chet Hendrickson; and Planning Extreme Programming, by Kent Beck and Martin Fowler.

Ultimately, any team's software development methodology needs to be customized to the team and their circumstances. No methodology is just a collection of rules to be performed in rote fashion, and XP - in spite of its famous rules - is no exception.

You will find two main divisions of XP writing here, and on the other sites we will point to. There are discussions of specific XP rules and practices, and there are discussions of the principles behind XP. Both are important. When a team is newly adopting XP, I recommend that they begin with the practices described here and in Extreme Programming Installed. These practices will tend to keep the team on track while they build up a grasp of the principles that form the basis for the practices. My colleague Don Wells, on the other hand, takes a gentler, less regimented approach to learning XP, and you should take a look at his site, www.extremeprogramming.org, as well as this one.

There are twelve key practices in XP, and we'll discuss them briefly here. Some of them are discussed in much more detail on this site, while others are barely touched upon. To provide input on this site, use the links on the home page. For further information on XP, try the links on our XP Links page.

The Planning Process, sometimes called the Planning Game.: The XP planning process allows the XP "customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success.
Small Releases.: XP teams put a simple system into production early, and update it frequently on a very short cycle.
Metaphor.: XP teams use a common "system of names" and a common system description that guides development and communication.
Simple Design.: A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below.
Testing.: XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided.
Refactoring.: XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete.
Pair Programming.: XP programmers write all production code in pairs, two programmers working together at one machine. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone.
Collective Ownership.: All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay.
Continuous Integration.: XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.
40-hour Week.: Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.
On-site Customer.: An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project.
Coding Standard.: For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly.

Please check these links, and the other links on the site. There is a great deal of material here. We hope you will find it interesting and tantalizing, and that you'll want to learn more about XP.

The C3 team, including Ann Anderson, Ralph Beattie, David Bryant, Marie DeArment, Margaret Fronczak, Rich Garzaniti, Dennis Gore, Brian Hacker, Chet Hendrickson, Doug Joppie, David Kim, Paul Kowalsky, Debbie Mueller, Richard Nutter, Adrian Pantea, Don Thomas, Don Wells..