The Practices

The 12 practices in XP are as follows :

• Test-driven development (via unit tests and customer tests, aka acceptance tests)

• The planning game

• Whole team (was on-site customer)

• Small releases

• Metaphor

• Simple design

• Refactor mercilessly

• Collective ownership

• Pair programming

• Continuous integration

• Sustainable pace

• Coding standards

The list changes occasionally; for example, 40- hour week was renamed to sustainable pace so that it would make sense in work cultures outside the United States. These pages are probably the best places to check for the most up-to-date version of the list: http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices and http://www. xprogramming .com/xpmag/whatisxp.htm.

An important XP practice that didn t make it into the official list of 12 is emergent design.

We discuss emergent architecture and design in Chapter 12.

 

Another XP practice that wasn t on Kent Beck s original list but has since become central to XP (in the form of the whole team practice), is that of colocating teams ”that is, the entire team (programmers, coach, customer, and so on) must be able to squeeze into one room.

We discuss how colocated teams affect scalability in the section When XP Starts to Fail, in Chapter 14.

 

Test-Driven Development

This practice is a combination of the practice of testing the code and the design (unit testing) and the practice of testing that all the requirements have been implemented (acceptance testing). Unit tests (aka programmer tests ) are always written by the programmers, and acceptance tests (also known as functional tests and customer tests ) are, if possible, written by the customer.

XP takes a test-first approach to programming. That is, for each class (or task), you first write the unit tests, run them, see that they fail, and then write the code that s necessary to prevent the unit tests from failing.

An increased emphasis on unit testing and on the use of automated testing tools is probably the most useful benefit to have emerged from the XP phenomenon . In fact, test-driven development (aka test-first design) is beginning to take on a life of its own that s increasingly distinct from XP. ^[4] Unit testing has been around far longer than XP, of course, but there s no doubt that the Extremos have raised consciousness across the industry about the importance of this practice, and they deserve credit for this.

The Planning Game

Planning in XP involves eliciting the right decisions from the right people. Businesspeople need to decide about scope, priority, what each release will consist of, and the release dates. Technical people need to decide about estimates, consequences, process, and detailed scheduling.

The planning game involves breaking the project into very short 1- to 3-week iterations and taking the project one iteration at a time. For each iteration, the customer needs to decide which user stories to include and which to leave until a future iteration.

Any piece of work that takes time is written up as a user story and assigned its own little piece of cardboard (the story card ). User stories must be testable and estimable . In addition, every user story must provide business value to the customer (i.e., design details wouldn t be written as user stories).

Each story represents a week or two of work. To make work allocation and estimating easier, each story is broken down into smaller tasks that the programmers sign up for, where each task represents a day or two of work.

The story cards themselves shouldn t contain much detail: They re really placeholders for conversations or promises for future conversations with the customer.

If the customer (or higher management) requests some documentation, it s assigned as a user story, and a cost estimate is attached. Changes in requirements are handled in a similar way. Every change is given an assigned cost. For any iteration, to schedule a change the customer must remove some other change of equal cost.

As the project progresses, estimating of user stories, in theory, becomes more accurate. The rate of user stories completed per fixed iteration is known as the project velocity. A key goal in an XP project is to maintain a consistent ( therefore predictable) velocity.

As we ll see in Chapter 11, some Extremos regard constant velocity as more important than deadlines.

 

Whole Team (Was On-site Customer)

From Extreme Programming Explained :

A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities. By ˜real customer I mean someone who will really use the system when it is in production. ^[5]

The definition of an XP customer has actually changed since the preceding quote was published in 2000. The new-testament definition is that the XP customer is simply a representative of the real customer. If you can get the real thing, then so much the better; otherwise , a proxy will do.

The following quote is from XP author Michael Feathers:

Some larger teams doing XP have teams of customers. The important thing isn t so much that there is a single customer, but that the ˜customer speaks with one voice. ^{[6 ]}

This is an important aspect of the XP customer (in fact, of any customer in any project). The customer must speak with one voice ”that is, the programmers must receive clear, unambiguous, nonconflicting instructions on what to create.

The Feathers quote also indicates that the concept of the customer role has evolved still further, that the customer may be an entire team. In his foreword to Pete McBreen s Questioning Extreme Programming , Kent Beck writes :

I will suggest that as you read this, you keep in mind one mistake of early XP thinking for which I am entirely responsible ” ˜the customer doesn t mean one person. It means a team, as big or bigger than the development team. ^[7]

Beck doesn t specify whether the customer team should be in the same room as the development team. This raises some questions about how the XP customer can still speak with a single voice. If they re colocated in the same room, it would be rather difficult to mandate that only one of them ever speaks to the developers. The rest must surely be gagged!

