Some of the XP practices may be things we want to do all the time. Some we may wish to do only part of the time. When we are really skilled in use of a technique, we’re best equipped to decide when to use it. Here are some exercises that may help build skill. And make up your own exercises. Let us know about how they work. Added: Planning Etudes.


Planning Etudes

At XPUniverse, in our justly famous planning course, we said that we thought Microsoft Project was inferior to cards for planning. One of the attendees e-mailed the other day to ask why. Here’s what I suggested. Really do this. It’s important that you do the experiment, not just think about it.

Take some blank cards, and write the letters A through J on ten of them. These cards represent ten planned features of your project.

Lay the cards in front of you, in alphabetical order, with A on the left. Left indicates that we’ll do it first, cards to the right will be done later. So now we have a plan, A, then B, then C, …, then J.

Wait! We’ve made a mistake! It turns out that vowels are less important than consonants. Rearrange the schedule. Note how long it took.

Wait again!! Letters with holes in them are more valuable than letters without holes. But consonants are still better than vowels. Arrange the schedule again. Note how long it took.

Wait! One more change! The president really likes feature G and hates C. Do the schedule over. Note how long it took.

Now go into Microsoft Project. Set up the project with ten tasks named A through J. Show them as occurring sequentially. Now do the rest of the exercise. Make each change in Project. Note how long it takes. Note how you feel about it.

Please let me know what you discover.

New Tests for Old Bugs

When a defect shows up in a user’s hands, we should write an Acceptance Test that shows the defect. When an Acceptance Test shows up a defect, we should write a Programmer Test that shows the defect. It’s not enough just to fix the bug. Writing the tests is an etude: we learn what to test and how to test it.

When you’re performing in concert and screw up a difficult passage, next week you practice the etudes that help with that kind of passage. And you practice the passage itself.

The discipline of always writing the test that was needed helps us to remember what tests are needed and how to test that kind of defect.

Most of the defects that slip through our nets are due to tests that were hard to think of, or hard to write, or seemed to be a waste of time. So we practice that kind of test writing, by writing the test we should have written, even though we don’t need it so badly now. We need the learning … and we get it by practicing what we need to learn.

Pair Programming

Pair programming seems difficult to some folks, seems undesirable to others. When you’re as good at pair programming as you can be, you’ll know when to pair and when not. To improve your skill at pairing, consider some of these exercises.
  • Have, use, and share breath mints.
  • Set a timer to about five minutes. When the timer dings, discuss the name of whatever you’re working on with your partner.
  • Have the pair dictate code to the driver, while the driver types and comments.
  • Thank your partner sincerely for everything s/he says.
  • Comment a method to make it more clear. Now try to improve the method so that it doesn’t need the comments after all. Discuss as you go.
  • Work alone with a timer running. When the timer dings, explain what you’re doing to someone else. Discuss openly.
  • Work alone with a timer running. When the timer dings, throw away the code you just wrote and do it again with a pair. Pay attention to the resulting quality and to the amount of time it takes.
  • When driving, make various intentional typos and errors. Help your pair catch them and help her express them in ways that are helpful to you.
  • Remember to express appreciation for good things as well as calling out errors.
  • When doing test-first development, switch driver and partner after every test/code cycle.
  • When doing test-first development, switch between test and code: A writes test, B codes, B writes test, A codes.
  • Have one person mouse and one type.
  • Two computers, eight hands. When the timer dings, swap pairs. With four people, there are six different ways to pair. Try them all.

Send Us Your Ideas

From time to time, we’ll be adding to this list of etudes. Write the editor with suggestions for etudes in all areas of Extreme Programming.

Posted on:

Written by: Ron Jeffries

Categorization: Articles, Classics

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.