Extreme Programming (XP)

A late 90's development based on the RAD ideas

Philosophy:

Keep it simple, build it quick, make it work
Analogies between software engineering and other engineering are false

our customer's requirements change more frequently
our products can be changed and altered more easily
the ratio of design cost to build cost is already much higher
history shows that software design diagrams are often not helpful in producing a reliable design
if we consider coding as "design" and compile and link as "build"
- the "build" task is so quick and cheap it should be considered instant and free
- almost all software development is design
the coding work becomes analagous to the up-front design effort we expect of an engineering discipline

Software developers must be allowed to do their job with the minimum of bureaucratic interference (as with RAD)

traditional methodologies are too bureaucratic
some rules are good
but more rules don't mean "better"

What is special about XP?

Four values

Communication, Feedback, Simplicity, and Courage

We design by coding

programmers meet and communicate with customers regularly
testing is the start point, not the end point

for each unit the programmer designs the test first
when the unit is ready, the test is run automatically

the design is kept simple
the design meets known existing requirements, not all possible future functionality

Beck (1999): "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy. Put in what you need when you need it."

programmers always work in pairs (considered more productive)
the system gets released regularly in small increments
customers are allowed to suggest improvements
redesigns are common - what they call refactoring - and handled easily

A thought

eAD (2000): "If changes are continuous, then we'll never get an up-front design completed. Furthermore, as changes become more unpredictable -- a great likelihood today -- then much anticipatory design likely will be wasted."

XP and project management

Each element of functionality is called a story, and each one is written on a card. The project scope and plan is simply and efficiently created by manipulating the cards by hand. Progress monitoring is achieved by tracking the unit test for each story.

Quality is assured by two main themes. Paired programmers ensure learning, adherence to standards, and avoidance of errors. Unit tests are core to coding and are designed before writing the code. The programmers are responsible for proving to the customer that each unit works correctly, rather than the customer having to prove that it doesn't work. See Hutcheson (2004) for a discussion of software testing in XP projects.

Efficiency is gained through

minimal bureaucracy;
focus on delivering quickly;
focus on getting it right first time;
only documentation: cards and source code;
not trying to predict all possible future changes;
handling current changes easily;
testing automated;
metric collection automated;
progress monitored by following story cards and test results.

Bibliography

Extreme Programming

Wells, J. D. (2002) Extreme Programming: A gentle introduction,

Highsmith, Jim, eAD (2000) Extreme Programming. Article in "eAD - e-business Application Delivery" by the Cutter Consortium

Beck, K. (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley

Nelson, E. (2002) Extreme Programming vs. Interaction Design: When two development design visionaries meet, there's room for consensus—but not much. Fawcette Technical Publications

Hutcheson, M. L. (2004) Testing in the eXtreme Programming (XP) Paradigm: A Case Study". Article in TickIT International, ISSN 1354-5884

Agile methods in general

The New Methodology, Martin Fowler, Chief Scientist, ThoughtWorks

Manifesto for Agile Software Development, The Agile Alliance.

At the Edge:, Information Architects, Inc.