According to XP, the cost structure of software development has changed over the last 30 years.
When costs grow exponentially, it makes to spend money now to avoid big costs later. When they’re growing more slowly, it can make sense to avoid spending money.
Paying for design up-front creates early costs. Extreme Programming advocates more of a "pay-as-you-go" approach.
As the diagram suggests, costs tend to remain lower for longer in pay-as-you-go. Notice the area labeled "x" in the diagram: this represents the "extra" costs you pay. These costs can be even higher than you might think: the cost of programming to an up-front design can be higher, as you have to deal with more complexity earlier on in the programming. Also, the design will guess wrong about some things, putting in too much complexity in some places, and not enough in others.
Principles and Practices
XP is based on several principles:
- Rapid feedback
- Assume simplicity
- Incremental change
- Embrace change
- Quality work
The principles guide the practices used by XP teams:
- Planning Game
- Small releases
- Pair programming
- Simple design
- Collective ownership
- Continuous integration
- Open workspace
- 40-hour week
We’ll focus on a few key practices here.
The Planning Game is based around the idea of user stories, a lightweight form of use cases. These are small stories (2-3 sentence) that a customer cares about, that can be reasonably tested, and that can be estimated and prioritized. (The customer is on-site during development, so they can provide more details as the team needs them.)
The Planning Game helps the user and developers prioritize stories. The user gets to add stories as needed, and splits stories that are too big to easily estimate.
There are two major types of tests in XP: unit tests and functional tests.
Unit tests are created by the developer, before and during programming. Developers have a responsibility to ensure that unit tests always run at 100%. These tests are used to ensure that development and refactoring make "forward progress".
Functional tests are specified by the user, then estimated and implemented by the developers (or an explicit test team). These tests will typically be run one or more times each day, as people integrate their work of the last few hours. The functional tests are what let the customer know there is true progress. Because they’re developed throughout the process (not at the end), functional tests also act as part of the specification.
In XP, the guiding mottos are "the simplest thing that could possibly work" and "you aren’t going to need it". These encourage fine-grained design, aided by refactoring.
Sometimes, an aspect of the design is too complex to know exactly what "could possibly" work, so an XP team will do a "spike" (a quick but narrow implementation) to help make the decision.
All production code is written by a pair. (One person has direct responsibility for the task, but will work with someone else to do it.) This provides built-in code and design reviews, as well as cross-team learning.
The pairing is flexible; you’d normally have two or more different partners in a day.
Customer and Developer Rights
XP explicitly delineates the rights and duties of the parties involved in development. (This section excerpted directly from Ron Jeffries’ site.)
Manager and Customer Rights
How to begin with XP? If you can’t adopt it all at once, you need to apply those practices you can:
Strive for user involvement – push for user presence with the development team. Put tests in place. Many groups pay lip service to tests, but you will move faster the better tests you have. Tests are a prerequisite for refactoring, which lets you begin with simple designs and grow them as needed. Pair programming builds in reviews and learning, and can help you spread the XP practices within a team.
[As of late 1999] I’ve never worked with an XP team (outside of a week’s training), so this is somewhat theoretical for me. My recent teams have used a lightweight version of Rational’s Unified Process: tests are required, but they’re not as up-front, ubiquitous, or as automated as they should be; teamwork is acceptable but true pair programming isn’t practiced; we’ve had more of an up-front focus than XP would have. Nevertheless, I think our teams have been struggling toward some of the XP practices, and would find most of them appropriate.
- Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley, 1999.
- Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley, 1999.
- Wiki (http://c2.com/cgi/wiki?ExtremeProgramming)