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.
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 10-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 = -2147483648Although this example is written as a standalone 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.
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 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 you can’t reuse this code in your actual production codebase, as you didn’t develop it with all your 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.
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).
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 focus just on short-term results. (That said,
for larger spikes, you may find 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 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 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 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 do 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.
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 on the ways in which your production code might be interacting with your experiment.
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.
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.
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.