Spike Solutions

Quick Questions

> "a" < "b"
true
> "a" > "b"
false
> "a" === "a"
true

Alternatively, you can write a short test. You can put it right next to your real tests, then delete it afterward. For example, if you wanted to know if Java throws an exception on arithmetic overflow, a throwaway test would answer the question:

@Test
public void deleteMe() {
  int a = Integer.MAX_VALUE + 1;  // test will fail if exception thrown
  System.out.println("No exception: a = " + a);
}

// Result of test run: "No exception: a = -2147483648"

Third-Party Dependencies

For complex dependencies, such as frameworks, I’ll often start with their tutorial. However, those tutorials tend to emphasize getting up and running quickly, not helping you understand the framework. They often have a lot of magic tooling that makes the framework harder to understand, not easier. So make their example your own. Remove magic, call APIs manually, and simplify unneeded complexity. Think about your use cases and demonstrate how they’ll work.

When you’re done, you can check the spike into your code repository to act as a reference while you build the real implementation. (I use a /spikes directory.) Once you’ve built out the production implementation, you can either delete the spike or keep it for future reference, depending on how useful it is.

Design Experiments

Spikes are much more focused. They’re created to answer a narrow technical question, not to mimic the final product.

Should we pair or mob on spikes?

It’s up to you. Because spikes don’t need to be maintained, even teams with strict pair programming rules don’t require writing spikes in pairs.

One very effective way to pair or mob on a spike is to have one person research the technology while another codes. Another option is for 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 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 needed to solve a problem, not to produce the code that solves it. The real production code usually ends up being a better reference than the spike.

When should we create a spike?

Whenever it helps. Perform a spike whenever the constraints of writing production-grade code get in the way of figuring out a solution.

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

That’s good; now you have information you needed to know. Perhaps your on-site customers will reconsider the value of the story you’re working on, or perhaps you need to think of another way to accomplish your goal.

Prerequisites

• Rather than speculating about how your program will work, you conduct an experiment that tells you.

• The complexities of your production code don’t interfere with your experiments.

Alternatives and Experiments

An alternative to spike solutions is to research problems by performing web searches, reading theory, and finding code snippets online. This can be good enough for small problems, but for bigger problems, the best way to really understand the technology is to get your hands dirty. Go ahead and start with code you find online, if you need to, but then simplify and adapt the example. Why does it work? What happens when you change default parameters? Use the spike to clarify your understanding.