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.
Comments
Having a single *repository* unnaturally couples the “central storage” requirement to the “trunk line of development” concept, resulting in the dilemma you describe. Instead, just announce a central *storage location* where *any* repositories will be backed up and managed by IT support.
That way, the concepts of “needs to be preserved” and “needs to be part of the main development history” are de-coupled. Anyone who wants to experiment can branch from the trunk to a new repository, develop their spike, and either re-integrate or abandon it as they choose later. Either way, it gets preserved until someone explicitly decides it's not worth keeping, instead of that decision needing to be made before starting.