Failing fast for fun and feedback

Here’s a wonderful anecdote about aeronautical engineer Paul MacCready who built the first successful human-powered airplane and in so doing won the first Kremer Prize. I’ve seen this story told in many different outlets¹ since I learned about it; it appears the original popularizer was Alan Kay.

The story goes like this. MacCready became interested in building a plane that could fly using only human power (his winning design was essentially bicycled by the pilot). Of course, people were working on this already for years, chasing the prestigious Kremer Prize, so what could he contribute?

MacCready’s insight was that people were solving the wrong problem. To create a human-powered aircraft they were trying to create human-powered aircraft! The right problem:

Create an aircraft that can be rebuilt quickly after being destroyed.

MacCready saw other teams working on their planes. They would take 10–12 months carefully theorizing, designing and building their aircraft, fly it, after 30 seconds or a minute it would crash, and they would spend another 10–12 months working on their next design to get another 30–60 seconds of data. MacCready set about designing a plane that he could crash over and over again. Crash and rebuild. Crash and rebuild. Everyday.

Now MacCready and his team are gathering data far faster than any other team. And they can iterate, quickly, honing in on the eventual working design.

I love this anecdote because it’s so cool but also because it has two keen insights. The more obvious insight is that feedback loops need to be tight. Make those loops as tight as possible to keep pushing through your failures to get to a success. If you’re trying to design an algorithm, say, or test a theory, and it takes days writing code for each change you want to test, you may never find the solution. So put the time in so you can turn around your tests in minutes.

The second, more subtle insight is on picking the right problem. The obvious problem (to create a human-powered airplane we need to create a human-powered airplane) may be predicated on a non-obvious problem (to create a human-powered airplane we need to create a plane that is easy to rebuild after crashing). A simple twist of insight can unlock a profound solution.