Turning spikes into a solution

Spike: A simple prototype program to prove your assumptions. This can range from feasibility to performance and back again.

I recently found that almost half of my time is spent creating spikes for ‘difficult’ situations I encounter. One of the pitfalls of writing spikes is getting stuck in an endless cycle of writing them. You’ll end up with a bunch of proofs that the problem can be solved, but your problem is still present. So, how do we avoid getting stuck on spikes? I use the following steps:

Analyze
Before you start building your spike you should decide what you’re building. I’ve seen people (myself included) start building a spike for something, which turned out to be a prototype for half of the wanted solution. If you’re familiar with the Single Responsibility Principle, you could apply it here as well, but on a higher level. For instance, if you need to prove that your system can successfully connect to a stock exchange webservice, don’t bother spiking your xml serialization, or pay any attention to a pretty UI.

Quantify
View your spikes as any other task on your project. You will have to set a deadline, make sure dependant tasks are planned accordingly, and most important of all: decide how much time you’ll need to build it. If you’re anything like me, you enjoy building spikes, and think finishing up a project is tedious work. If you don’t quantify, you’ll be building your spike till the end of times (over dramatization)!

Build
Start creating your spike, with the previous steps in mind. If you feel you’re doing too much, prototyping too much functionality, consider planning another spike for the extra functionality. Focus on the problem at hand, it’s perfectly fine to test an algorithm in a console application. If possible, build your spike as a separate project, instead of inside your existing system. This is usually easier and faster.

Refactor (optional)
Your spike is likely not the best programming possible, as the only goal is to see if your assumptions are correct. Refactor your code to apply the usual guidelines (like low coupling, high cohesion, SRP, etc.), and make sure your tests still pass (assuming you use some form of testing).

Integrate (optional)
If applicable, integrate your spike into your solution. Make sure it doesn’t break anything (automated testing anyone?) and make sure it follows your coding guidelines. All in all, make sure it fits in as part of the whole solution.

This being said, theoretically it’s all very easy. The most difficult part of the whole process is discipline. You will have to constantly keep an eye on yourself and make sure you either stick to the plan, or adapt the plan to stick to you. The first one is safer, the second one is more flexible.