Don't Fear Failure, Just Fail Fast

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

Ordinary wind power requires too much equipment and money. The higher the altitude, the easier it is to increase power generation, but naturally the cost rises proportionally. However, when he overcame that challenge and reported to Larry Page that the prototype had worked reasonably well, Larry reportedly said, “Immediately build five more of the same thing and test them all until they break.”

The meaning behind this is that breaking things speeds up learning.

There’s an extremely realistic implication here.

You calculate the strength before building a bridge.

Of course calculating is normal. There’s surely no exception to this.

But in reality, the next step is to build a miniature and test it — to break it.

For bridges there are plenty of precedents, and the theory is nearly settled. The unimaginable troubles have probably all been exhausted already.

Even so, everyone still accepts that you test before building the real thing.

Now, what if the proposition were “something no one has ever tried before”?

How much can you trust theoretical values, simulations, and assumed cases?

The steady work of crushing them one by one is certainly one facet of engineering, but that’s simply too slow.

What’s the quick solution?

Just go ahead and fail for now.

You can learn an enormous amount from failure. Any engineer knows this.

Bugs slipped in right before production start, exception handling you kept meaning to fix but left alone, insufficient heat-resistance evaluation, use cases outside the assumed specs, and so on.

Failure teaches you many “things you must not do” and their “typical solutions,” and the accumulation of these eventually sublimates into the irreplaceable asset called “instinct.”

How many years, how many products, does it take to get there?

Ugh, this is a pain, just go fail already!

This can also be seen as extremely logical thinking, on the other hand.

As is often said in various forms of argumentation, proving that something 100% does not exist is impossible in most cases.

Exhaustively verifying every exception case is extremely difficult.

In other words, “prove that no counterexample to XX exists!” is, in a sense, a trap — an irrational, unproductive line used in discussions, usually loaded with malice and aggression.

Something similar can be said about development.

It’s impossible to guarantee 100% that there’s no possibility of failure. And nothing wastes more time than pursuing that to the end.

But on the other hand, it’s also true that everyone gets uneasy if all you say is, “Theoretically this should work, so, um, let’s just go for it!” “Theoretically” and “ideally” are, in many cases, weak against exception cases, and in reality there are always several pitfalls. People sense this intuitively.

What usually supports you 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 is relatively low, I think.”

That sort of thing.

But now, what if the subject is a completely new domain, one where no one is truly an expert and no one has ever succeeded before? This is the same question as before.

In that case, it seems like a perfectly reasonable, good approach to first go ahead and fall into those pitfalls a few times, then build your development process by saying something like, “There’s a fairly serious pitfall here, a few small ones over there, and traces of what looks like a pitfall beyond that. So I plan to proceed along this particular route.”

Naturally, exhaustive coverage of exception cases is nowhere near complete, and in some cases theoretical verification may be insufficient too. But if the developers have already discovered the notable pitfalls and learned how to recover from falling into them — or how to avoid them in the first place — then, needless to say, their ability to resolve new troubles, and even their ability to sense trouble coming, will be dramatically higher when new problems arise going forward.

The result is that you end up building the best thing at the fastest speed.

At first glance it looks reckless, at first glance it looks like an outrageous argument. Normally, saying “we’re going to break it” would never get a budget approved.

But that is precisely the method by which “a newcomer beats the old guard,” or “the fastest way to reach unexplored territory,” or “the way to create something from nothing.”

This might be a relatively unfamiliar approach for a delicate people like the Japanese.

But think about it: no child starts by “studying” Lego. Yet after a bit of cutting and trying, they’re suddenly able to build things. And those who learned things that way effortlessly surpass adult thinking. Everyone knows this very, very well.

Finally, what Astro Teller said about what’s 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.