Spike mindset and the not so obvious second-order thinking questions
“Failing to consider second- and third-order consequences is the cause of a lot of painfully bad decisions, and it is especially deadly when the first inferior option confirms your own biases. Never seize on the first available option, no matter how good it seems, before you’ve asked questions and explored.”
~ Ray Dalio
Over the last few years, I’ve found a correlation between second-order thinking, which is the ability to think through the nth order consequences of our actions, and running spikes. Whenever I’m starting projects as either Tech Lead or Solutions Architect, I instruct my teams to run spikes on the requirements we are most uncertain about.
Reactions go from “What is a spike?” to “Don’t need it, I know what I’m doing” (smarty-pants me would often think like the latter).
Now, what is a spike? Defined by Robert C. Martin, AKA Uncle Bob, in his book Clean Agile: back to basics: “A spike is a meta-story, or rather, a story for estimating a story. It is called a spike because it often requires us to develop a long but very thin slice through all the layers of the system”. In my words, a technical research task to discover the implications of an implementation.
“Life can only be understood backwards, but it must be lived forwards”
~ Soren Kierkegaard
Let’s explain it with a straightforward example
Consider this user story:
“As a user, when I click the share icon, I want to be prompted to share <content> to Twitter, Facebook, or LinkedIn.”
In retrospect, things are obvious. Second-order thinking would lead to the following questions
- How do I share content to Twitter?
- How do I share content to Facebook?
- How do I share content to LinkedIn?
That’s what reason says, but in reality, we tend to jump into an easy first-order thinking solution that requires no effort from our brains. We will not only provide quick estimation but even a plan for implementation, first Twitter, then Facebook, then LinkedIn in an arbitrary number of days for whatever reason. This linear approach fails at recognizing differences and similarities between the different platforms only to discover them while implementing.
Running a spike would require us to answer those questions with a lightweight, functional implementation, and a very simple document describing our journey to accomplish the task.
I do not recommend to ask people to fill templates, they should rather feel free to tell the story however they like, as long as it’s clear, but if you don’t know where to start, here is my baseline:
What’s good about running spikes?
By isolating uncertainty, spikes give us the opportunity to uncover issues before they happen, that means we are operating on second-order thinking related work, and addressing its consequences. Spikes are useful for problems that require us to detach complex business logic from its technical implementation.
It doesn’t matter if your target is to share beautiful kittens or complex physics work, the sharing mechanisms are the same, in other words, spike complexity remains static and will not change over time, we cannot say the same about business requirements.
By detaching business logic to understand tech, its scope, constraints, benefits and tradeoffs we keep business requirements in our brain’s background process, which will naturally lead us to the “what if” questions that would otherwise happen in the middle of a sprint when there is no more time available.
Also, spikes are fun. We enjoy immersing ourselves into the matrix, with nothing else to think about, it feels like a breath of fresh air when you have three days to stop worrying about everything else and focus on a piece of tech.
Considerations
It is essential to establish limits. Problems, just as work will expand to fill the time available, in my experience, three days are enough to explore any well-defined spike and come back to the business with good questions and a better understanding of the implications.
Spike code is not for copy-pasting to your codebase, I recently heard an Engineer I admire, the kind of person with more than 30 years in the industry that still solves problems by coding, say that in his experience a system will become quite good after its 3rd or 4th rewrite. Consider your spike code as something disposable that served its purpose at teaching you something.
Conclusion
Spikes are not about having doubts on your knowledge and experience, but about asking yourself, “How do I know I’m right?”, it doesn’t mean we will stop making mistakes, they will at least be more informed ones.
What to read next?
