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.