Can the journey be more valuable than the destination?
In the quest to continually increase the speed at which we deliver software to customers, there seems to be an unfortunate casualty in the race, the journey. The journey is not something that we can easily see. It is meandering and only lightly sign posted. To many, it is something that has no value, the only thing that matters is the destination. The all consuming idea that we must get somewhere in a hurry. As such, we do not take the time to look back at the journey we have taken, nor do we appreciate it while we are on it. In rare cases we look at the journey with contempt and annoyance.
A number of incidents recently got me thinking about this “destination” focused mindset. Thinking about how blinded we can become as an industry, as we jump from one destination to another. Leaving so many rich journeys in our wake. While thinking on this I was reminded of a great talk by Alan Watts on the nature of life and the analogy we draw with a journey. While he disparages the analogy, there is a lot to be taken from it.
Applying a mindset like this may seem like a heresy to the modern Agile philosophies. We are supposed to have a vision, a clear roadmap of where we want to go and an exact point that we want to get to. There is no room for play, for distraction. However in reality, that is exactly wrong. When we set out to write a new piece of software, we are often completely unaware of where we want to go. We vaguely know the problem we are trying to solve but the journey of how we go about solving it teaches us much more than the eventual solution. We can learn who our customers are, what they really want, what the problem is beneath the one we think we are solving. If we are really attentive, we can learn what moves us; as a team, as an organisation or even a company. If we go completely off script, we might even play along the way.
So it is lamentable that so many people now forgo the journey, they are only interested in the destination. The success of completing the feature, the praise of another release successfully delivered, another defect found and resolved. But with this rush to succeed, we miss so much of the true value in being software developers. We miss the dance.
Shortest path to Production
This is one of the mindsets that I have started to see more and more from developers; “Can’t we just skip this testing environment? This process is unnecessary! We just want to get it to PRO! It’s important for the next release!!”. These are symptoms of a rushed system. Anything that is seen as an impediment to getting code to production should immediately be cast aside, as it is “slowing us down”. Nobody has the right to slow us down! Despite the fact that much of it is our own design causing the delay. This comes as a result of operating at a completely unsustainable pace, where teams are taking on more work than can reasonably delivered. Still, we must not be impeded! This code must get to PRO! Today!
Every time that question is asked, the answer is always the same. “Because! It has to!” Someone committed to it. No idea who or what they were smoking at the time but they did. So now we have to make it happen. We must reach the destination!
Yet when “impeded” enough, when the release is missed, the functionality not delivered, the destination not reached. The world does not end. The people who were promised the functionality are told it will be late. They will get frustrated, shout, slam fists, then they calm down and see the reality of the situation. Yet the teams do not, they continue to scramble. Straight back to the rat race! We missed the last release, so now we have to do double time for the next one. Even though we are already doing double time from the previous one, so… quadruple time?
The journey that is missed with this mindset is a simple one. We miss the fact that our testing environments are where we should learn whether our code is worth releasing in the first place. Too often the mindset is that we can only learn something when code is in the hands of the customer, when it is in Production but that is not always true. We can learn many valuable things, long before then. Things like a technology is not sustainable, it has too many issues to be scalable, it is slow, unresponsive and maybe we should look at alternatives. We don’t need to go all the way to PRO with it to determine that, we can make the same decision in DEV if we want. But we don’t! Because once a decision is made, once a path is chosen, we have to see it all the way to the end. Regardless of how short sighted or wrong it is.
We have lost sight of the idea that we should be continually evaluating whether an idea is good or not. This should be done the whole way along the journey. If you are on a road and you see a blazing fire ahead, you do not keep going. You change direction, stop or even reverse. You make continual little course corrections. Sometimes that changes the destination, but if the destination is on fire, maybe that’s a good thing?
The same mindset also affects defects. We are not interested in the journey of a defect. Just fix it and get back to work! Do not invest the time to understand it and try to mitigate it in the future. Just find the problem and resolve it. Turn it off and back on again. Sorted!
I’m currently finishing an insightful book that looks into this mindset in depth, Turn the Ship Around. In it, David Marquet talks about how in the beginning of his journey his ship was all about avoiding errors. They would only do the bare minimum, keeping their heads down and trying to go unnoticed. When he began to change the ship, the focus became operational excellence, to take learnings from every mistake as a way to improve the running of the ship. Too often we fall into the same trap in development. The culture becomes fixated on how good we look, rather than being curious about how we can use mistakes as a way to strive towards something better.
A rather topical example of this cropped up as I write this, from everyone's favourite president.
In this clip Trump states that he would rather have people stay on a cruise ship, risking further infection and potentially death, than have them come onto US soil and have the US infection numbers go up. This resonated with me quite deeply, as I see this on a daily basis. Teams happly bat defects around, so that their numbers look good. Rather than take responsibility and look into something, running the risk of potentially failing, they would rather leave it to someone else to resolve.
One of the earliest crusades I remember in my career was on exactly this, The Dangers of a Metrics Driven Culture. Where playing a numbers game can drive rational people to do irrational things, as they are only interested in meeting the metric. When pinning your culture on a metric, you had better pick a good one.
Better yet, we could focus on the journey. What can we learn when we find a defect? What did we miss? How can we do better next time? Is there a bigger issue at play here? If I take a step back, can I see a pattern? Too often we don’t take the time to ask, let alone answer these questions. When pressed on why teams keep fixing the same issue over and over, why they haven’t been able to root cause and resolve the issue completely… “Because! We’re busy! We’re in a rush to get to the destination!” The magical place where everything will be fine and there are no more issues. However this place does not exist. They’re just going in circles but too blinkered to see the repeating landmarks.
Focus on the Journey
Every time we aim at a destination, we inevitably find that it is not what we expected. It has some shortcoming that we did not forsee. The grass is not the right shade of green. So what do we do? We set our sights on a new destination. Better, greener, with all the benefits this miserable destination lacks. In travelling to the new destination we pass many of the same warning signs from the previous journey but because we had no interest in it then, we ignore them, again. Annoying impediments that we must remove from our path, to our destination!
Thinking back to a time before this endless sprinting, we used to take journeys. We used to try things out and see if they worked. It had its flaws. A lot of money was wasted on aimless, over-budgeted projects that didn’t produce anything, but from those journeys at least we learned something. We had the breathing room to take some nugget of wisdom into the next journey. Today the focus is so destination driven that we are cheating ourselves of any possibility to do that. But the journey can be reclaimed.
We can make more time for Spikes that may or may not go anywhere. Just a short journey down this road, to see what is at the end. If it’s nothing I’ll come back and we can keep going towards the destination. If there is something worth seeing, maybe we can take a detour to the destination?
Make more time for play. See what you do as playing software development, not working it. Be the composer that writes a beautiful symphony, not the one that writes that single perfect cord. Make time to hone your craft, practice the skills you enjoy and take pride in learning new ones.
Share your journey. Even when we are blinkered towards a destination, something beautiful can flicker across our path. When we find ourselves in those moments, we should stop to appreciate it, sharing it with others around us, so they can see what journeys are out there.
At the end of the day there is only one destination we are all heading towards, the final one, so why not enjoy the journey along the way?