People get mad at the Fedora Project all the time because something important to them fails to work. “It used to work, it worked for a long time, and now it’s broken!” They look at an idea that we tried out, failed, and learned from, and don’t understand how we could let that get in to a release.
This comes up in my house, with my daughters and wife, who hate to fail. HATE IT. I know where this comes from. Even when you try your supportive best, it’s easy to focus on the success and the praise. How often do we praise failure?
I’ve been telling them, telling Fedorans, telling anyone who will listen that the secret to our success is in fact our failure. You cannot learn without failure. Even when you dock a massive fail boat, you at least learn after all is done what not to do next time.
Last night I caught a shortened version of a Honda documentary, available here on youtube.com (or search here.)  The moment in the video that grabbed me initially is Indycar driver Danica Patrick talking about racing:
You’re driving your car and you feel frightened a little bit. We bump up against that feeling as much as we can to try and push that limit further, and get comfortable there, and then push it again, so, you know, you’re constantly on the brink of crashing because that’s the fastest.
In an engineering-oriented organization such as Honda, “Failure is a by-product of pushing the envelope,” as one engine designer puts it. It’s a culture that goes back to the organizational founding, as explained by Takeo Fukui, President and CEO of Global Honda, when talking about Soichiro Honda’s ideas of trial and error. “We can only make fantastic advances in technology through many failures.”
What we do to make free/libre and open source software better is a rapid a process of fail, learn, succeed, push the envelope, fail, learn, succeed, push the envelope, ad infinitum. Fedora happens to be particularly good at this, more willing than some, more like Danica Patrick, to be frightened, get comfortable, then push the limits again.
(Post updated with spelling correction and being added to the Red Hat category.)
(Post updated with new links to video, as previous links had expired.)
Basically “throw a lot of stuff at the wall and see what sticks”.
Assume any given person’s failure rate is about 60%.
If you just throw one thing at the wall, that’s kind of scary. If it’s a lot, that produces a lot of successes. The failures don’t matter.
Somewhat similar to Edison’s “I didn’t fail, I just found ten thousand ways that didn’t work”. Which is right, except for the part about shocking elephants.
Structures that don’t allow failure and experimentation are the ones that need fixing, because they’ll just produce minor variations on what already exists.
Ah, I see they quoted that 🙂
Yeah, it was a nice visual/design wrap-up to, “Why all these hanging lightbulbs?”
So the other side of the failure is measurement – what are Fedora’s measurements? How do you know when you’ve gone from an experiment that’s failed and how do you learn from it?
For example, let’s just say there’s a perception of a decline in hardware compatibility. What metric do you have in place to be able to measure that? How do you know you’re getting better or worse over time?
[…] : http://iquaid.org/2009/02/28/failure-as-the-secret-of-success/ Posted by Frederic Hornain Filed in FOSDEM, Fedora, Management ·Tags: Linux, Management, […]
Great! This is true, totally agree.
And I have an extra advice, please, if you fail learn about it, as you say. I’m telling this because there are some people who fails and always try (and find) somebody else to blame, if you fail and blame somebody or something else, then you didn’t learn anything.
Regards.
Thanks for the plug, Chris. That is exactly the purpose of the Community Architecture team. As you know, those are hard metrics to track. In addition, from a community buidling angle, I’m not sure I’d track hardware compatibility. That is really the purview of QA. Our role is to make sure there is a thriving QA community who are enabled to track such metrics and do something about it of their own free will. So, for this purpose, we are hacking on EKG as a starting point for tracking community health.
That said, it is a problem that we don’t have such a discipline across the entire distro. Perhaps a continued focus on QA and learning from failure might attract some new folks interested in that sort of QA management.
I neglected the advantage of failure sometimes, but I learn something from your artical, more would be learnt if I can understand all your sentences (I’m a biginner to learn English, so pardon me for a couple of grammer mistakes), and I just want to ask you a silly question –what are the title “i, quaid” means?
I was stepping by by accident, I’m a chinese student who are preparing for the English debate about failure & success, and some of your viewpoints and words do really help me a lot, and thank you for your kindness words!
And it’s about 12:24pm in my country now, but it may show another time in your country.
Thank you!
sorry, it’s me again, i relize my question is really silly when i saw your name is quaid. I learnt a new english name anyway.
I understand. I have experience writing for translation, but I do not try to do that in my blog. I enjoy letting the words just flow from my mind. 🙂
As for the title and sub-title of this blog, it is a reference to the famous Isaac Asimov story collection, “I, Robot“.
It is even more confusing because it is a nickname (a ‘nick’) that I use only online. However, Quaid is a name in English, most usually a last name (family name), and probably comes from a Scottish name that dropped a prefix. Original spellings would have been McQuaid, McQwayde, or even possibly McWade? The spelling differences are because the names are from Gaelic dialects and are translated in to English (Roman) characters.
Many Gaelic people (Irish and Scots) dropped the prefix on their family name when migrating to the United States in the 1800s and early 1900s. This was done to make the name sound “less Irish” because there was enormous prejudice against immigrants from Ireland.
[…] open source, release early release often Great post by Red Hat’s Karsten Wade on the role of failure in Fedora (and in life). One of the key tenets of both the open source and design thinking movements is the […]
[…] me and Fedora out of our comfort zones. The result could be failure, but that is not all bad. Karsten had a good post on failing often. The January 2010 issue of Wired had a cover story dedicated to the benefits of […]
I’d give my left NUT for a failure rate of 60%