Click here to Skip to main content
Click here to Skip to main content
Go to top

What Is Extreme Programming?

, , 21 Jul 2003
Rate this:
Please Sign up or sign in to vote.
A brief treatise on what XP is all about, with references to links, books, authors, and sites.

Table Of Contents

Introduction

Extreme Programming is a combination of simple, common-sense practices stressing communication, teamwork, requirements, and customer satisfaction. It is based on these values:
  • Communication - in order to successfully create and deliver a software product on time, there must be constant and thorough communication between members of the development team.
  • Feedback - Customer involvement and feedback are essential for customer satisfaction.
  • Simplicity - XP stresses the need to keep things as simple as possible while meeting the requirements laid out for the project.
  • Courage - Developers must have the courage and confidence to bring change and produce quality results.

Please consult the Resources section for the sources of the information in this article.

Core concepts in XP

The concepts of XP require their own vocabulary. Whether one introduces the vocabulary first or the concepts first is always the issue. In this case, the concepts are introduced first with links to the vocabulary.

Pair Programming

XP assumes that people work best in pairs so that they complement each other's strengths and weaknesses and so that knowledge can be spread between members of the team. The benefits as far as design, bug elimination, etc., can make two programmers at one computer be much more effective than they would be if they were each at separate computers. Here is an excerpt from a book report on The Costs and Benefits of Pair Programming (Laurie Williams & Alstair Cockburn), which talks about the benefits of pair programming.

Economics. A recent controlled experiment found only a small development cost for adding the second person. However, the resulting code also had fewer defects. The defect removal savings should more than offsets the development cost increase.

Satisfaction. People working in pairs found the experience more enjoyable than working alone.

Design quality. The study also found that the pairs produced shorter programs than their solo peers, indicating superior designs. Interviewees made the same comments.

Continuous Reviews. Pair programming's shoulder-to-shoulder technique serves as a continual design and code review, leading to most efficient defect removal rates.

Problem solving. Interview participants constantly refer to the team's ability to solve "impossible" problems faster.

Learning. Pair programmers repeatedly cite how much they learn from each other.

Team Building and Communication. Interview participants describe that people learn to discuss and work together. This improves team communication and effectiveness.

Staff and Project Management. Since multiple people have familiarity with each piece of code, pair programming reduces staff-loss risk.

Pairs and roles are changed often so that people can get the benefit of what each other has learned, and get a good feel for all the different areas of the system.

Weaknesses

This will not work for all programmers. It may be difficult to convince managers of the cost benefit. Also, it does not work where the programmers are working from a distance especially when time zones are an issue, however there are tools that can help this, such as http://www.gotomypc.com/ and other remote viewing/control software.

Stories and Test/Requirement-Driven Development

A project's requirements are laid out as individual stories. These stories have test cases. A test case includes the test and the desired results which, if met, indicate that that story is complete.

