Spike Code and Source Control

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.