Introduction to eXtreme Programming by isp11018


									          Introduction to eXtreme Programming
                                     Mike Grant
                                      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, it’s 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 you’re 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, it’s 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, difficult, 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 re-
quirements. XP can be (superficially) summed up in twelve “practices”1 :

1     The Planning Process
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
   1 The descriptions of these practices, and pretty much this entire document were shamelessly

stolen from, the authoritative web site for XP, edited by Ron

Introduction to
eXtreme Programming                                                April 5, 2001

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.

2    Small Releases
XP teams put a simple system into production early, and update it frequently
on a very short cycle.

3    Metaphor
XP teams use a common “system of names” and a common system description
that guides development and communication.

4    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

5    Testing
XP teams focus on validation of the software at all times. Programmers de-
velop 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.

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

7    Pair Programming
XP programmers write all production code in pairs, two programmers working
together at one machine. Pair programming has been shown by many exper-
iments to produce better software at similar or lower cost than programmers
working alone.

Introduction to
eXtreme Programming                                                April 5, 2001

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

9     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 effective.

11      On-site Customer
An XP project is steered by a dedicated individual who is empowered to de-
termine 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

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

    1. Jeffries, R.
    2. Fowler, M. Refactoring : Improving the Design of Existing Code
    3. Jeffries, 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


To top