Extreme Programming FAQ
Italicized links are book titles. Click to order from Amazon.com. Example: Extreme Programming Explained.
Introduction
What is Extreme Programming? Does it involve bungee cords?
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.
What does this have to do with Windows XP?
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.
Is XP a methodology?
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.
Where did XP come from?
XP was originated by Kent Beck, based on his years of practice as an object-oriented software developer, and in particular, his work with Ward Cunningham using the Smalltalk programming language. Because Smalltalk was the first popular object-oriented language, Ward and Kent have been doing object-oriented programming longer than just about anyone else.
What are the basic practices of XP?
The 12 core practices of XP are:
The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit.
Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
What does a typical extreme programming project look like?
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 where the 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 the delivered system from some iteration, and distributes it to 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.
How big a project will XP work with?
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 the customers for other teams.
How does XP compare to UML?
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.
How does XP compare to RUP?
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.
How does XP compare to CMM?
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.
How does XP compare to other lightweight processes, like Scrum, and FDD?
Scrum is a lightweight process that is philosophically very close XP. Scrum focuses more effort removing impediments, with daily stand-up meetings where programmers list any outside issues that are impeding progress, and a Scrum Master who is tasked with removing those impediments.
Peter Coad's Feature Driven Development is an iterative lightweight process, but is much more hierarchical than XP, with a chief programmer, who directs class owners, who direct feature teams.
For an in-depth comparison of various lightweight processes, see Martin Fowler's paper The New Methodology.
What does YAGNI mean?
"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."
What does ''Do the simplest thing that could possibly work.'' (DTSTTCPW) mean?
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....
How can you know one approach is simpler than another?
XP actually has a very specific definition of "simplest" (based on the list in Extreme Programming Explained, p.109):
The system (code plus tests) clearly communicates everything that needs to be communicated at the current instant in its development. This means that it runs every existing test, and that the source code clearly reveals the intention behind it to anyone who reads it.
The system contains no duplicate code, unless that would violate (1).
The system contains the minimum number of classes possible without violating (1) or (2).
The system contains the minimum number of methods possible, consistent with (1) (2) and (3).
What does "Once and Only Once" (OAOO) mean?
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.
Where can I get a more complete glossary of XP terms?
There's an extensive glossary of XP terms and acronyms available at http://c2.com/cgi/wiki?XpGlossary. This is part of Ward Cunningham's amazing Wiki system.
Common Objections
Isn't XP just undisciplined "hacking" or "cowboy coding"?
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:
XPers won't write any functionality that doesn't fulfill a specific, explicit customer need.
XPers won't write any code without first writing a failing test
XPers write all production code in pairs.
XPers deliver a fully functional (albeit possibly feature limited) system at the end of each 1-3 week iteration.
Won't pair programming cut productivity in half?
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.
With pair programming and collective code ownership, how are programmers supposed to be recognized and compensated?
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 one or more other developers). At the end of each iteration, the customer decides if the task is complete or not. After a year of doing this, the programmer has a long list of completed tasks to show his manager.
Isn't it annoying having someone looking over your shoulder while you program?
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.
Won't pair programming interfere with "flow", which requires solitude and silence?
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.
Why just pair programming? Why not 3 or 4 or 100 programmers?
There's a communications overhead for each additional programmer you add, and it grows nonlinearly. With 2 programmers, there's 1 communication path. With 3 programmers there are 3 paths, with 4, there are 6, and so on. Pairing is just the sweet spot where you get the benefits of additional minds looking at the problem, but before the communications overhead cost gets too high.
As a practical matter, when a pair is facing a particularly tough or puzzling task, they often will call in one or more additional people for help, effectively producing a temporary trio or even quad programming situation.
How can you possibly test everything? Don't you get a combinatorial explosion?
It's true that computation theory pretty much proves you can't validate every possible state of a nontrivial system. However, in practice, an experienced 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.
Won't simple design leave you with a program that won't scale well?
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.
Won't YAGNI lead you to design dead-ends down the road?
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. As Paul B. MacCready, designer of the Gossamer Condor, says, "Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true, will give you ridiculous resources to apply to the other 2%."
I don't think I [want to do/can sell my bosses on doing] all of the practices. Can I leave some out and still be doing XP?
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.
Learning More
Where can I learn more about XP?
The best place to start is currently Kent Beck's book Extreme Programming Explained: Embracing Change. 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.
XP FAQ © 2001 John Brewer
Send updates & suggestions to xpfaq@jera.com