Don’t Check in Spike Code…

…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;-)

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.