I haven't written code at work in at least 2 weeks

No, I didn't quit being an engineer! Quite the opposite, in fact. I'm currently doing a stretch assignment, an exploratory task that will form the groundwork of how we're going to revamp a certain area of our product.

What's a spike? 🦔

I hadn't heard of the term "spike" (or "functional spike") until now. I suspect one reason for this was because in my other job, there were a number of people who'd been working on the project for years and it was very well-documented, and so there was more general knowledge being passed around. While legacy code is a given on big projects, this codebase I'm working on has seen a lot of different engineers, and as a result, the code is inconsistent in several respects.

According to Wikipedia, a spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions. It is used to determine how much work will be required to solve or work around a software issue. Typically, a "spike test" involves gathering additional information or testing for easily reproduced edge cases.

It's called a spike because you have to drill deep into the problem (ouch!). While I can't tell you exactly what topic I am doing this for, I can say that I'm applying this approach of a time-boxed investigation to a certain module of our project that needs improvement. The business logic is stale, it just needs a revamp, but new functionality is needed, too.

Why should I do a spike? 🐡

Did anyone ever tell you that coding is actually a very small part of software engineering? Because that's absolutely correct. As part of my professional development plan, one skill I am particularly trying to build is evaluating, estimating, all that stuff.

Now, this kind of comes organically the more you work on a project and interact with different parts of its codebase, so you know what to expect. But the technique I am trying out is consciously making assumptions about the system and its individual components that are already available, then figuring out how we can leverage these to achieve the output we need. The idea of this is to make better informed decisions — ones that won't mean we're putting a sticking plaster on a problem, but truly solving it — thereby reducing waste.

And, of course, doing a spike has quite a lot in common with planning a novel (or any other lengthy written work, really)! It won't probably won't work so well with the initial planning, as a spike is more for investigation of an entity that already exists so that you can expand upon it.

But: we've all heard of writer's block, and this can occur not just when you're in the beginning stages of a project, but also when you're in the thick of it. It's definitely not uncommon to find that you've painted yourself into a corner. For example, realising one of your major plot points has more holes than one of those netted bags you put bras in before they go in the washing machine.

Reminding yourself what the "goal" of your book is — what set of problems is it trying to solve? — is a great way to start estimating what will be needed in order to meet that goal. Intensive work interrogating the questions, asking why they are even questions at all (in software this will usually be in terms of user stories), will get you down to the essence of the problem.

Anne-Marie Pritchard has cited some examples of spikes that made it to implementation, as well as some questions you can consider while doing your spike. So, next time you're stuck... go forth and spike! 🌵