An Overview of Extreme Programming and Its Role in Agile Projects

By Mark C. Layton

One popular approach to product development, specific to software, is extreme programming (XP). Extreme programming takes the best practices of software development to an extreme level. Created in 1996 by Kent Beck, with the help of Ward Cunningham and Ron Jeffries, the principles of XP were originally described in Beck’s 1999 book, Extreme Programming Explained (Addison-Wesley Professional), which has since been updated.

The focus of extreme programming is customer satisfaction. XP teams achieve high customer satisfaction by developing features when the customer needs them. New requests are part of the development team’s daily routine, and the team is empowered to deal with these requests whenever they crop up. The team organizes itself around any problem that arises and solves it as efficiently as possible.

As XP has grown as a practice, XP roles have blurred. A typical project now consists of people in customer, management, technical, and project support groups. Each person may play a different role at different times.

Discovering extreme programming principles

Basic approaches in extreme programming are based on Agile principles. These approaches are as follows:

  • Coding is the core activity. Software code not only delivers the solution but can also be used to explore problems. For example, a programmer can explain a problem using code.
  • XP teams do lots of testing. If doing just a little testing helps you identify some defects, a lot of testing will help you find more. In fact, developers don’t start coding until they’ve worked out the success criteria for the requirement and designed the unit tests. A defect is not a failure of code; it’s a failure to define the right test.
  • Communication between customer and programmer is direct. The programmer must understand the business requirement to design a technical solution.
  • For complex systems, some level of overall design, beyond any specific function, is necessary. In XP projects, the overall design is considered during regular refactoring — namely, using the process of systematically improving the code to enhance readability, reduce complexity, improve maintainability, and ensure extensibility across the entire code base.

You may find extreme programming combined with lean or scrum because the process elements are so similar that they marry well.

Getting to know some extreme programming practices

In XP, some practices are similar to other agile approaches, but others aren’t. This table lists a few key XP practices, most of which are commonsense practices and many of which are reflected in agile principles.

Key Practices of Extreme Programming
XP Practice Underpinning Assumption
Planning game All members of the team should participate in planning. No disconnect exists between business and technical people.
Whole team The customer needs to be collocated (physically located together) with the development team and be available. This accessibility enables the team to ask more minor questions, quickly get answers, and ultimately deliver a product more aligned with customer expectations.
Coding standards Use coding standards to empower developers to make decisions and to maintain consistency throughout the product; don’t constantly reinvent the basics of how to develop products in your organization. Standard code identifiers and naming conventions are two examples of coding standards.
System metaphor When describing how the system works, use an implied comparison, a simple story that is easily understood (for instance, “the system is like cooking a meal”). This provides additional context that the team can fall back on in all product discovery activities and discussions.
Collective code ownership The entire team is responsible for the quality of code. Shared ownership and accountability bring about the best designs and highest quality. Any engineer can modify another engineer’s code to enable progress to continue.
Sustainable pace Overworked people are not effective. Too much work leads to mistakes, which leads to more work, which leads to more mistakes. Avoid working more than 40 hours per week for an extended period of time.
Pair programming Two people work together on a programming task. One person is strategic (the driver), and one person is tactical (the navigator). They explain their approach to each other. No piece of code is understood by only one person. Defects can more easily be found and fixed before merging and integrating code with the system.
Design improvement Continuously improve design by refactoring code — removing duplications and inefficiencies within the code. A lean code base is simpler to maintain and operates more efficiently.
Simple design The simpler the design, the lower the cost to change the software code.
Test-driven development (TDD) Write automated customer acceptance and unit tests before you code anything. Write a test, run it, and watch it fail. Then write just enough code to make the test pass, refactoring until it does (red-green-clean). Test your success before you claim progress.
Continuous integration Team members should be working from the latest code. Integrate code components across the development team as often as possible to identify issues and take corrective action before problems build on each other.
Small releases Release value to the customer as often as possible. Some organizations release daily. Avoid building up large stores of unreleased code requiring extensive risky regression and integration efforts. Get feedback from your customer as early as possible, as often as possible.

Extreme programming intentionally pushes the limits of development customs by dramatically increasing the intensity of best practice rituals, which has resulted in a strong track record of XP improving development efficiency and success.