The Activities

The four basic activities within XP are as follows :

• Coding

• Testing

• Listening

• Designing

Kent Beck, author of Extreme Programming Explained , posits that these four activities are all there is to software development:

L istening , T esting, C oding, D esigning. Thats all there is to software. Anyone who tells you different is selling something. ^[16]

This is a rather minimalist way of looking at software development, and it also sets the tone for the my way or the highway rhetoric that surrounds XP. Is it really all there is to it, though? We revisit this quote in the final chapter.

Coding

Without code, we dont have a program, so its a fair assumption that a software project will involve coding at some stage. In XP, the stage is pretty much the entire project.

Testing

Write the test, then write the code. Keep changing the code until the test passes . Rinse and repeat until all the tests are written and pass with flying colors.

By placing such a high emphasis on testing (particularly when refactoring the design), XP ensures that the project always inches forward”it never slips back (although it might be moving forward in a circle).

See Chapters 9 and 13 for some good reasons why we feel XP projects are in danger of inching forward in circles. And see Chapter 2 for a discussion of a project in which the signs suggest that it was doing just that.

 

Of course, the trade-off is also that the project is always inching, never leaping.If you look first, then sometimes its okay to leap.

We discuss the benefits of looking before you leap further in Chapter 12.

 

Samurai Debugging

Doug once worked with a guy who had a technique that he called Samurai debugging (this was back around 1981/1982). When you follow the Samurai debugging technique, you start with a blank screen. Thats not what you want, so you start debugging it, and you continue debugging until your program does exactly what you want it to do.

Its similar to Michelangelos All you do is start with a block of marble and chip away everything that doesnt look like David, but its also not so unlike XP today.

 

Listening

The customer tells the programmer what he wants the system to do; the programmer writes the system. Because its human nature to base our interpretations on our own prior experience, everyone will hear the customers requirements slightly differently (we expect this to get especially interesting now that XP has changed the definition of customer from a single customer to a customer team). To get past this, programmers must try to put their preconceptions to one side and listen to what the businesspeople are really telling them. Its more difficult than it sounds, but its worth persevering with.

Also see the ListeningWithout Preconceptions sidebar in Chapter 10.

 

Its worth noting that there has never been an instance in recorded history of a programmer hearing what was most convenient to code. Therefore the silly, archaic practice of writing requirements down in detail can be safely discarded.

Designing

XP involves design. Well, sort of. It doesnt involve design in the traditional sense (plan out your overall architecture, draw lots of lines and boxes, create models, and derive code from models). Instead XP involves a little up-front design (at least 5 to 10 minutes before coding; see Chapter 12), and the rest is sort of an integral part of the day-to-day programming process.

Design in XP mainly involves thinking, how can we simplify this? In other words, its tightly coupled with the practice of constant refactoring. Design in XP is summed up by these two Extremo quotes:

Groucho  

Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal”half an hour should be the most time you spend to do this. After that, the best thing to do is to let the code participate in the design session”move to the machine and start typing in code. ^[17]

You must remember that XP does not recommend that its practitioners leap into code without a specification. Rather XP recommends the use of user stories and CRC cards as the means of specifying the work up front. ^[18]

We discuss letting the code participate in the design and other catchy Zen-like concepts in Chapter 16.

 

The Roles

As defined in Extreme Programming Explained , the basic roles within XP are as follows:

• Programmer

• Tester

• Tracker

• Coach

• Consultant

• Big boss

Notice that the on-site customer isnt included as a role. In Extreme Programming Explained , the on-site customer is actually described as a practice. This more recent description of the on-site customer is also given by Kent Beck:

In XP, the customer side of the team (which is generally around half of the team) accepts responsibility for the scope of the project, including system-level testing. Effective customer sides combine domain experts, testers, analysts, and marketers. Depending on the organization, you might also include customer service representatives, sales engineers , and interaction designers. ^[19]

Remember that all these people must be able to squeeze into a single room (all day, every day) for the whole project! Note that this is considerably more togetherness than in most families. So, breath mints and deodorant are vitally important on an XP project.

See the song Coders Little Helper in Chapter 6 for more about the personal hygiene aspects of XP.

 

The XP Life Cycle

An aspect of XP that many people find compelling is that it has eschewed the traditional waterfall approach to software life cycles. A waterfall project is characterized by the way in which its divided into discrete phases. Each phase provides input into the next phase. The requirements-gathering phase usually involves some rapid prototyping, which helps to avoid the problem of unexpected issues cropping up during design and build, which people normally associate with waterfall projects.

With XP, there are no phases as such. The design evolves in concert with the requirements. The code is developed in concert with the design. Put another way, the requirements drive the code; the code is the design. And it all sort of happens at the same time.

This is normally referred to as evolutionary development, because the code base is being grown, or evolved, rather than being planned, designed in full, and then built. This contrasts with the approach taken by other modern processes, such as Rational Unified Process (RUP), which tend to be iterative and incremental (i.e., the project is broken down into mini-waterfalls, so that theres still at least a significant element of looking before you leap).

With XP, the project is divided into iterations of 1 to 3 weeks, with a deliverable handed to the customer at the end of each iteration (the customer also decides whether each deliverable will be released to the end users).

Each iteration begins with a planning meeting that involves the programmers and the customer. In this meeting, the participants decide what functionality to include and what to leave out for now. The customer describes what she wants (in the form of user stories), and the programmers estimate how long each story will take to implement.

In reality, XP does have waterfall-style micro-phases, but they are very short: The Requirements . Design . Code . Integrate . Test . Deploy life cycle takes place in a single iteration (1 to 3 weeks). The inner phases (Design . Code . Integrate . Test) are repeated several times a day, and the boundaries between designing, coding, and testing are blurred to the extent that theyre almost indistinguishable. In fact, Kent Beck describes the XP life cycle as a waterfall run through a blender .

The requirements phase in XP is referred to as exploration. The purpose of exploration is to identify, prioritize, and estimate requirements. This would typically take place in the first day or two of each iteration:

Exploration takes the place of a written requirements document. The programmers and the customer assemble and discuss the customers needs. The customer writes stories describing these needs. In discussion with the customer, the programmers remove ambiguity from the stories by making sure that they are testable and estimable . Customers make sure that stories are meaningful by ordering them in terms of their business value. ^[20]

The initial set of stories ( handwritten on story cards) wont contain much detail. Theyre roughly equivalent to a set of use case outlines (although user stories differ in that they arent limited to describing a users interaction with the system).

See Chapter 10 for a definition of use cases (and comparison with user stories).

 

Later, in each iteration, the customer writes automated acceptance tests that form the actual detail. This is roughly equivalent to”well, hell, I dont think theres an equivalent to asking the customer to define their requirements in scripted code.

^[16] See http://www.c2.com/cgi/wiki?ExtremeProgramming .

^[17] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 70.

^[18] Robert C. Martin posting to the newsgroup comp.software.extreme-programming, subject: Re: How XP and Microsoft are similar, September 11, 1999.

^[19] Kent Beck posting to the newsgroup comp.software.extreme-programming, subject: The Customer, May 7, 2002.

^[20] James Newkirk and Robert C. Martin, Extreme Programming in Practice (New York, NY: Addison-Wesley, 2001), p. 9.