I just read a post over on Codebetter.com where Jeremy Miller advises us all to not check in a code spike. When I initially read this, I got a creepy, crawly feeling because the thought of doing any work at all without checking in makes me a little nervous.
As I read Jeremy’s post, though, I became more comfortable with Jeremy’s reasoning, and I also came to understand what was driving me nuts when I saw the post in the first place. Not only did Jeremy not really mean “don’t check in your code”, but I was reading “spike”, and thinking “reference architecture.” Let me explain.
The spikes that Jeremy is talking about are explicitly defined as throw-away code in every sense of the word. There’s no expectation that any of this code finds its way into your main source trunk. You’ll also notice that Jeremy ends up suggesting that you actually *do* want to check these spikes in — just not into your main trunk.
In my experience, though, it’s not uncommon for a “spike” to evolve to the point where it’s used to illustrate how something is going to work. In other words, once you’ve used the spike to prove that something can work, you want to use it to show others how it’s done. When that happens, you’re starting to turn your spike into a reference architecture, and this is a much more important beast than your normal spike. Here are some signs that your spike might really be turning into a reference architecture:
- It’s documented. If you start to go through the trouble of explaining how this thing works, it’s more than just a spike.
- It’s got more than one revision. If you check in updates to your spike to illustrate new ideas instead of building a new spike, you’re growing a reference architecture.
- It mimics the structure of your “real” application. If you go to the trouble of making your spike’s project structure look substantially like your application’s structure (or vice versa), there’s a good chance you’re going to end up with a reference architecture by the time you’re done.
Personally, I like reference architectures a lot. They’re small-scale illustrations of how all the moving pieces in your application fit together in a size and scope that can be absorbed a lot more quickly than your full application.
Do you find this distinction in your projects?