Code has never been cheaper. Over the last few years, even the most skeptical software engineer has likely started including a fair chunk of AI in their process. On the other side of the balance are the Tokenmaxxers, they attempt to reach value by invoking Shakespearean Monkeys hoping eventually to give them product market fit by a scattergun approach to shipping anything that moves.

Somewhere in the middle is a little more interesting to me, that is a place where developers retain clear responsibility and use that to develop more interesting software, more rapidly.

It's very vogue at the moment in product, design, and engineering to show, don't tell. Replace your presentation with a demo, and replace "how would X work" with real experience.

As such, the value of a good spike/functional prototype is immense. Incredible increases in clarity become available, as the possibility of mixed interpretation between team members goes down. But the existence of a good spike leads to the follow on. What's a bad spike?

Increasing clarity

Any spike should radically increase clarity. That's fundamentally the point, if you already knew exactly what you wanted to do that's not a spike - that's just called getting shit done.

In a spike, you're actively trading perfection for fast decision making and high end-to-end agency. To get working quickly, teams need to know what the target of this spike is. You don't want a backend developer going away diving into how to make performant database queries when the real question is "does this new page make any sense in our website hierarchy?".

It's therefore vital that you communicate a target in mind for the clarity you're looking to gain. A "we should spike this" - without a crisp articulation for "this" is begging for fake productivity. Usually this ends with a lot of people coming together to jam on something. Suddenly, demo videos start flying around, devs are jamming on new tech, and everyone's throwing designs on a wall and surrounding them with sticky notes. Wow, we really must be doing something here... It's entirely possible that something has zero real value. failure to communicate what you're doing leads to an untuned orchestra all playing their own favourite key.

So, start with the exercise of figuring out the question that you're asking, what do you need further clarity on?

From my experience, I classify most spikes in the following categories

In each of these cases, you want to cheat on everything except the question.

Thinking of a new encoding structure for importing video? Cheat on the frontend upload. The bytes already exist on the server.

Thinking of a new checkout page experience? Cheat on the integration, FakeStripe accepts 100% of all the calls you told it to.

Cheat, don't lie

Don't cheat too close to the sun. Consider the experience spike. It's a great opportunity to shim out the complexity of a feature like "import from dropbox". Let's just have the import faked and all files are just in a js bundle on the frontend. This sounds good unless you forget that the integration will take time to process. A cheated import that takes 2ms to run isn't just a cheat, it's a lie that skews your answer to the question. Of course the experience is fantastic when external dependencies are instant. So, this means in an experience spike you can cheat the technical - but you don't fake the actual experience impact.

This lie is common in demo-driven design. It's a "free" way to make your design look like it's working. In a technical spike, this sort of cheat could look like only designing for a single case when the technical design is challenging in part due to the combinatorial complexity. In integrations, it could look like ignoring the edge cases that are hard and only gluing together the easy pieces. Maybe an integration is only hard because COPPA laws make it hard.

So cheat judiciously, but consider doing so in the open. Every cheat should be honest about what it is and why it was a good idea.

Provide feedback to each other when the wrong cheats are taken. Failure to be honest about the cheats & tradeoffs taken fundamentally erodes the outcomes that you're attempting to achieve. Remember, these cheats do need eventual solution - you will fuck around and find out eventually.

Throwaway

Due to tradeoffs made in a spike, once consensus is established on the solution, the code is almost definitely worth throwing away. This can feel wrong, and feel like you're about to slow yourself down. I assert that's probably not going to happen.

During a spike, you regularly make decisions - remake them - and rebuild things. Minimal to zero time is spent on total coherence of the system. This is analogous to a maze, as you meander and take the various paths you'll find yourself backtracking and trying a new path. Compare that to when you know the solution and can go right to the end of the path. Your code can be written quickly, and better by simply starting again.

Having this expectation of throwaway also gives even more license for your spike to go as fast as you can towards your end state. As there's no one with a worry in the back of their mind that this code is actually about to go in front of all of your customers.

Stakeholders may be concerned that doing this increases the time to value - why after all can't we ship it right now?

It's largely a reasonable question. Extracting the production code from a spike can feel like you're digging through dinner looking for any onions that you want removed. Failure to do any of this excavation would instantly inherit every tradeoff that was accepted in the original spike, as well as many more that were simply not thought through. The speed of software development is often based on amount of decisions being made and agreed upon.

Collaborate

Fundamentally, the rapid iteration that is required to survive in today's world requires a reshaping of working styles. We're seeing a lot more teams with embedded specialities, and a lot more people taking on diverse workloads that previously would be handled by specialty experts. Use this opportunity of intense collaboration to learn more about your peers' crafts and the cheats that they use to be able to work more effectively to find the answer to their question. Attention to this will build empathy with what's hard about your peers' challenges.

It turns out, after all this time that my science teacher in school had accidentally nailed the requirements for rapid software iteration. Write a good hypothesis, one worth testing, then test the hell out of it.