|The XP Programmer’s Cube is an artifact that captures the key activities in a day in the life of an XP programmer.|
XP Programming Activities
XP is unusual as methodologies go, in that it prescribes activities at the day-by-day (and even at the minute-by-minute) level.
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.
- All production code is produced by a pair.
- The typist thinks tactically, the partner thinks strategically.
- Switch roles periodically.
- 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."
- "Do the Simplest Thing That Could Possibly Work."
- Implement just enough to make the test pass.
- Follow the team’s coding standard.
- 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.
- 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
By a lucky twist (and a little fiddling), it turns out that the core of this cycle can be embedded onto the shape of a 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".
The XP Programmer’s Cube embodies the daily activities of the XP lifecycle:
Pair Up, Q&A, Test, Code, Refactor, and Integrate or Toss
The cube is a visible artifact that can remind us of important practices that an XP team values.
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.]