XP Terminology

XP is often a bone of contention simply because its recommended practices don t always pair up exactly with the practices names . Table 4-1 presents some examples. (If you re interested in tracking down the sources for the following items, many of them are quoted back in Chapter 1.)

Table 4-1: When All You Have Is a Hammer

Xp Rule (Practice, Value, Teaching, Etc.)	Obvious Or Common Interpretation	What It Really Means
The design	A design spec	The code (unit tests)
The architecture	A high-level architecture model	The code (written to a metaphor)
The requirements	A list of requirements	The code (acceptance tests) [14]
Documentation	Text that describes the code	The code ( document primarily by writing clean code and tests)
Testing	Testing	Writing code [15]
The code	Source code	Production code (and tests)
Customer	Customer	Someone who writes code (acceptance tests)
[14] It could be argued that the requirements also include user stories, but user stories are transitory artifacts (i.e., their relevance diminishes once the code has been written). In an XP project, the true test of inclusion of all requirements is the acceptance tests. [15] Writing automated unit tests (code) and acceptance tests (scripted code).

Thus, on the newsgroups in particular, heated arguments tend to spiral ever faster, because those involved are throwing words and phrases at each other but interpreting them completely differently. Here s a little allegory to illustrate the problem:

Ralph: I don t like cooking. Should we buy an oven?

Alice: That doesn t make sense, Ralph! Besides, we already have an oven.

[Lengthy and highly confusing argument rages for almost an hour .]

Ralph: No, I meant microwave oven all along! You know, like the one Norton just bought! I just meant we should buy one so we don t have to do traditional oven cooking.

Alice: Well, I mean, I guess that s okay, Ralph.

Ralph: Of course, by microwave oven I really meant toaster.