Imagine a team approach to programming, in which there are few surprises, changes are easily incorporated, and tested code rolls out in scheduled increments. That's the goal of Extreme Programming (XP).

What Is XP?

Extreme Programming defines a way of bringing customers and programmers together in a tightly integrated team with working conditions that promote communication and problem solving. Kent Beck created this development methodology in 1996. XP requires collaboration, communication, and discipline. Because of the intense interaction, XP works best for small- to medium-size teams, with the sweet spot at around 15 members. On larger projects, several smaller teams may be federated, with members moving among as well as within teams.

Extreme Programming breaks development into bite-size chunks and relies on daily face-to-face team communication and lots of testing; the assumption that specifications will change is built into the process. Projects are developed in increments, with just enough code written to implement the required functions, and everything (the design, the features, and the code) is constantly evaluated and adjusted to accomplish the desired result.

Formally, XP comprises 12 core practices (see the sidebar). In the planning game, the customer writes simple usage scenarios on 3-by-5 index cards. Without a complex, wordy specification document, this low-tech technique leads to face-to-face communication with the programming team. Keeping the written word to a minimum maintains discussion at a maximum. The customer remains on site to interact with developers, so design changes can happen quickly.

Discussions include estimates of the time and resources required to complete each feature. Timing is based on short iterations, usually one to three weeks, during which a small but functional portion of the project completes. Each iteration includes design, coding, testing, and release, and each release is then integrated with the previous ones. Because the project is built in small but functional steps, the final release is actually a non-event. The application or system is complete when it has enough functionality to be useful or saleable to clients.

Programmers work in pairs on a single workstation, with one person writing code and the other watching the big picture. Pair programming generates a lot of discussion, and programmers switch seats periodically. Old-timers claim this is inefficient, but pair programming may actually be more productive than two people working separately; there is less chance of getting sidetracked when a partner is waiting. All code is written to agreed-upon standards. At the outset, the developers agree on a system metaphor, a standard way to name classes and methods, and a standard architecture that facilitates reuse and understanding of the code by the team. With increased communication and openness, standards are better enforced. Programmers change partners periodically as well and work on all aspects of the project, giving the entire group ownership of the code. Typically, all members of the teamdevelopers and clients alikework in an open room.

Testing is ongoing and has two basic levels. Unit tests, written by programmers, exercise production code on a class or module basis. Acceptance tests, derived from the customer scenarios, check that feature implementations are correct. All code has an associated test, and new tests are added to the old ones in a testing framework, creating a comprehensive test suite. Programmers constantly "refactor" the code, removing duplication and optimizing the design. This, combined with the test suite, lets programmers avoid classic "fix one thing, break another" bugs.

The XP team strives to maintain a 40-hour work week, avoiding the excessive overtime that causes sloppy work and breaks down morale. The status of an XP project is always known, so the team can plan better and work at a sustained pace in the long term.

For helpful links, read "Extreme Programming Resources,".

Concerns

Just about everything new is controversial at first, particularly with techniques that require 180-degree shifts in perspective. And that's pretty much what XP calls for. Joshua Kerievsky, president of Industrial Logic, an Extreme Programming mentoring firm, says the most important step in evaluating the potential success of an XP project is determining whether the developers and client can handle the necessary sea change. He notes that for many companies, the changes are too great. Open environments strip away individual status symbols like offices, and group code ownership can bruise a guru's ego.

Critics of Extreme Programming say that it merely incorporates best practices that have been around for years. That may be true, but what makes the process Extreme is that all the best practices are used all the time. XP's promisewell-desgined and well-tested code, delivered on time and on budgetmeans it's an approach worth considering.

Get Our Best Stories!

This newsletter may contain advertising, deals, or affiliate links. Subscribing to a newsletter indicates your consent to our Terms of Use and Privacy Policy. You may unsubscribe from the newsletters at any time.