Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes -- turning them all up to "10" (or "11" for Spinal Tap fans). See Kent Beck's introduction to Extreme Programming Explained for more details.
Absolutely nothing. In February 2001, Microsoft announced that the next release of their consumer Windows operating system would be called "Windows XP". The use of "XP" as shorthand for Extreme Programming predates Microsoft's use of "XP" by 2-3 years.
No and yes. No, it's not a methodology in the sense of a lot of paperwork and additional hoops for developers to jump through. But yes, in the sense that it is a repeatable process for developing software, it is in fact a methodology, although a lightweight one.
Alistair Cockburn, who studies methodologies for a living, characterizes XP as a lightweight, low-ceremony, high-discipline methodology.
XP was originated by Kent Beck, based on his years of practice as an O-O software developer, and in particular, his work with Ward Cunningham using the Smalltalk programming language. Because Smalltalk was the first popular O-O language, Ward and Kent have been doing object-oriented programming longer than just about anyone else.
The 12 core practices of XP are:
The first thing you'd notice is that all the programmers are in a room together, usually sitting around a large table in the middle of the room. The programmers may have desks or offices nearby, but you can tell by the piles of books are piled that the big table is where the action is.
XP teams work in a series of fixed iteration cycles. Iterations typically last 1, 2 or 3 weeks each depending on the team. (A given team will almost always use same the iteration size for every iteration.)
At the beginning of each iteration, the team gets together with the customer for a planning meeting. In that meeting, they go over the features the customer wants done in that iteration, breaking each feature down into individual engineering tasks. Individual developers then sign up for specific tasks, and estimate those tasks. No developer is allowed to sign up for more work in the coming iteration than he completed in the previous iteration.
During the rest of the iteration, the team will implement the features they signed up for, pair programming on all production code. All code is written test-first -- that is, the developers don't write any code until they have a failing test case. The developers write unit tests to test individual classes and subsystems. The customer provides functional or acceptance tests to validate the features that the programmers are developing.
At the end of the iteration (usually on a Friday), the programmers deliver a working system to the customer. The system may not be complete, but all functionality that is implemented works completely, without bugs. The customer accepts delivery, and the team goes home early. The next Monday everyone meets again to plan the next iteration, and the cycle repeats itself.
Actual product release is almost a non-event. The customer takes delivered system from some iteration, and distributes it to the end users. The system is always very nearly defect-free, so the only question is when the developers have added enough functionality to make it worthwhile for the end users to upgrade.
Easily up to a dozen programmers. Up to twice that with some difficulty. Beyond that, you'll need something else, either augmenting XP with more traditional heavyweight practices, or splitting the project among two or more regular XP teams, with some teams becoming customers for other teams.
XP is a development process; UML is a design notation. Most XPers are fluent in UML, and periodically draw UML diagrams on marker boards to work out design issues. Most XP projects don't have reams of printed UML diagrams, although there may be a brief design overview document that contains a few simple diagrams to show canonical class relationships in the system.
The Rational Unified Process, or RUP, is a customizable "one size fits all process". It defines lots of roles, processes and documents, but essentially all of them are optional. Robert C. Martin has made a pretty good case that XP is in fact a minimal instance of RUP.
General consensus on the XP mailing list is that XP is close to the spirit of CMM. However, real-world CMM practitioners tend to place a much higher emphasis on ceremonial meetings and paper documentation than XPers do, so it's unclear if an XP shop would receive a high CMM rating.
"You aren't gonna need it," a general refrain when someone suggests building functionality for the system that isn't required by any current user story. For example:
Programmer 1: "It says here we need to save the default number of widgets between sessions. I'd better write a generalized object persistence mechanism."
Programmer 2: "YAGNI. Just write out a one-line text file for now. If we need more later, we'll add it later."
This is something an XP coach will say when he sees an XP developer doing something that is needlessly complicated. In general, XP says don't overdesign your system....
XP actually has a very specific definition of "simplest" (based on the list in Extreme Programming Explained, p.109):
Once and only once is just shorthand for the first two items in the XP definition of "simplest". (1) says you need to say everything that needs to be said once. (2) says you need to say it only once, avoiding duplication.
There's a fairly extensive XP glossary available at http://c2.com/cgi/wiki?XpGlossary. This is part of Ward Cunningham's amazing Wiki system.
Don't let the lack of paperwork and meetings fool you. Unless you're at least a CMM level 3 shop, XP is likely more disciplined than the way you produce software today. Some examples of that discipline:
It turns out that two programmers working as a pair are more than twice as productive as a single programmer working alone, and also produce higher quality code. The big gain is not, as you might think, in avoiding little syntax errors, but rather in avoiding the big picture errors -- the ones where you blow an entire afternoon barking up the wrong tree.
Laurie Williams has done empirical studies of pair programming. Her work is summarized in the paper The Costs and Benefits of Pair Programming, which she co-wrote with Alistair Cockburn. In this study, after only a few pairing sessions, pairs of programmers were roughly as twice as productive as solo programmers, yet produced substantially fewer defects.
XP has collective code ownership, but individual task ownership. Each developer signs up for tasks at the beginning of each iteration. He is then responsible for completing those tasks by pairing with another developer. At the end of each iteration, the customer decides if the task is complete or not. After a year, you'll have a long list of completed tasks to show your manager.
Pair programming means two people working side-by-side on the same problem on the same computer; if someone is looking over your shoulder, you're doing it wrong. Typically, the person "driving" the keyboard and mouse will be focused primarily on tactical issues in coding the current method, while the non-driver will focus more on strategic issues, like how the method fits into the system, and is it needed at all in the first places. It's kind of like a road rally, where a driver and a navigator collaborate to get over a given course in the best time.
Pair programming appears to access another kind of flow, which is shared between the two people pairing. There's some talking, but not a lot of idle chitchat, and and it's easier to return to the state if someone interrupts you.
It's true that computation theory pretty much proves you can't validate every possible state of a non-trivial system. However, in practice, an experience programmer can produce a pretty good set of tests that will result in a high degree of confidence that the system is working correctly.
It's sort of like those probabilistic tests used to produce large prime numbers for public-key cryptography. You can't tell for certain that a number is prime without trying to factor it, but you can apply a number of simpler tests that will verify its primeness to any degree of certainty that you want.
Simple design, practiced alone typically would have this result. But XP says that after you do the simplest thing that could possibly work, you go back and refactor your code until everything your code needs to express appears once and only once within the code base.
General experience in the XP community is an unqualified "no". At the very worst, it may happen, but so rarely that your wins from all the other YAGNIs will more than pay for having to backtrack once in a while.
Many of the practices work well in isolation, so it's quite possible you'd be better off using the ones you feel like than none at all. However there's a synergistic effect to using all of them together that you'll be missing out on. As a result, a lot of people in the XP community feel strongly that if you're not using all 12 practices, you're not doing XP.
As a practical matter, there's currently no XP certification authority. You can do whatever you want, and no XP Gestapo is going to kick in your door. But if you're not using all 12 practices, you probably could be going faster.
The best place to start is currently Kent Beck's book "Extreme Programming Explained: Embracing Change", (available from Amazon.com among other places). This book is essentially the definitive guide to XP at the moment, and a fairly quick read.
Once you have an overview of XP, visit Ward Cunningham's Wiki Wiki Web (or Wiki for short). Wiki is a simple, yet powerful hypertext system. Anyone can add or modify any page on Wiki, so the system collects the knowledge of thousands of people into a (semi) coherent whole. Started as a system for cataloging Design Patterns, Wiki has grown to include literally hundreds of pages related to XP. A good starting point is http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap.
There's also a lively XP mailing list on Yahoo Groups (formerly eGroups). To subscribe, send a blank email to extremeprogramming-subscribe@yahoogroups.com. Or see the archives on the web at http://groups.yahoo.com/group/extremeprogramming.
XP FAQ © 2001 John Brewer
Send updates & suggestions to xpfaq@jera.com