XP Programmer’s Cube: A Day in the Life

Posted on by
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:

XP Day in the Life

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

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:
XP 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 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.

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

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