February 26, 2019 • ☕️ 2 min read
Human beings work on the basis of low complexity but high risk situations. This is our natural state as dictated by nature. Software by oppoisition is high complextiy but low risk.
Over my career of 10 years as a software developer Ive noticed a trend with those that I consider to be successful and ive often been told that success leaves clues. The trend in question was a air of fearlessness when it came to failure, and failure in terms of deploying software specifically.
Though, what does failing forward look like? I mean, can it be done in a productive sense so you don't frustrate your co-workers? Saying to someone, "Hey, failing forward is the key" is all fine and dandy, but what happens when you fail forward and shit can production?
The truth is, failing forward is an exceptionally difficult paradigm to follow because its basically frowned upon for business value. Up time counts, user satisfaction counts, quality counts. Over time, the pattern of failing forward may have become apparent to me, but a dark pattern also came with it; pretending you don't. No one wants to admit they fail forward, it shakes confidence.
So, if failing forward is at such odds(useful but dangerous), how can we implement it as a viable delivery model?
The answer is timing.
Timing is everything when you want to continue delivering progress to any application. You need to time you releases in line with who its going to affect. This can be done effective with a mind map of the associated expense of the release in terms of possible burden generated.
Does this affect all devs - Very expensive Clients - Could be so expensive it costs the whole company Frontend devs that are progressive - Not that big of a deal
And so, you realize that failing forward is playing a dangerous game with a production application as you have the potential to cripple things in one move but in order to make progress, you need to push these fears aside and get better at your release timing.
A lot of the associated risk of failing forward can be done away with via a reactive team. If you and your team are extremely capable at reacting to issues on the fly, you can safely absorb any generated cost from a well timed release.
My thoughts are echoed by one of my developer heros:
Personal blog by David O'Regan. I explain things with words and code.