Just last week, I was talking with a friend who was asking for advice on how to architect his iOS app. He wanted to know the best way to do it, and we came up with a few approaches that seemed appropriate. We never did decide on which would be best, so he asked, “how do you normally decide which approach to take when you have multiple options?”
After thinking on it a bit, I realized that I normally just pick an approach and start building it. Dive into the code, try doing it one way, and then take a step back and see how well that particular approach is working. And if I don’t like it, I’ll scrap it and start over with a different approach.
It turns out this is a common practice in software development, and it’s called a spike solution. Jon Reid of Quality Coding defines it this way:
A spike solution is a code experiment. It’s called a “spike” because instead of carefully building things up layer by layer, we just brute-force something, driving through multiple layers.
It’s a quick and dirty experiment, brute-forced to prove a concept, see how an approach works, or explore potential solutions. And since it’s a quick & dirty experiment, you should throw it away when you’re done. The spike should never make it to production, and that’s ok – we’re just looking for the right approach or solution. We can and should take what we learned in the spike and bring it into the production code.
So if you’re struggling with deciding on the right approach to your problem, create a new branch, and start spiking. You don’t have to worry about messing up your production code or getting shoehorned into a single approach; you can always leave your spiked branch, go back to master, and create a new branch with a new spike. Then you can compare both spikes, see which one you like better, and move forward with that approach. And remember, a spike is quick & dirty, so don’t worry about your code being perfect – just bang it out as fast as you can.
When you're programming, how do you decide which approach to take to solve a problem? http://t.co/3DxN2xHTPO
— Josh Brown (@jtbrown) April 7, 2015
Further reading
Matt Swanson does an excellent job describing the spike approach.
Jon Reid describes how he uses spike solutions.