OdeToCode IC Logo

Spike Code and Source Control

Tuesday, November 18, 2008

Jeremy’s post “Don’t Check In Spike Code” reminds of something I’ve advocated for years: dedicate a place in your source control repository where each developer can check in their “experimental” code. The rule of thumb is to throw away code you write for a spike, but all code can be valuable, even if it isn’t production worthy.

Here are the kinds of things I’ve checked into “experiments/sallen” over the years:

  • Code to isolate and reproduce compiler, framework, and library bugs.
  • Code written to learn a new technology, platform, or library.
  • Code that I almost threw away because I was sure it would only be needed once (like a one time data import).
  • UI mockups
  • Code written to evaluate a product.
  • Code that doesn’t work (because you’ll have proof 6 months later when someone else has the same idea).

I’ve found that keeping a dedicated area for these types of check-ins offers some advantages:

  • It keeps spike code out of production branches (as Jeremy suggests).
  • It keeps code around that you might find useful to refer to one year from now.
  • After someone leaves a project, their experiments live on.
  • It saves you from saying “I think I tried something like that last year but threw the code away”.

If nothing else, you can look back at what you wrote when you were spiking on a new technology and laugh in that “oh man, we really didn’t know what we were doing ” way.