• Next: Performance Optimization
• Previous: Incremental Design and Architecture
• Up: Chapter 9: Developing

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Spike Solutions

Audience

Programmers

We perform small, isolated experiments when we need more information.

You've probably noticed by now that XP values concrete data over speculation. Whenever you're faced with a question, don't speculate about the answer—conduct an experiment! Figure out how you can use real data to make progress.

That's what spike solutions are for, too.

About Spikes

A spike solution, or spike, is a technical investigation. It's a small experiment to research the answer to a problem. For example, a programmer might not know whether Java throws an exception on arithmetic overflow. A quick ten-minute spike will answer the question.

  public class ArithmeticOverflowSpike {
      public static void main(String[] args) {
          try {
              int a = Integer.MAX_VALUE + 1;
              System.out.println("No exception: a = " + a);
          }
          catch (Throwable e) {
              System.out.println("Exception: " + e);
          }
      }
  }

  No exception: a = -2147483648

Although this example is written as a stand-alone program, small spikes such as this one can also be written inside your test framework. Although they don't actually call your production code, the test framework provides a convenient way to quickly run the spike and report on the results.

Performing the Experiment

The best way to implement a spike is usually to create a small program or test that demonstrates the feature in question. You can read as many books and tutorials as you like, but it's my experience that nothing helps me understand a problem more than writing working code. It's important to work from a practical point of view, not just a theoretical one.

Writing code, however, often takes longer than reading a tutorial. Reduce that time by writing small, standalone programs. You can ignore all the complexities necessary to write production code—just focus on getting something working. Run from the command-line or your test framework. Hardcode values. Ignore user input, unless absolutely necessary. I often end up with programs a few dozen lines long that run almost everything from main().

Spike solutions clarify technical issues by setting aside the complexities of production code.

Of course, this approach means that you can't reuse this code in your actual production codebase, as you didn't develop it with your the normal discipline and care. That's fine. It's an experiment. When you finish, throw it away, check it in as documentation, or share it with your colleagues, but don't treat it as anything other than an experiment.

I discard the spikes I create to clarify a technical question (such as "Does this language throw an exception on arithmetic overflow?"), but generally keep the ones that demonstrate how to accomplish a specific task (such as "How do I send HTML email?"). I keep a separate spikes/ directory in my repository just for these sorts of spikes.

Design Spikes

Sometimes you'll need to test some approach to your production code. Perhaps you want to see how a design possibility will work in practice, or you need to see how a persistence framework will work on your production code.

In this case, go ahead and work on production code. Be sure to check in your latest changes before you start the spike and be careful not to check any of your spike code.

Scheduling Spikes

Ally

Slack

Most spikes are performed on the spur of the moment. You see a need to clarify a small technical issue, and you write a quick spike to do so. If the spike takes more than a few minutes, your iteration slack absorbs the cost.

If you anticipate the need for a spike when estimating a story, include the time in your story estimate. Sometimes, you won't be able to estimate a story at all until you've done your research; in this case, create a spike story and estimate that instead (see Stories in Chapter 8).

Questions

Your spike example is terrible! Don't you know that you should never catch Throwable?

Exactly. Production code should never catch Throwable, but a spike isn't production code. Spike solutions are the one time that you can forget about writing good code and just focus on short-term results. (That said, for larger spikes, you may find that code that's too sloppy is hard to work with and slows you down.)

Should we pair on spikes?

It's up to you. Because spikes aren't production code, even teams with strict pair programming rules (see Pair Programming) don't require writing spikes in pairs.

One very effective way to pair on a spike is to have one person research the technology while the other person codes. Another option is for both people to work independently on separate approaches, each doing their own research and coding, then coming back together to review progress and share ideas.

Should we really throw away the code from our spikes?

Unless you think someone will refer to it again later, toss it. Remember, the purpose of a spike solution is to give you the information and experience to know how to solve a problem, not to produce the code that solves it.

How often should we be doing spikes?

Perform a spike whenever you have a question about if or how some piece of technology will work.

What if the spike reveals that the problem is more difficult than we thought?

That's good; it gives you more information. Perhaps the customer will reconsider the value of the feature, or perhaps you need to think of another way to accomplish what you want.

Once, a customer asked me for a feature I thought might work in a certain way, but my spike demonstrated that the relevant Internet standard actually prohibited the desired behavior. We came up with a different design for implementing the larger feature.

Results

When you clarify technical questions with well-directed, isolated experiments, you spend less time speculating about how your program will work. You focus your debugging and exploratory programming on the problem at hand rather than the ways in which your production code might be interacting with your experiment.

Contraindications

Avoid the temptation to create useful or generic programs out of your spikes. Focus your work on answering a specific technical question, and stop working on the spike as soon as it answers that question. Similarly, there's no need to create a spike when you already understand a technology well.

Ally

Test-Driven Development

Don't use spikes as an excuse to avoid disciplined test-driven development and refactoring. Never copy spike code into production code. Even if it is exactly what you need, rewrite it using test-driven development so that it meets your production code standards.

Alternatives

Spike solutions are a learning technique based on performing small, concrete experiments. Some people perform these experiments in their production code, which can work well for small experiments (such as the arithmetic overflow example), but it increases the scope of possible error. If something doesn't work as expected, is it because your understanding of the technology is wrong? Is it due to an unseen interaction with the production code or test framework? Standalone spikes eliminate this uncertainty.

For stories that you can't estimate accurately, an alternative to scheduling a spike story is to provide a high estimate. This is risky, because some stories will take longer than your highest estimate, and some may not be possible at all.

Another option is to research problems by reading about the underlying theory and finding code snippets in books or online. This is often a good way to get started on a spike, but the best way to really understand what's going on is to create your own spike. Simplify and adapt the example. Why does it work? What happens when you change default parameters? Use the spike to clarify your understanding.

• Next: Performance Optimization
• Previous: Incremental Design and Architecture
• Up: Chapter 9: Developing