A spike is a small, disposable experiment in code. After learning about your problem or solution via the spike, you throw it away and rewrite the code using TDD. Here, we look at a process for doing that incrementally, using the spike as a guide and git's rebase functionality as the means. It's only appropriate when the spiked code is heavily constrained by external interfaces. But, in that case, it can guide you through tricky third party interactions. Because this is a subtle topic, the screencast is necessarily demonstrating a simplified form: the spiked and TDDed code are identical. When doing this in practice, the rebases will result in nontrivial conflicts since the implementations won't be identical. The more dissimilar they are, the closer you are to true test driven design, and the less useful this technique is.