Building Features with Spike & Stabilise
Back in September, Dan North introduced us to a Spike & Stabilise approach to building features. It’s been very successful in helping our teams deliver product improvements to our users in a much faster way.
What’s the “Spike”?
The term “spike” often gets used to mean “throw away, prototype code”.
Rather than throwing away spikes, we sometimes ship them - often as experimental features - and get real feedback from users.
That means making some initial quality concessions, like messier code and less tests, in exchange for earlier feedback.
Shipping a spike is not an excuse to ship shit. Anything we ship needs to be good enough for a user to get value from, and to garner useful feedback. NullPointerExceptions teach us nothing, and frustrate our users.
When is spiking useful?
Redgate hugely values user research and design, but upfront research can suffer from long lead times.
Sometimes we believe faster feedback on an idea, and iterating on our solution, will be a quicker way to improve a product.
We aim for a healthy balance between upfront research and feedback on implementation.
What happens between “Spike” and “Stabilise”?
When a spike is running in production, we want to iterate and make that spike valuable to users.
We’ll talk with users about what we’ve delivered, and gather usage data. That helps us to make informed changes to the experimental feature and polish the experience of using it.
What’s the “Stabilise”?
When we choose to ship a spike we accept the risks that come with shipping code that isn’t 100% “production-ready”, and could be hard to maintain.
Stabilising gets that code into a fully maintainable state.
That means ensuring anyone can confidently change the code, getting the architecture into the shape we want, squashing any known bugs, and dealing with tricky edge cases.
When do you Stabilise?
We ship a spike because we want to learn something — typically, “Is this feature useful to users?”.
When we have an answer to that question, then we’re ready to stabilise.
What do you do when you Stabilise?
If the spike is successful…
Stabilising a successful spike mostly means getting the code up to our in-house standards. Improving unit test coverage, refactoring code, and doing some more thorough testing.
When we’re happy with the quality of our work, we consider a spike to be stabilised.
If it isn’t…
Sometimes we ship a spike that doesn’t land, however we iterate on it.
When this happens we “stabilise” our codebase by removing the spike entirely. Deleting low-value code is incredibly cathartic, and we’ve saved time by not fully polishing the code before deleting it.
