Don't Fear Failure, Just Fail Fast

From Astro Teller’s SXSW talk at Google[x].

There was an interesting moment when he talked about a project to generate wind power by flying kites.

Conventional wind power requires too much equipment and money. Generating power gets easier at higher altitude, but naturally the cost rises to match. When he’d worked through that challenge and reported to Larry Page that the prototype had performed reasonably well, Larry’s response was “build five more of the same thing right away and test them until they all break.”

The point is that breaking things speeds up learning.

This carries an extremely realistic implication.

You calculate the strength before you build a bridge. Of course you calculate it first, that’s normal. There’s no exception to that, surely. But in practice the next step is to build a miniature and test it (break it). Bridges have a huge amount of precedent behind them, and the theory is nearly settled. Every imaginable failure mode has probably already surfaced somewhere. Even so, everyone agrees you still test before building the real thing.

But what if the proposition is “something nobody has ever tried before”? How much can you trust theoretical values, simulations, and assumed cases? Knocking down each exceptional case one by one is certainly one facet of engineering, but it’s far too slow.

What’s the quickest solution?

Just go ahead and fail.

You can learn an enormous amount from failure. Any engineer knows this. Bugs slipped in right before launch, exception handling you kept meaning to fix but left alone, insufficient heat evaluation, use cases outside the assumed spec, and so on. Failure teaches you many “things you must not do” and their “typical fixes,” and accumulating those eventually sublimates into the irreplaceable asset called “instinct.” How many years does it take to get there? How many products do you have to build?

Enough already, quit dawdling, go fail already!

This is also, in its own way, an extremely logical way of thinking.

As is often said across various forms of argumentation, proving that something 100% does not exist is impossible in most cases. Exhaustively covering and verifying every exceptional case is extremely difficult. In other words, “prove that no counterexample to XX exists!” is in a sense a trap, and in discussions it’s typically an irrational, unproductive line thrown out with extra malice and aggression.

Something similar holds for development. You can’t guarantee 100% that failure won’t occur. And nothing wastes more time than chasing that guarantee to the bitter end. On the other hand, everyone gets uneasy if all they hear is “theoretically this should work, so, um, let’s just go for it!” “Theoretically” and “ideally” are, in most cases, weak against exceptional cases, and plenty of pitfalls lurk beneath them. People know this intuitively. What usually reassures people at such times is “experience” or “track record.” “If we leave it to so-and-so, it’ll probably be fine.” “Given his track record, the risk seems relatively low.” That kind of thing.

But what if the subject is a completely new domain, one where no one is truly an expert and no one has ever succeeded before? That’s the same question as before. In that case, the reasonable approach seems to be falling into those pitfalls a few times first, and then building the development process by saying something like, “there’s a fairly serious pitfall here, a few small pitfalls over there, and traces of what looks like a pitfall beyond that, so I plan to proceed via this particular route.” Exhaustive coverage of exception cases is naturally nowhere near complete, and depending on the case theoretical verification may also fall short. But if the developers have already found the notable pitfalls and learned how to recover after falling into them, or how to avoid them altogether, then their ability to solve new troubles as they arise, and even their ability to sense trouble coming, is dramatically stronger for it.

The result is building the best thing in the fastest possible time.

It looks reckless at first glance, it looks like an outrageous argument at first glance — normally no budget gets approved if you say “we’re going to break it.”

But that is precisely how a newcomer beats the old guard, how you reach uncharted territory at maximum speed, and how you create something from nothing.

This may be a relatively unfamiliar approach for a delicate people like the Japanese. But think about it: no child starts by “studying” Lego. Yet after some amount of trial and error, they’re suddenly able to build things. And those who learned that way effortlessly surpass adult ways of thinking. Everyone knows this very, very well.

Finally, what Astro Teller said was needed “to make the world not 10% more convenient, but 10 times or 100 times more convenient”:

“Creative, Productive and Failure”

Originally published in Japanese at https://clazytech.com/2015/05/97/. Translated with LLM assistance and reviewed before publication.