Small Releases

Back to Extreme Programming Explained :

Put a simple system into production quickly, then release new versions on a very short cycle. ^[8]

Although this approach does have advantages, there are also certain risks that must be contained (these are discussed later). In fact, we ve noticed a small caveat being added onto this practice more recently: The (typical) 2-week iteration doesn t necessarily result in a production release (i.e., a program that will be used in a live system by real users). It may instead simply be a small release aimed at the internal customer, primarily to gain early feedback and hopefully find any defects that need to be corrected.

Also from Extreme Programming Explained :

It is far better to plan a month or two at a time than six months or a year at a time. A company shipping bulky software to customers might not be able to release this often. They should still reduce their cycle as much as possible. ^[9]

The theory behind small releases is that valuable functionality is placed into the user s hands as soon as possible and that the system never gets too far removed from what the customer really wants. That is, if users are going to say, Yes, but that s not really what I wanted. . . . when they see the finished software, they get to say this after a couple of weeks of development work has gone by, not after a couple of years . This ties in with XP s feedback value.

System Metaphor

In XP, the software architecture is complemented with a single unifying metaphor. The system metaphor is a simple shared story of how the system works. All naming and design theories stem from that one story. For example, the system is a bakery, therefore we have ovens, bakers, trays, shop counters, tins, and so forth.

Similarly, a contract management system would be spoken of in terms of contracts, customers, and endorsements, and an online e-commerce system would be described in terms of products, a shopping cart, and a checkout procedure.

The system metaphor is often a bone of contention because it s seen as a direct replacement for a system architecture. Usually this confusion arises because vanilla XP projects don t produce a documented architecture model; thus, source code written to a particular common metaphor is about the closest they get. In reality, however, it s the system metaphor and all the other design activities that replace the documented architecture.

Simple Design

A simple design is quicker to code and easier to maintain than a complex design.

In XP, a driving design maxim is Always do the simplest thing that could possibly work. This means not designing or coding for something that won t be included in the current iteration. This philosophy of coding for today gets taken to, well . . . extremes in XP.

Emergent Design

