Introduction to Extreme Programming (XP)

Posted on by

Background

According to XP, the cost structure of software development has changed over the last 30 years.

Exponential cost increase or not?

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
  • Metaphor
  • Tests
  • Pair programming
  • Refactoring
  • Simple design
  • Collective ownership
  • Continuous integration
  • Open workspace
  • 40-hour week

We’ll focus on a few key practices here.

Planning Game

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.

Tests

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.

Simple Design

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.

Pair Programming

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

  1. You have the right to an overall plan, to know what can be accomplished, when, and at what cost.
  2. You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
  3. You have the right to change your mind, to substitute functionality, and to change priorities.
  4. You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can even cancel at any time and be left with a useful working system reflecting investment to date.

Developer Rights

  1. You have the right to know what is needed, via clear requirement stories, with clear declarations of priority.
  2. You have the right to say how long each story will take you to implement, and to revise estimates given experience.
  3. You have the right to identify risky stories, to have them given higher priority, and to experiment to reduce risk.
  4. You have the right to produce quality work at all times. you have the right to peace, fun, and productive and enjoyable work.

(See http://xprogramming.com/products.htm.)

Beginning XP

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.

Caveats

[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.

More Information

[Written 12-28-99]