Quick release cycles and quick failure

Notes to self:

The Value of Failure (?)
I’m never quite satisfied when I participate in discussions about the value of failure. I’m not sure why, but I think we’re missing something here. Not sure what it is. “Yeah, yeah, yeah. Fail quickly. You’ve got to fail to learn.” What does that really mean in practical terms?

Failure and quick release cycles
I think these people (in the video, above) are approaching quick/early failure in a very (literally) constructive way. They walk out onto a field with an airplane made out of foam core, toothpicks, and packing tape; they fly it and crash it and adjust it five or six times; and they leave the field with a much better plane than what they started with.

Notice:
a) Their plane is built to be hackable. It’s made out of foam core. At 4:00 the pilot says "maybe we should try getting rid of this forward sweep" of the wings and he gets out his knife and he cuts off the front of the wings and tapes them to the back. Earlier in the video he decides he needs a bigger vertical stabilizer on the back so he cuts a rough square of foam core, tapes it to the side of the old stabilizer, and pinches the leading edge to make it more aerodynamic. Then he launches it to see how it worked.

Says the pilot/engineer/hacker (at about 5:45):

“So, we came out and it was too tail heavy. so two crashes later we figured that out. Then we put a bigger battery on it. And then we figured out there wasn’t enough vertical stabilizer, and we fixed that. Then there was too much ‘magic carpet’ going on–too much flex–so we put some tape on it and fixed that. Then cut the front of the wing off and put it on the back of the wing, which got rid of the wing rock. Now, with model #1, we got probably five airplanes worth of test flights. ”

b) This brings to mind Stuart Brand’s book “How Buildings Learn: What Happens After They’re Built” which (among other things) describes the benefits of building things in a way that makes them easier to improve and modify over time.

c) Another thought: the people in the model airplane video are able to fail/improve quickly because their platform supports rapid releases and quick fixes. (Does my web publishing platform, writ large, allow/support this? Not really.) If their plane were “better” - - if it were made out of fancier materials and looked more polished - - i’m guessing it would be a lot harder to modify and hack.

d) Years ago I saw an article somewhere about designing high performance sailboats. The author said that phenomenal things could be done in the design phase with computer modeling, but that the models were never perfect. For $100k you could design a cutting edge boat with advanced hydrodynamic modeling, or for about the same amount of money you could skip all the hydrodynamic predictions and just build the actual boat and see how it sailed (which, after all, is the ultimate point of the exercise) - - if it wasn’t particularly fast (usually the case) you could sell the boat for cost and try again.

Faster, NASA, Faster, a 2009 NY Times Op-Ed by former astronaut and Google program manager Edward Lu, encourages NASA to adopt a space vehicle strategy that emphasizes smaller but more frequent launches- - as many as one a week, for reasons similar to those used by the model airplane enthusiasts in the video.

The Russian Soyuz rocket demonstrates the value of frequent launching. Variants of this rocket have flown more than 1,700 times, averaging more than 30 launchings a year. As a result, the Soyuz is among the most reliable of all existing rockets. In fact, I flew into space aboard a Soyuz rocket in 2003 when NASA space shuttles had been grounded after the Columbia disaster.

To meet its new goals for human spaceflight, NASA must be able to be creative and take risks, or else it will be unable to adapt to new technology and changing political realities. Grand plans stretching over decades will become irrelevant and eventually collapse.

(Lu’s NY Times op-ed is also useful for .gov employees trying to understand how to operate with greater agility in a highly bureaucratic environment.)

I’m also remembering a conversation I had with the CEO of a New Media/Technology design agency: he said that the big trick isn’t failing, that’s all too easy to do. The trick is building the skills you need to learn from those mistakes, and to recognize breakthroughs and progress when and where they do occur (which is usually when and where you’re not looking).

Another good reference on the “failure” question is We Tried To Warn You, Part 2: Failure is a matter of timing by Peter Jones in Boxes and Arrows, 2008.

There’s also a Harvard Business Review article I’m looking for about how top performing businesses are better at exposing, discussing, and sharing lessons-learned from past failures than the also ran’s are.

My paper Good Projects Gone Bad, an Introduction to Process Maturity from the American Association of Museums conference in 2008 might be helpful too.

And a search on Nina Simon’s Museum 2.0 blog for articles relating to “failure” yields some gems.