As we mentioned earlier, a fundamental XP practice, which didn t make it into the original list of 12 practices but was added later, is emergent design , the concept of growing a design as your understanding of the problem (and best solution) evolves. Emergent design is discussed in an article by Ron Jeffries on his Web site ( http://www.xprogramming.com ). It could be thought of as a combination of refactoring, test-driven development, simple design, and metaphor, and of the XP designing activity.

We discuss emergent design in Chapter 12.

 

Refactoring

Refactoring is the practice of improving the design of existing code. XP advises that you strive for simple designs. Therefore, refactoring in XP means looking for ways to simplify the design of existing code while still running all of the tests. And, because XP eliminates up-front design before coding (aka big design up front [BDUF]) you ve always got plenty of code that needs improving. We like to call this Constant Refactoring After Programming.

XP does recommend that you only refactor code that really needs it (e.g., where there is duplicated code). The way that XP recommends you identify such code is to look out for code smells ” parts of the code that have become crufty and need to be improved.

Although the code is existing, it might have been written only a few seconds ago. The theory is that refactoring is a constant and integral part of programming. By continuously thinking about how to simplify your code (and of course doing it), you theoretically end up with a better code-level design (or, in Extremo jargon, better smelling code ).

More on refactoring in Chapter 9.

 

Collective Ownership

Everyone is responsible for the entire code base. If a programmer sees something she doesn t like about any piece of code in the project, she (and her pair-programming buddy) can go in and change it.

Although XP has collective code ownership, it has individual task ownership. ^[10] This means that each programmer signs up for tasks at the start of each iteration and is responsible for completing that task by the end of the iteration. Usually, a programmer will sign up for tasks that interest him or that fall under his own core skill set (e.g., an SQL expert will most likely sign up for those tasks that involve writing SQL). However, as we ll see shortly, programmers in XP are required to rotate around frequently.

We discuss collective ownership in the What If Programmers Take Ownership of Code? section in Chapter 3.

 

Pair Programming

You can code on your own for nonproduction code ^[11] such as prototypes . For all production code, though, XP recommends that everyone on the team program in pairs. Pairing up is an effective way of catching errors and helping each other to identify ways of further simplifying the code.

To keep pairs from becoming stale, and to facilitate collective ownership, XP encourages people to move around and switch partners frequently. This pair promiscuity (more commonly known as pair rotation ) is intended to prevent knowledge bottlenecks from appearing. A common situation is where only one person knows about one part of the system, hence that person becomes virtually indispensable . If that person isn t around, then a bug in her niche area simply can t be fixed (at least not satisfactorily).

When people are allowed to choose their own pairs, they ll usually choose to work on parts of the project that interest them most or that they re most suited to. If you like to write stored procedures, then whenever a user story comes up involving a stored procedure task, chances are pretty good that you ll choose to work on it. Hence, pair promiscuity shouldn t necessarily lead to problems where someone is doing something he doesn t want to (except maybe pair programming).

The XP literature is quite clear that pair programming is mandatory for all production code. That is confirmed online by XP author Robert C. Martin:

The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and comfort do not supercede the delivery of quality to the project, or your parcitipation [sic] in the team. ^[12]

Alternatively, you could take XP author Ron Jeffries advice:

XP says that ˜all production code is written by two people sitting together at one machine . That s the rule. As far as I know, no project has ever done that, including many that I consider to deserve the name XP. So what s the rule about? It s an ideal. It s what we strive for. It is a stretch goal. ^[13]

Elsewhere, to confuse us even more, Ron also says:

The definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time. ^[14]

Whichever XP author s advice (Ron s or his evil twin s) you choose to follow, if you strive for pair programming, then you might find that the pairing up mindset becomes habitual: Extreme Programming Explained even recommends pair integrating.

We discuss pair programming further in Chapter 6.

In Chapter 13, a practicing (though skeptical) XPer describes a project in which pair progress-bar watching was mandatory for all.

 

Continuous Integration

Code is integrated and tested after a few hours ”a day of development at most. If by the end of the day your code isn t yet working, you re encouraged to toss it away, go home clean, and start afresh the following morning.

As mentioned previously, pair programming can lead to habitual pairing in other aspects of XP, including pair integrating:

When the machine is free, a pair with code to integrate sits down, loads the current release, loads their changes (checking for and resolving any collisions), and runs the tests until they pass (100% correct). ^[15]

 

Sustainable Pace

The more tired a programmer is, the more mistakes she ll make. Programmers who code through the night, fired up on free pizza and too much Dr Pepper, might think they re doing the company a favor, but in reality they re creating negative work ”doing more harm than good. The bugs that they re inevitably introducing, in their barely awake daze as they stare bleary-eyed at the flickering screen, will probably take a lot longer to track down and fix than any time they gained , assuming they actually managed to produce any useable code at all between midnight and 5:00 AM.

The upshot is that a 40-hour week (as this practice used to be known) is quite a good thing, really. Sustainable pace will result in higher productivity levels in the long run than making frequent mad dashes that quickly burn out your programmers.

Coding Standards

Coding standards are important in any programming project, and more so in an XP project, because any pair of programmers can change any part of the code at any time.

Coding standards also help a lot in making your code clearer, as in easier to read and decipher. Encouraging programmers to give their variables and methods meaningful names helps to make your code self-documenting . For example, call a method calculateTaxGains() rather than multiplyAWithB(), or even worse mltVals(). This in turn means that your code needs fewer (if any) comments. In fact, the presence of code comments (according to Extremo theory) should be taken as a signal that the code could be made clearer.

^[4] See http://www.objectmentor.com/writeUps/TestDrivenDevelopment and Kent Beck, Test-Driven Development: By Example (New York, NY: Addison-Wesley, 2002).

^[5] Beck, Extreme Programming Explained, op. cit., p. 60.

^{[6 ]} Michael Feathers posting to the newsgroup comp.software.extreme-programming, subject: Re: On-site Customer Liaison; was The Case against XP, December 29, 2001.

^[7] Pete McBreen, Questioning Extreme Programming (New York, NY: Addison-Wesley, 2002), p. xvi.

^[8] Beck, Extreme Programming Explained, op. cit., p. 54.

^[9] Beck, Extreme Programming Explained, op. cit., p. 56.

^[10] See http://www.jera.com/techinfo/xpfaq.html .

^[11] In this book we use production code to mean source code that s being targeted for delivery to be used in a live system (as opposed to, say, prototype or spike code, which would be used for exploration and experimentation and then thrown away).

^[12] Robert C. Martin posting to the newsgroup comp.object, subject: Re: Pair Programming ” Yuck! October 28, 2001.

^[13] Ron Jeffries, Misconceptions About XP, http://www.xprogramming.com/xpmag/Misconceptions.htm, January 21, 2002.

^[14] See http://www.c2.com/cgi/wiki?IfXpIsntWorkingYoureNotDoingXp.

^[15] Beck, Extreme Programming Explained, op. cit., p. 59.