Extreme Programming

Extreme Programming is a lightweight (or agile) software methodology (or process) that is usually attributed to Kent Beck, Ron Jeffries, and Ward Cunningham [Beck1999; Beck2000; Siddiqi2000]. XP is targeted toward small to medium-sized teams building software in the face of vague and/or rapidly changing requirements. XP teams are expected to be colocated, typically with less than ten members.

The critical assumption underlying XP is that the high cost of change has been (or can be) addressed by technologies such as objects/patterns, relational databases, and information hiding. As a consequence of this assumption, the resulting XP process is intended to be highly dynamic. Beck's book is subtitled Embrace Change, and the XP team deals with requirements changes throughout an iterative life cycle with short loops. The four basic activities in the XP life cycle are coding, testing, listening, and designing. The dynamism is demonstrated via four values: continual communication with the customer and within the team, simplicity by always focusing on the minimalist solution, rapid feedback via unit and functional testing (among other mechanisms), and the courage to deal with problems proactively.

Most of the principles espoused in XP, such as minimalism, simplicity, an evolutionary life cycle, short cycle times, user involvement, good coding standards, and so forth, are commonsense and appropriate practices in any disciplined process. The "extreme" in XP comes from taking commonsense practices to extreme levels, as summarized in Table 42.3. Although some may (improperly) interpret practices such as "focusing on a minimalist solution" as meaning hacking, in reality XP is a highly disciplined process. Simplicity means focusing on the highest-priority, most valuable parts of the system as currently identified rather than designing solutions to problems that are not yet needed and may never be needed as the requirements and operating environment change.

Table 42.3. The "Extreme" in Extreme Programming

Commonsense Practice	XP Extreme	XP Implementation
Code reviews	Review code all the time.	Pair programming
Testing	Test all the time, even by the customers.	Unit testing, functional testing
Design	Make design part of everybody's daily business.	Refactoring
Simplicity	Always leave the system with the simplest design that supports its current functionality.	The simplest thing that could possibly work
Architecture	Everybody will work to refine the architecture all the time.	Metaphor
Integration testing	Integrate and test several times a day.	Continuous integration
Short iterations	Make iterations really, really short seconds and minutes and hours, not weeks and months and years.	Planning game

XP can be summarized by 12 practices. Although many other practices can be considered part of XP, these 12 are the basic set.

1. Planning game Quickly determine the scope of the next release, combining business priorities and technical estimates. The customer decides scope, priority, and dates from a business perspective, while technical people estimate and track progress.

2. Small releases Put a simple system into production quickly. Release new versions on a very short (two-week) cycle.

3. Metaphor Guides all development with a simple, shared story of how the whole system works.

4. Simple design Design as simply as possible at any given moment.

5. Testing Continually write unit tests that must run flawlessly; customers write tests to demonstrate that functions are finished. "Test, then code" means a failed test case is an entry criterion for writing code.

6. Refactoring Restructure the system without changing behavior to remove duplication, improve communication, simplify, or add flexibility.

7. Pair programming All production code is written by two programmers at one machine.

8. Collective ownership Anyone can improve any code anywhere in the system at any time.

9. Continuous integration Integrate and build the system many times a day, every time a task is finished. Continual regression testing means no regressions in functionality as a result of changed requirements.

10. 40-hour week Work no more than 40 hours per week as a rule; never work overtime two weeks in a row.

11. On-site customer A real, live user on the team full-time to answer questions.

12. Coding standards Rules emphasizing communication throughout the code.

The planning game and small releases depend on the customer providing a set of "stories," or short descriptions of features, that characterize the work to be performed in each release. Releases are two weeks apart, and the team and customer must agree on which stories (simple use cases) will be implemented within a two-week period. A pool of stories characterizes the full functionality desired by the customer, but only the subset identified as those features most desired by the customer for the next two-week release are being implemented at any time. New stories can be added to the pool at any time; thus the requirements can be highly volatile. But implementation proceeds in two-week chunks based on the most desired functions currently in the pool; thus the volatility is managed. An on-site customer is needed to support this style of iterative life cycle.

"Metaphor" provides the overarching vision for the project. This could be considered a high-level architecture, but XP emphasizes design while at the same time minimizing design documentation. Some have characterized XP as not allowing documentation outside code [Allen2001], but it is probably more accurate to say that because XP emphasizes continual redesign (via refactoring whenever necessary), there is little value to detailed design documentation and maintainers rarely trust anything other than the code anyway. Design documentation is typically thrown away after the code is written. The only time design documentation is kept is when the customer can no longer come up with any new stories. Then it is time to put the system in mothballs and write a five- to ten-page "mothball tour" of the system. A natural corollary of the emphasis on refactoring is to always implement the simplest solution to satisfy the immediate need. Changes in the requirements are likely to supersede "general solutions" anyway.

Pair programming is one of the more controversial practices in XP because it has resource consequences for the managers who decide whether or not the project will use XP. Although it may appear that pair programming will lead to twice the resources, research has shown that pair programming leads to higher quality and decreased cycle time [Williams+2000]. For a jelled team, the increase in effort may be as little as 15%, while the reduction in cycle time may be 40 50%. For Internet-time environments, the increased speed-to-market may be well worth the increment in effort. Collaboration improves the problem-solving process, and the increase in quality will also have a significant impact on maintenance costs, which appears likely to more than pay for any added resource costs over the total life cycle.

Collective ownership means that anyone can change any piece of code in the system at any time. The XP emphasis on continuous integration, continual regression testing, and pair programming is intended as protection against problems here.

"Test, then code" is the phrase used to express XP's emphasis on testing. It captures the principle that testing should be planned early and test cases developed in parallel with requirements analysis, although the traditional emphasis is on black-box testing. Thinking about testing early in the life cycle is a well-known good software engineering practice, even if too infrequently practiced.

The basic XP management tool is the metric, and the medium of the metric is the "big visible chart." In the XP style, three or four measures are typically all a team can stand at one time, and those should be actively used and visible to the team. "Project velocity," the number of stories of a given size that can be done in an iteration, is one recommended XP metric.

When adopting XP that is, the XP attitude toward process improvement the recommendation is to adopt XP one practice at a time, always addressing the most pressing problem for your team. As one might expect, the XP attitude toward change is that it's "just rules" the team can change the rules at any time as long as they agree on how they will assess the effects of the change. The advocates of XP recognize that XP is an intensely social activity, and not everyone can learn it. Having said this, it must also be recognized that XP is a "system" or "methodology" that demonstrates emergent behavior, and to gain the full benefit of XP, a reasonably complete set of the basic practices is needed.