Don’t spike till it hurts

Out of a spike, nothing but the newly acquired knowledge should be part of the final solution.

Both technology and technical creativity move along at a quick pace and people are always looking for better ways to solve their particular problems. The quest for improvement is a natural one. It is part of human nature. Innovation abounds and the abundance of new open source projects tackling similar problem spaces provide ample opportunity for the curious software developer to scratch that particular itch, be it as a contributor or a user.

Most software projects I’ve been involved with have included some new element of technology, or some new feature of a trusted technology. Whether this is a feeling of responsibility to always provide the optimal solution, or whether it is an eagerness to play with a new toy is debatable and there may be an element of both underpinning the quest for improvement. Fortunately, there has usually been the awareness of a responsibility associated with innovation. The introduction of the unknown should always be seen as a risk and should not be embarked upon without some means of mitigation.

If you try something new then you really need to have a safety net to take away the risk.

Typically this risk mitigation takes the form of a spike or technical task to prove the appropriateness of the technology to the solution. In the agile world a spike story is usually scheduled early on and is targeted to prove that the technology feature satisfies the project’s needs (as opposed to a time-boxed technology investigation where you schedule a fixed amount of time to explore a technology to see what features it offers).
In some cases, new technology adoption will involve the scheduling of a time-boxed technology investigation followed by a targeted spike. Firstly, find out what the technology can do then, secondly, prove that one of the identified features is suitable for the solution.

The use of spikes can be seen as reasonable and responsible risk-mitigation. And what’s more, it’s win-win. On one hand, proving the technology is a good thing – we made the right choice. On the other hand, disproving the technology is also a good thing – the risk mitigation was effective. What can go wrong?

Sadly, people occasionally forget that spikes are meant to be throw-away implementations. The only important artifact from a spike should be the knowledge acquired during the spike. Everything else should be thrown away. Ok, before anyone jumps on my case about that last sentence, it should read

“Out of a spike, nothing but the newly acquired knowledge should be part of the final solution“.

Feel free to keep the spike code in subversion (or whatever SCM you use), just don’t use that code for anything else. A spike is a spike is a spike.

I have seen, too many times, programmers become attached to the spike, not wanting to let go.

“If I just add a little more then it will solve our problem. Almost there…look it works!“

Sure, it may be functionally correct, but how much attention to maintenance/readability/abstraction was paid during this spike? When I first thought to write this entry I was tempted to suggest that you code your spike in as procedural code as you can; violate your checkstyle checks; remove all temptation to include it in your main codebase. I almost suggested that any extra effort to provide the normal things we aim to produce in our coding efforts (clean, readable code with appropriately chosen abstractions) are fluff in this context.
A little over the top? Probably.

The focus of the spike should have been to prove or disprove the technology, nothing more, nothing less.

However, I’m trying not to send the wrong message here. I’m not advocating that programmers should throw away good habits; in fact, I’d hope that not to be the case. I’m advocating programmers acknowledge that spikes are disposable and should be treated as such. The nature of a spike precludes a programmer’s finest coding efforts and, consequently, spiked code should never be considered to be part of the final solution.

Look for shortcuts to get you to the aim of the spike. If this forces a temporary relaxation of rigour then acknowledge the reasons for the relaxation and complete the spike. This approach cannot be taken, however, if the goal of the spike is uncertain. The intent of the spike has to be clear. You need to know when to stop. There needs to be constraints applied to the story, similar to acceptance criteria, that make it obvious that the story is complete.
e.g. Stop if the library is not thread-safe.

Another manifestation of the programmer becoming attached to a spike is solution-affinity. This occurs when a programmer tackles the spike using the same metaphor as the project.

e.g. the project is concerned with car finance and the spike aims to prove that a particular workflow engine is suitable. If the spike uses concepts from car finance to prove the workflow engine (i.e. exactly the same metaphor as the project) then it becomes difficult to relinquish the approach taken in the spike. Any efforts to implement the technology will mirror that of the discarded spike. Again, this is a problem because the intent of the spike is different to the intent of the project. Different rules apply.

To avoid solution-affinity, attack the spike with a different metaphor. Try to divorce the proving of the technology from the overarching domain. Spike the workflow engine using a different domain. Change the context to free the programmer from bias built up during the spike.

Spikes can be effective risk mitigation tools but try to remember:

• Never forget the purpose of the spike.
  
• Always know when to stop.
• Spike using a different metaphor.
• Keep your rigour but optimise your approach to keep to the intention of the spike.
  
• Throw away all but the acquired knowledge.