The project is done in iterations. At the end of an iteration, the next iteration is planned out in an iteration planning meeting. The customer (with the developers' guidance, of course) decides what stories are to be implemented in the next iteration, based on what is most important to them, and what is most practical to implement next.

It is important that each iteration takes just as long as all the others in a given project. The time that it took to complete a given story is recorded so that the programmers get a good feel for how much effort it takes to do that type of work.

The stories are broken down into tasks, which are the steps needed to implement a given user story. Developers then sign up to do those tasks.

On the completion of an iteration, acceptance tests are done to ensure that the test cases defined in that story have been met. The acceptance tests include both automated unit testing, and customer testing. This makes sure that all requirements are reached because the development is based around those requirements and there are definite indicators on whether a given requirement is met. It also breaks down the project into reachable goals rather than having programmers work away forever on an ever-expanding megalith.

Simplicity

Go the simplest way that meets the requirements - complexity may be clever, but it costs more in the end (maintenance, etc). No needless complications.

Design as You Go

This development method enables the design to evolve as you implement the stories and get an in-depth look at what is needed to fill the requirements. This will, of course, require a lot of refactoring of code, but it also will lead to the flexibility to add new features as they come. Needless to say, JIT Designing is one of the most controversial concepts in XP.

Weaknesses

It can become counter-productive to design as you go because certain things need to be planned out ahead of any implementation. With no concrete design, things can become chaos. However, there are many things which, if planned ahead, will only be re-designed later on.

Close Collaboration/Feedback

In XP, developers are in constant communication with each other and with their customer(s). This includes:

  • A daily stand-up meeting of all members of the group.
  • Swapping developers between tasks, so everyone gets to know all the different parts of the system being developed.

Continuous Integration

Continuous integration eliminates the headaches of working with outdated code and trying to integrate fragmented or diverging code into the system.

Sustainable Pace

The programming team should not work too much overtime and exhaust themselves. Try to maintain a moderate pace that can be sustained throughout the entire length of the project, rather than a hectic, crowded schedule that leaves you burned out by the middle of the project.

On-Site Customer

Have the customer be as available and as close as possible, preferably on-site. This will help you collaborate with the customer and meet their requirements.

Weaknesses: It is unlikely that it will be possible for a competent customer representative to be available at all times.

Collective Code Ownership

Anyone in the developer team should be able to change any piece of code.

Weakness: If the person who changed the code does not talk to others both before and after the changes, problems can arise.

Refactor Mercilessly

Otherwise known as "If it ain't broke, fix it!". When you see something that could be better and simpler, change it! According to XP, this will make the product constantly improve.

Weaknesses

If you're constantly changing things, it can be hard for everyone to keep up with the changes, both in knowledge and in coding. Regression testing is a must with constant refactoring. The reliance on testing becomes a weak point in the development process--are you adequately testing, and are your tests right? Testing, both the process of testing and the process of writing and testing the tests involves a hidden cost-benefit relationship. XP attempts to push the unknown and unmanageable qualities of "bug fixing" onto known and manageable tests but does not adequately address the core issue of what comprises a good test.

Commonly Used Terms

YAGNI

"You aren't gonna need it." An expression meaning: "That's not needed, and it will complicate things. Throw it out."

User Story

A project's requirements are laid out as individual user stories. These stories have test cases, which are tests and the desired results of those tests, which, if met, indicate that the implementation of that story is complete.

Small Releases

It is important to make small releases of the software product every time you add an area of functionality and make it workable. This helps by allowing the developers to:

  • Get feedback on the product at each step of the product's development
  • See the fruits of their work before the end of the development process.

Spike Solution

A spike solution is a small program/project to explore/test out different solutions to a tough technical or design problem.

JIT Designing

Designing as you go, rather than doing all the designing at the beginning of the project. This helps to cover the problem of changing user requirements, and a changing perspective of the system's implementation.

Unit Testing

A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration. See http://www.xprogramming.com/software.htm for a list of unit testing frameworks for different languages/platforms.

Stand-up Meeting

At some point in each day, a stand-up meeting is held where everyone stands up in a circle and talks about the project and its progress. It is important that the meeting be kept short, as the purpose is to encourage essential communication between all the members of the team, not to bore everyone by taking a long time hashing things through. It is for this reason that people should stand up for the meeting - it naturally keeps the meeting short.

Acceptance Test

A test which verifies if the requirements defined in a given user story have been met. This may be an automated unit test, or it may be a manual test by the customer.

Pair Programming

A system where two programmers work together at one computer. This way:

  • One team member's knowledge and expertise in the area being worked on can be easily passed on to another team member, thereby helping to spread knowledge of the system from developer to another;
  • The team members can complement each other's strengths and weaknesses;
  • One person can be thinking of the task at hand in terms of the overall design, while the other one thinks in terms of the details of implementation.

The benefits as far as design, bug elimination, etc, can make two programmers at one computer be much more effective than they would be if they were each at separate computers.

The team members must switch roles and re-pair often to keep the knowledge flowing rather than having "knowledge islands", where a certain small group on the team knows a lot about a certain aspect of the product, whereas the rest of the team knows almost nothing about it.

Iteration

A project is divided into a number of iterations of about 1-3 weeks each. In each iteration, a set of stories that are the most important to the customer are chosen and implemented. At the beginning of each iteration, an iteration planning meeting is held so that the customer can decide what user stories will be done in that iteration.

It is important to keep iterations the same length throughout the entire project, so that you won't be grinding along for weeks on the same area, and so that the project velocity can be easily measured.

Project Velocity

A measurement of the number of stories of a given size that can be done in a single iteration.

Task

A user story is broken up into tasks. Each task is taken up and completed by a member/pair on the development team.

Test Case

A usage situation of a given part of the system for which tests are made to ensure that it works as it should. For example, the customer may want to be able to enter in a part number and receive a report on the current price and availability. Before the programmer implements this functionality, he writes a test, which, if it succeeds, indicates that the functionality works as expected.

System Metaphor/System Model

A system metaphor should be chosen for each project, to keep the design simple and orderly, and to give people an idea of what the system should be like/ how it should work. A system metaphor is a comparison of the system being developed to a known system model. This helps people to get an overall picture of what the system is like and how it works, from their experience with the system model the system is being compared to. The system metaphor can be anything from an Accounting metaphor, with accounts, transactions, and ledgers, to an Auction metaphor, with sellers, bidders, items-to-sell, and bids.

Iteration Planning Meeting

A planning session to plan out what user stories will be completed in the next iteration of the software product.

Release Planning Meeting

A planning session to plan out what will be done for the next release of the software product.

Regression Testing

When a fault is found in a system, a regression test is made to ensure that the problem does not recur. This forms a "bug net" to catch bugs as soon as they enter the system.

Coding Standard

Coding standards are important in XP. A coding standard keeps code uniform and readable, and makes it as coherent as if it had been written by only one competent developer.

Fault

(In the context of QA/Testing) A fault is an area that was overlooked in designing/creating the system that could cause undesired operation.

Bug

(In the context of QA/Testing) An issue that causes undesired operation, that is due to an error on the part of the developer(s).

Issue

(In the context of QA/Testing) Any undesired operation in the software product.

Feature

A feature is any type of functionality requested by the user. It is NOT another word for bug.

Problem

(In the context of QA/Testing) A problem is an issue that causes undesired operation, and is not the fault of the software product, but can be overcome by changes to the software product.

Stress Test

A test which simulates the largest possible load on a system.

Monkey Test

Test to see how the system behaves under nonsensical input.

Parallel Test

A test to ensure that two systems work exactly the same as each other.

Key Players/Authors:

Kent Beck is the originator of XP. He has written numerous books on the subject.

Laurie Williams has done extensive writing and research on Extreme Programming, especially in the area of Pair Programming.

Martin Fowler has written some books on XP. He is well known for his work and writing on refactoring.

Jim Highsmith has written books on a couple of different software development methodologies, including XP.

William Wake is an agile development team coach, and has written numerous articles on specific topics within XP.

Ron Jefferies is one of the inventors of XP, and has written many books on the subject.

IBM is fairly heavily involved with XP, especially since it works with the Java community (Eclipse, etc), and XP is closely tied to Java.

I apologize if I have missed mentioning any important figures in the XP arena. There are hundreds of important figures in XP, but if I have missed any of the most prominent figures, please let me know.

Resources

Sites

Links

Books

Extreme Programming Explained: Embrace Change by Kent Beck - Written by the originator of XP, and one of the most definitive guides available on XP. A MUST-READ! A 42-page preview is available at Amazon.com

Extreme Programming Installed by Ron Jefferies, Ann Anderson, and Chet Hendrickson - This book goes deeper into XP techniques than Extreme Programming Explained. Should probably be read after the aforementioned book.

The Costs and Benefits of Pair Programming by Laurie Williams & Alstair Cockburn - Results of an empirical study on Pair Programming. Shows and studies the benefits of pair programming

Tools

XProgramming Unit Testing Downloads Section - Links to downloads of unit testing software for most common languages.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Authors

Marc Clifton

United States United States
Marc is the creator of two open source projets, MyXaml, a declarative (XML) instantiation engine and the Advanced Unit Testing framework, and Interacx, a commercial n-tier RAD application suite.  Visit his website, www.marcclifton.com, where you will find many of his articles and his blog.
 
Marc lives in Philmont, NY.

J. Dunlap
Web Developer
United States United States
My main goal as a developer is to improve the way software is designed, and how it interacts with the user. I like designing software best, but I also like coding and documentation. I especially like to work with user interfaces and graphics.
 
I have extensive knowledge of the .NET Framework, and like to delve into its internals. I specialize in working with VG.net and MyXaml. I also like to work with ASP.NET, AJAX, and DHTML.

You may also be interested in...

Comments and Discussions

 
GeneralTesting events PinmemberN a v a n e e t h4-Feb-08 22:39 
GeneralRe: Testing events PinprotectorMarc Clifton5-Feb-08 0:52 
GeneralRe: Testing events PinmemberN a v a n e e t h5-Feb-08 2:21 
QuestionIs XP successfull for big projects ? PinmemberN a v a n e e t h20-Jan-08 20:17 
AnswerRe: Is XP successfull for big projects ? PinprotectorMarc Clifton21-Jan-08 1:13 
GeneralRe: Is XP successfull for big projects ? PinmemberN a v a n e e t h21-Jan-08 2:30 
GeneralRe: Is XP successfull for big projects ? PinprotectorMarc Clifton21-Jan-08 2:43 
GeneralRe: Is XP successfull for big projects ? PinmemberN a v a n e e t h21-Jan-08 18:35 
GeneralWriting Unit Tests PinmemberN a v a n e e t h16-Jan-08 0:02 
GeneralRe: Writing Unit Tests PinprotectorMarc Clifton16-Jan-08 1:04 
GeneralRe: Writing Unit Tests PinmemberN a v a n e e t h16-Jan-08 19:45 
GeneralRe: Writing Unit Tests PinprotectorMarc Clifton17-Jan-08 1:01 
GeneralRe: Writing Unit Tests PinmemberN a v a n e e t h17-Jan-08 4:17 
QuestionXP == just industry acceptance? PinmemberNirosh14-Nov-06 20:58 
GeneralAn overdue Thank You! PinmemberJohn R. Shaw23-Oct-06 21:09 
GeneralXP software PinmemberHugo.Pereira17-Apr-06 22:43 
GeneralWhy is there extreme programmers around ? ;-) PinmemberManuel Permuy4-Feb-04 13:30 
GeneralRe: Why is there extreme programmers around ? ;-) PineditorMarc Clifton4-Feb-04 14:17 
GeneralDesign Methodologies Pinmemberomanske7-Oct-03 11:05 
GeneralRe: Design Methodologies PineditorMarc Clifton4-Feb-04 15:19 
GeneralGood writing Pinmemberalgruber29-Jul-03 5:40 
GeneralRe: Good writing PineditorMarc Clifton29-Jul-03 6:06 
GeneralRe: Good writing Pinmemberalgruber3-Aug-03 18:07 
GeneralRe: Good writing PineditorMarc Clifton4-Aug-03 6:36 
GeneralNice overview of XP... PinsussTestosteles25-Jul-03 8:34 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140926.1 | Last Updated 22 Jul 2003
Article Copyright 2003 by Marc Clifton, J. Dunlap
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid