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.


Comments
bignose Tuesday, November 18, 2008
Even better, use distributed VCS (such as Bazaar or Git) throughout the organisation.

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.
Justin Saraceno Tuesday, November 18, 2008
This is exactly why I really like the concept of Shelvesets in Team Foundation Server. It's the easiest way I've found to keep track of code I don't want to check to production in or throw away. If I decide to use the code later, TFS merge works really well too.
Bruce Boughton Thursday, November 20, 2008
You don't need distributed source control for this. Developers can and should create their own little spike branches. If you want to keep your repo organised, create a "dev" subdirectory of branches or "spikes" or something!
gravatar Najeeb (www.CodeMinima.com) Thursday, April 1, 2010
A (wiki) site for just that, Scott, codeminima.com. You don't have to scrap your spike code, since I agree with you that all code is valuable. Let the entire dev community benefit from it by putting it on CodeMinima. Do have a look.
gravatar weight loss calculator Thursday, October 28, 2010
Nice concept indeed!
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!