XPlorations

XP Programming Activities

A state machine is a traditional way to show a set of activities and the possible transitions between them. We might show XP's programming activities like this:

The triangle in the middle catches a key idea in XP:
    test, then code, then refactor

This is the opposite of traditional programming:
    design, then code, then test

Let's look at the activities one at a time:

Standup Meeting at 9 AM

• This is not an official part of XP.
• Many teams use it to get focused for the day.
• The fixed starting time helps remind the team to work a 40-hour week.

Pair Up

• All production code is produced by a pair.
• The typist thinks tactically, the partner thinks strategically.
• Switch roles periodically.

Test

• Write only small bits of unit test code at a time.
• Verify that the test fails before coding. (It's sure interesting if it doesn't fail.)
• "Test everything that could possibly break."

Code

• "Do the Simplest Thing That Could Possibly Work."
• Implement just enough to make the test pass.
• Follow the team's coding standard.

Refactor

• Seek out "code smells" (places that don't feel right); apply a refactoring; verify that the unit tests still pass.
• The code should:
• Run all unit tests
• Communicate what it needs to
• Have no duplicate logic
• Have as few classes and methods as possible
• Take small steps, and unit-test after each.
• See Refactoring, by Martin Fowler.

Q&A

• The customer is available on-site to provide immediate answers.
• Many questions require decisions (not facts) - and the customer should be prepared to make them.
• The customer should write an acceptance test or (more rarely) a story to capture their answer.

Integrate or Toss

• Move the code to the integration machine, build the system, and run all tests.
• Fix things to bring the unit tests back to 100%.
• If you can't easily integrate, throw it away and try again tomorrow.

Return to "Pair Up"

• If you have time left in the day, you can pair up (or at least switch roles), and start over on another task.

Go Home @ 5PM

• Going home on time reinforces the practice of having a 40-hour week.
• Notice that nothing is hanging over your head - everything you've done for the day is integrated (or tossed).

The XP Programmer's Cube

It's unlikely that a real team will follow the process by sitting down and flipping the cube every time they make a move - so why bother?

• A 3-dimensional artifact can't be left under a pile of paper - it has a better chance of being looked at.
• The cube can help in training, giving beginners something concrete to look at and think about.
• The cube helps remind you of important aspects of XP:
• Always have a partner.
• Get answers before you code.
• Test-first programming.
• Throw it away when you need to.
• Go home "clean".

Conclusion

The cube is a visible artifact that can remind us of important practices that an XP team values.
 

Link: Word document with a cutout cube.

NOTE: I'm still giving away pre-made cubes. Send me your physical address and I'll send you one.

Resources and Related Articles

• Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 9.
• Extreme Programming Explained: Embrace Change, Kent Beck.

[Written 5-31-2000; fixed typo 6-5-00.]
 

Copyright 1994-2006, William C. Wake - William.Wake@acm.org