Spikes

A few weeks ago I wrote some of the worst markup I have written in years. I went at the project with no real respect for creating a set of useful class names, browser support or how the front end would glue to the CMS. Numerous design, animation and art direction decisions were being made collaboratively in the browser and code editor by myself and Paul.

The reason I worked this way was I didn’t know enough about where the project was going, there was a fierce deadline in front of me and the potential for the client to bin a lot of the concept on demo day.

A few days later I was showing the site to Jamie and I mentioned that the code was shamefully bad and needed deleting, I told him I only created this version to find out where the project was going.

In his wisdom Jamie said, “Ah, that’s called a spike in programming. You start working at the problem not knowing all the answers and look to take what you learn at the end to form the correct approach for the final version. The spike is pretty much deleted, the insight is what’s carried on.” This is why you should hang out with Jamie. He says clever shit like this all the time.

It got me thinking about how many times I’m apprehensive about starting work on a task. I scurry around the edges of it, peering at it, pondering about the best possible way to make it happen. Perfection can manifest itself in all sorts of rather imperfect ways. The desire for tasks to be executed in the best possible way will often leave them waiting, sat dormant and unloved.

Spike what you’re working on. Go at it and accept that you will need to throw stuff away. There’s nothing new here, product designers prototype, writers draft and apparently programmers spike.

There are a fair few variations on exactly how to define a ‘spike’ found on this there internet. Most of them are documented within agile workflow. All worth reading if you’re curious.