The first time I heard the phrase Extreme Programming, I had visions of all-night coding sessions with cans of Jolt cola and Mountain Dew strewn about. Far from it, Extreme Programming (XP), the latest craze in software construction methodologies, actually advocates a 40-hour workweek. The term “extreme” comes from XP’s radical departure from the complex, time-consuming techniques of well-known and long-accepted methodologies.

Consider this quote from one of Kent Beck’s XP converts: “XP matches observations of programmers in the wild.” (Beck is the author of Xtreme Programming Xplained—Embrace Change.) So yes, XP is radical, and the best way that I can describe XP is to list its practices and then summarize XP’s project cycle.

XP Practices

• Planning—Determine the scope of the next release by combining business priorities with technical estimates made by coders.

• Small releases—Use iterative development where each release is delivered in one to three weeks.

• Metaphor—Start with a simple, shared story of how the system is to work.

• Simple design—Follow the doctrine of, as Beck says, “extracomplexity removed as soon as it is discovered,” but strive not to use complex designs in the first place.

• Testing—Have coders write unit tests for all methods and customers write functional tests for the application.

• Refactoring—Continually strive to remove duplicate code and find ways to simplify code while adding flexibility—i.e., “do over.”

• Pair-programming—All production code is done by two coders sharing one workstation.

• Collective ownership—Allow anyone to be able to change any code anywhere in the system at any time.

• Continuous integration—Build and completely test the system several times a day.

• 40-hour week—It is an absolute rule that you can’t go over 40 hours two weeks in a row.

• On-site customer—Have a user expert on the team full time to develop functional tests and provide continuous feedback.

• Coding standards—Because everyone owns all the code of the system, it must all look the same throughout the system.

XP Project Cycle

An XP project seeks to deliver the system every one to three weeks. The idea is to drop grandiose design schemes and replace them with a simple story of the system that everyone understands and agrees on. The project starts with the most basic of the requirements for thesystems. The design is done using the simple strategy of 3 x 5 Class-Responsibility- Collaborator (CRC) cards. (To get a better idea how CRC cards are used to design object- oriented systems, read c2.com/doc/oopsla89/paper.html.) After the “hyper” design phase is done, coders select 3 x 5 cards, estimate the amount of time to deliver, select a partner, and begin coding. One coder is the driver, and the other is the planner. The driver fleshes out the code for the task, and the planner looks for coding errors while planning how to test the code and improve the overall design.

Pair Programming

This pair programming goes against common coding practices, and my first thought about it was that it would result in less code. But studies have shown that pair programming always results in cleaner and more concise code. Quality code means fewer bugs and, after coders become comfortable with pair programming, output catches up with “cave coding” anyway.

One of the immediate benefits of pair programming is continuous code reviews. I’ve always been an advocate of code reviews, but, because they burn up lots of time and resources, code reviews are often skipped. With XP, code reviews go on constantly (because you always work in pairs), and therefore are extremely effective.

Testing and Collective Ownership

Testing is the name of the game with XP. Coders become “test infected” because they won’t add a feature unless they can test that feature. Unit tests provide instant gratification while establishing coder confidence. The XP team customer is responsible for adding functional tests as features are added to the systems.

As a coding pair completes a task, it integrates its code to the system. At this point, the coding pair not only tests its new code but also runs the automated tests for the entire system. If any test fails, the coding pair is to fix any code that fails—even if it didn’t code it. That’s called collective ownership—all the coders are responsible for all the code in the system.

Iterative Development

After a one- to three-week phase is complete, the system is delivered to the customer. Feedback is instantaneous, and a subsequent project cycle begins. Features are added and designs are changed. In other words, the scope of the project evolves after each iteration.

Is XP for You?

Should you be using XP? First, remember that XP is a radical new methodology. Your company’s coders and management must be willing to try a completely new way of designing, coding, and delivering systems. XP’s use of numerous releases and continual evolution of a project may not work in your business environment. Note, too, that XP works best for small projects, ones with two to 10 coders. And last, XP is dependant on modular programming, if not object-oriented programming. The continual integration and system testing of XP require a programming language that supports fast builds and automated unit tests. XP success stories were built using C++, Java, and Smalltalk.