...into the trunk.
Just like the title says, do NOT check “spike” code into the source control
trunk. When you do an exploratory spike, you’re generally throwing good coding
practices completely out the window. You’re on a focused mission to “figure out
how this gosh durned thing is supposed to work.” The code that you write in a
spike probably sucks anyway.
Do spike whenever you’re unsure how to work with some new
library or technology or to try out a new object structure – but put that code
in a branch. As soon as the spike has achieved its purpose, put that code
aside, and write all new code in the trunk using TDD and your normal coding
standards. You know, the coding and design standards that you've adopted as a team because you think those standards lead to sustainable quality. But Jeremy, I could just retrofit some unit tests around the spike
code and call it good! Maybe, but you better ask yourself, am I really going to
put decent tests around this code? Retrofitting unit tests never results in the
same quality of tests as real test first development. Besides, as I said
earlier, spike code generally sucks anyway;-)