Spikes vs Tests: Brothers not Enemies

I write this post with a certain amount of guilt. If you look at my public coding persona (https://github.com/mikemoraned) it’s not unusual to see code with minimal tests, and a wide variety of styles and libraries. Compare that to my ‘at work’ style and, you’ll have to take my word on this, you’ll find a lot more tests and consistency. Why the difference? Most of my non-work code is the result of a Spike.

In a similar vein to my other article, it’s important to know why you are doing something, and what ‘done’ looks like.

I do a Spike for various reasons, like wanting to explore a new language, or I’ve got an idea about how something might work, but I’m not totally sure it’s feasible. A Spike could possibly go on forever, so you have to choose a semi-arbitrary limit on when to stop. If I’m on holiday then I’ve got more free time, but that also means it’s easy to get distracted into Yak Shaving territory and I also usually have a stack of ideas waiting to try out. In practice, I’m usually ‘done’ either when I’ve learned what I needed to, or a couple of days have passed.

Analogy hat on. Spikes serve the purpose that mockups do in other disciplines. It’s easy to have an idea in the shower, a lala-land where things always work, and think you are done. However, when you try to make it you find the bits are too heavy and fall apart when put together. Let’s consider a couple of recent examples.

My Playing music when someone is typing idea came when I was on a plane. After breaking it down I identified what I thought was the most difficult technical part and I did a Spike on that. I almost ran out of time, because I’d made a stupid mistake interpreting radians as degrees. However, I got to the point where I thought it was proven feasible, so I stopped and wrote it up.

Should you use tests during Spikes? Maybe. Should it be test-driven? Definitely not. If I’d done this Spike that way, then I probably would have found the radians bug, but the whole process would have taken a lot longer. Test-driven development is good for situations where you need to go from no software, to working software, delivering small units of working, valuable software along the way. With Spikes you’re taking on the risk of either delivering nothing, or, at-best, ending up with something which basically proves the point but which is very fragile. This is ok, because this is balanced against the risk of not finding out anything at all.

The reason I suspect most people who do Spikes still advocate doing them in a test-driven way is because they suspect the Spike-produced code will be taken from their hands and used for realz. You can make this less likely by using technical hints, like doing it on a branch. Ultimately, the problem of “shipping the prototype” is a social problem, not a technical one, and not one I have any easy solution to. However, for me, personally, on my own projects, I can just not be stupid.

This first example was about proving if it’s technically possible to detect fingers moving a keyboard. Any final product would look nothing like this. My second example is different, and is more akin to a working mock-up. It started out as this (excuse my ridiculously bad sketching):

As explained in the post, I have some ideas about using GeoHashes to show geocoded images. This formed in my head as way of exploring a series of pictures, and I did the sketch above around what it might look like. Over a day or so, I found a source of images, and started exploring how to show them. It was important to use real images, because I wanted to get a feel of whether exploring a real, but pseudo-geocoded, space made sense. I soon dropped a lot of what I’d originally envisaged, such as sliding your finger over images to browse them, because although it would be fun to implement, it wouldn’t help me with my larger mission. In the end, I ran out of time, but I did get as far as seeing what it felt like to explore the space, and what the problems were (“where the bits were too heavy"). I haven’t learnt as much as I’d liked but it’s important to not just blindly bludgeon your way forward, because that way leads to eventual pain.

So, in summary, use a Spike when you want to explore, don’t be ashamed to not use tests, limit your time, and keep the learning, but not the code.