Introduction to eXtreme Programming

Mike Grant mike@acm.jhu.edu April 5, 2001

The following shamefully misinformed article appeared on Slashdot just a few days ago: Planning Extreme Programming Posted by timothy on Tuesday April 03, @09:30AM from the measure-thrice-cut-once dept. However skeptical the ads make you, its hard to deny that what used to be considered supercomputing power keeps showing up in consumer-priced boxes, and the threshold of what really is extreme has crept steadily upward. If youre planning a project of more than average size, though, the review that chromatic contributed below of Planning Extreme Programming could be a valuable read, and the ideas in the book itself could save you a lot of money and time. Even if you have no plans to desire to install a beowulf in your broomcloset, its interesting to consider what sort of thought must go into any large-scale programming project. Contrary to what many think, extreme programming has nothing to do with large, dicult, or complex projects. 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 can be (supercially) summed up in twelve practices1 :

The Planning Process

The XP planning process allows the XP customer to dene the business value of desired features, and uses cost estimates provided by the programmers, to
1 The descriptions of these practices, and pretty much this entire document were shamelessly stolen from http://www.xprogramming.com, the authoritative web site for XP, edited by Ron Jeries.

Introduction to eXtreme Programming

April 5, 2001

choose what needs to be done and what needs to be deferred. The eect of XPs 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 rst, then software that fullls the requirements reected 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.

Introduction to eXtreme Programming

April 5, 2001

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.

10

40-hour Week

Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and eective.

11

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 eect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project.

12

Coding Standard

For a team to work eectively 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.

Resources
1. Jeries, R. http://www.xprogramming.com 2. Fowler, M. Refactoring : Improving the Design of Existing Code 3. Jeries, R. et al Extreme Programming Installed 4. Beck, K. Extreme Programming Explained: Embrace Change 5. Beck, K. et al Planning Extreme Programming This document itself can be found at http://acm.jhu.edu/~mike/peer.