Fail Fast, Fail Forwards

To walk we have to lean forward, stuff lose our balance, and begin to fall. We let go, constantly, of the previous stability, falling, all the time, trusting that we will find a succession of new stabilities with each step. The fullest living is a constant dying of the past, enjoying the present fully, but holding it lightly; letting go without clinging and moving freely into new experiences. Our experience of the past and of those dear to us is not lost at all, but remains richly within us. – Robin Skynner

In my practice, I use the phrase “No plan survives first contact with reality” to help people understand that no matter how many details you pack into a design, the universe is proficient and diligent in showing you exactly where the weak points are in your system. Life is chiefly about recovering from non-optimal situations and outright failures.

This is ok, it’s part of the process, and you can’t prevent it. What we can do, is control the damage these failures take.

running_man

Fail Fast

The worst sort of failure is when a large and trusted piece of your process lets you down unexpectedly. If something is going to break, we want it to break on or near deployment, not 3 months form now when we’re dealing with some other issue. Right now, when the component or plan is fresh in our minds and we have the interest and focus – that’s the moment we want a thing to fail.

I was recently working with a group that had a automatic server failover component to their product offering and through a subtly related bug report, they discovered it didn’t work in many cases. There had been tests in place for it for months, but those tests weren’t rigorous enough, so the first time they discovered this problem was during a client emergency. In addition, none of the team that had originally built the system was immediately available. 4 projects had to be put on hold as the original team was reassembled and the server taken apart to find the flaw – creating schedule slips throughout the entire organization, and causing impact for months to come.

It’s important to test things rigorously, and to make them break as early in the process as possible.

One spring, I built a chicken coop; 8 months later, the roof collapsed during a strong snowstorm. It was a bad moment – I not only had to deal with the primary effects of the blizzard, but I also now had to play house-builder, doctor, nurse and undertaker to a number of chickens in different levels of distress, while wading through 4–6 feet of snow. It was costly and unpleasant, and if I had discovered the flaws in my design in May when I built it, I wouldn’t have had the problems I did.

When I rebuilt it, I invited a number of construction-minded friends over to not only give input and help construct it, but then to have a cookout and generally raucous party on top of the henhouse. At the end, we took a front end loader and gave it a good downward push to determine if it really was strong enough to handle the 5–6 tons of snow it was expected to manage in a worst-case scenario. I wanted that thing to break now, if it was going to, when the experts were standing there, and the weather was nice, not when I was alone in the snow again.

Fail Forwards

When something does break, or just doesn’t do what it’s supposed to, do some forensics. Don’t chuck it in the garbage and start from scratch, or give up on the whole idea. We want to fall forwards, like British psychotherapist Robin Skynner suggests above.

Improvement requires iteration. Improvement requires practice. Improvement requires feedback. None of these critical parts of the learning process can happen when you succeed at something quite as effectively as when something fails catastrophically. To improve, we must risk and fail, and every failure must be recognized for what it is: an opportunity to improve our abilities to recover and design.

We can make this process easier – a design can be built so that when it fails, it fails in a certain direction. Chopping a small wedge in a tree in exactly the direction we want it to fall allows us to be liberal with the chainsaw and still know where it will wind up. That small chop is design and planning, the chainsaw part is just rendering our design.

Fail Small

One of the permaculture principles is to act “small and slow”. For such diminutive words, “small” and “slow” hold a lot of weight in my life. I’m always looking for the minimum. The minimum viable product, the minimum viable client, and absolutely the minimum viable change.

The smaller our failures, the quicker we can test, recover and learn from them. But how big can we go and still be making small changes? How small can we go and still be making our efforts worthwhile? How slowly do we go – how long do we test before we deploy?

I admit to erring on the big side of small and on the slothful side of slow. I want to launch big plans, and I struggle to keep them minimal. And I tend towards overthinking, which means I don’t want to launch until I’m in the 98% category. That’s too late!  Launching a change or a smaller project at 80% perfection is a much faster way to get to that first failure, and by extension, that first feedback you need to improve it.

“Small” and “slow” are not easily calculated values. They differ by the project, by the implementor, by the season, by the budget and by the expectations and constraints of outside forces. My best advice here is to always be aware of the tendency to go big and fast and actively apply the pressures of small and slow.

Stack Functions

Failure mitigation is probably the biggest reason for stacking functions. When every functional need of a design is covered by more than one component, and every component provides more than one need, we wind up with deeply integrated and redundant systems. Systems integration and redundancy are pretty much always good things.

That hoop house you built uses PVC pipe as the main supports? Since it’s there, why not make it into an overhead drip irrigation system? That provides backup for primary watering, raises the thermal mass, and increases the weight, potentially making it less likely to fly away in a breeze.

In a business, we cross-train for this very purpose. When one function can be provided by multiple people, an organization gains resiliency and stability – and provides the possibility for one member to transition into another role without leaving a gap. When one person can fulfill many roles, they are more valuable, better integrated and capable of providing effort and resource where they are needed most.

All of our processes can adopt this mentality of function stacking – try to eliminate uni-taskers, and bring in elements of design that serve multiple functions at once. In a well-rounded design, each required function will be covered three times, and each component will provide at least three functions.

Plan for Failure

Hope for the best, but plan for the worst.

The only time “is the contract it signed” matters is when the whole thing is in flames – usually because of mismanagement by you, or by not weeding out a criminally insane client. Having good agreements can be seen as an indication of distrust – but it can also be seen as professional recognition that stuff happens; things break, including communications and expectations.

Back to the chicken coop, I luckily had a barn with space in it to temporarily house the survivors following the collapse, and I had experience dealing with injured critters. Broad-spectrum understanding peripheral to a project can act as cheap insurance during a crisis. So is spare resource, like an underused barn. If it were full to capacity, I’d have had less flexibility to deal with the emergency.

Set them up again

We started talking about iteration, and I’ll repeat it again – and again and again and again. Iteration, the deploy->analyze->improve->deploy cycle, is core to building resilient and long-living designs that people are able to align with and find useful. This same philosophy works internally, as you and I are also are constant works in process. Every morning we wake up, ready for another iteration, another day full of growth, of change, and yes, of little failures; the “constant dying of the past” that allows us to enjoy the present fully.

Principles

Scott is a multidiscipline technologist and problem wrangler. His day jobs include writing code for mid-size businesses and startups, consulting on business process for young companies and organizations, and applying permaculture design philosophy wherever it’s appropriate.

Scott is available for limited consultation on a myriad of topics. [email protected]

Leave a Reply

Your email address will not be published. Required fields are marked *