Eric Polerecky bio photo

Director, Professional Services @RightBrain_Net - 50% engineer, 50% entrepreneur. Former: CTO @Wantify, @agilesoftware, @grasshopper

Eric Polerecky

Email Twitter LinkedIn Github Stackoverflow

Certifications

Xamarin (expired)

Speaking

Microservices? Real World FRP Xamarin Forms Case Study

All Posts

All Posts

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:

  1. project (node)
  2. app.js
  3. routes.js

  4. tests
  5. tdd tests
  6. stuff here

  7. bdd tests
  8. more stuff here

  9. config
  10. grunt
  11. packages (express and all)
  12. mocha
  13. etc.

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.