I was recently looking over a friends “spike”. For those that don’t know a “spike” is a development effort with the end goal of learning something. The thing that you learn from a spike might be technical but it could also be along the lines of “do we want to move forward”.
After a few hours of work the spike look like this:
- project (node)
- tdd tests
- bdd tests
more stuff here
- packages (express and all)
On running the tests we can find out that express will respond with 200 when a request for the route “/” comes in.
What is the point?
The goal if this spike is to learn something from from the results of the spike, not the act of the spike. If the goal was to learn how to write tests in a new env maybe this spike would be a success but our goal is to see if our idea is feasible.
I’ve been trying to figure out why the first steps in this project ended up going in the opposite direction of the goal: test the feasibility of a program that does XYZ.
What we give up
As we write a spike we lose a great deal of things and the lose of these things are part of the spike. We lose all the enterprise future proofy type stuff. We lose the safety that our edge cases are caught. We lose the love for our code.
A spike should be test but if we all in love with our spike we never want to toss it out the window. It’s more important to feel loss when working on a spike (of any size [lean startup, AB testing, tech spike]) so that we can find an answer and move on.