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 http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://colinjack.lostechies.com Colin Jack

    Good reminder, I’ve been doing a lot of spiking recently and its difficult not to resist the urge to “just” add a few tests and use it in the main code base. As you say though its probably a bad idea.

  • http://www.sagem-phones.com Sagum

    What’s a spike code

  • http://blowmage.com/ Mike Moore

    1) Use git
    2) git stash
    3) Reimplement your spike using TDD

    Git allows you to stash your changes in such a way that you don’t lose them and you don’t have to commit them to your central repository. Even if you are using SVN, you should be using the git client because of situations like this. Better tooling FTW.

  • Kerry MacLean

    An obvious corollary to this is to treat all code written in an active (non-throw away) branch as if it was to to go to production – that is, get your tests around it first, properly documented, etc. etc.

    It seems like an obvious thing, but the amount of stuff that should be “spike” code embedded in production branches is scary.

  • http://www.jphamilton.net J.P. Hamilton

    If TFS has one feature that is decent, it might be shelving. I’ve used it a couple of time for some spikes on my current project.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller
  • Madhur

    And the definition of spike code is ? Couldn’t find online anything ..

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    Um, making a new branch in Subversion takes 5-10 seconds with Tortoise SVN?

  • http://sentia.com.au/blog Dave Newman

    I’m sure i’d do this in a branch more often if if SVN didn’t make it so painful!