Comments on: Built to Fail: How companies like Google, IDEO, and 37signals build failure-tolerant systems for anything!

By: modular homes

modular homes — Wed, 25 Aug 2010 16:52:08 +0000

Building up processes based on the ideas above makes it easier and easier to deal with failure and come out on the other side!

By: modular homes

modular homes — Thu, 01 Jul 2010 15:59:49 +0000

hello i think there are more helping info which is help people!

By: Bryan Zmijewski

Bryan Zmijewski — Wed, 13 Jan 2010 10:30:20 +0000

…little late to this post, but I was on the Skyline team (acquired by IDEO) that came up with those 12 ideas each year

In my three years, I was involved in about 40 ideas that got licensed and probably 15 that made it on the shelves. If you counted all the ideas that we came up with that never made it to a sketch, we probably had over 20,000 ideas. I'd say the hit ratio is even smaller!

By: Bryan Zmijewski

Bryan Zmijewski — Wed, 13 Jan 2010 03:30:20 +0000

…little late to this post, but I was on the Skyline team (acquired by IDEO) that came up with those 12 ideas each year

By: sumomo

sumomo — Sun, 03 Jan 2010 04:31:43 +0000

excellent article, you made my day, i'm a teen, and i learn more from this one page of interesting ideas and concepts than the 1000 page of boring history book that is required.

you know what, the educational system in America needs a REALITY CHECK.

By: Kevin Shaum

Kevin Shaum — Sun, 27 Sep 2009 00:26:50 +0000

I think you are mistaken about what the term "fail fast" means:

http://en.wikipedia.org/wiki/Fail-fast

By: Phil Simon

Phil Simon — Tue, 08 Sep 2009 09:01:34 +0000

Interesting post. I have a few thoughts. Failure is probably more tolerant at Google than other organizations because they have so many things going on. A problem with a Okrut or Google Maps might be inconvenient, but it will hardly tarnish Google's brand. Plus, Google's apps are so widely used in many cases that problems will be discovered and fixed relatively quickly.

Also, as Cedric mentioned, Google's 20% policy is huge. In a way, they bake failure into the culture. Relative to other companies, at Google there doesn't appear to be the blamed placed on those who tried and failed.

However, for a large organization in the middle of a massive IT project affecting supplies, employees, or vendors, failure may be less acceptable. The consequences can be so severe that it affects employees receiving paychecks, corporate security, the accuracy of financial reports, and the like. This is particularly pronounced in development efforts that follow the Waterfall method.

If adopted, methodologies like Agile software development should decrease failure rates. Of course, people will ultimately determine whether these projects fail much more than any methodology or technology.

By: woodka

woodka — Tue, 28 Jul 2009 18:12:41 +0000

A waterfall model with iterative design-build-test rapid prototype built within it can work well, especially if everything is well documented. For instance, design with user interface models to determine what interface a user likes and features needed, then move on to the build cycle to build the actual system, loop back into design if you need to. Keeps you from building things before the user knows what they want, and lets you go back to change things as needed. But still move through the waterfall steps as you go. It also helps if you ALWAYS build in testability and use a very modular design. Have standard code pieces in the library once verified so you're not reinventing wheels. This does take a lot of discipline, and what I've found doing software process consulting is that a lot of those who dis software engineering models like waterfall simply have never worked in a well-structured software environment. Once they're introduced to a good process with design and code reviews, good documentation and configuration management, they love it and find it really helps their creativity and ability to get things done.

Don't play to the “cowboys” here — there is always a need for process, and anything has a process, even if it is chaotic. It can be documented and managed well to produce a better result.

By: Martin Thomas

Martin Thomas — Fri, 24 Jul 2009 14:50:03 +0000

Interested in your thoughts.. Does 37signals or E-myth have the right philosophy for business today? www.purlem.com/blog/?p=38

By: mxaddison

mxaddison — Tue, 21 Jul 2009 04:44:32 +0000

Andrew — I can say with experience, at least to the part about marriage, that if you have pure passion for each other you'll figure out the rest. Perhaps the same holds true for entrepreneurship.

By: segdeha

segdeha — Thu, 16 Jul 2009 20:33:08 +0000

There is a corollary here with different styles of dog training (believe it or not). Some people practice corrective training where the dog is “punished” (usually verbally) for incorrect behavior and praised/rewarded for correct behavior. Another style, using “markers”, uses rewards (sometimes praise, but more often food) for correct behavior and verbal markers for feedback when the dog is doing either the wrong thing or is on the right track.

The difference is subtle between “no” as feedback and “no” as correction, but the result is dogs that are problem solvers rather than ones afraid to try new things for fear of being punished. The goal of any company should be to “breed” problem solvers. You do this, as Andrew points out, by planning for, accepting, and even celebrating failed attempts to solve problems.

By: Happy Cloud Moments

Happy Cloud Moments — Thu, 16 Jul 2009 00:46:17 +0000

Hi Andrew,

Thanks for stopping by my blog! You have some interesting articles here.

By: ssaikia

ssaikia — Tue, 14 Jul 2009 17:22:26 +0000

WHO IS YOUR TARGET AUDIENCE FOR THIS POST?

The concepts outlined in this post probably apply to bigger organizations that have significant resources. A small resource-constrained startup is not going to plan for failure and build the redundancy that you prescrible.

NOT a good post Andrew – it does not sound like you know your material! Sorry for this harsh criticism.

By: Stephane Rodet

Stephane Rodet — Tue, 14 Jul 2009 14:15:21 +0000

I just limit myself to the Google argumentation:
Well, it's a different architecture – different needs too. The mainframe is much more expensive, so it all comes to requirements. If one Google box fails that references 10000 of websites, and these are absent of a search result, that's no big deal. Also if 1000 Gmail users can't log in during 15 minutes, that's no big deal – no one is going to be fired or to sue Google for that.
Now think about 1000 of transactions on the NYSE that fail. That's another type of consequences. That signifies $$$ of losses. Or would you like your monthly paycheck to be lost randomly? Probably not. These are the case where you need special hardware. It's fault tolerant, complex & expensive, because it would be even more expensive not to have that degree of tolerance-fault. That's why both architectures coexist. There is not a “one fit all” solution.

BTW, some study has shown that people that have a plan B tend to be less depressive because they can adapt better to the new reality… So failure has to be in the plan, too.

By: Warren Benedetto

Warren Benedetto — Mon, 13 Jul 2009 19:29:32 +0000

You might want to watch the first few minutes of Jason Fried (37 Signals) giving the keynote at BigOmaha recently: http://vimeo.com/4717683?pg=embed&sec=

Based on his comments about not embracing failure, I have a feeling he might disagree with your thesis about his company. Maybe you should consider updating the post to reference Ruby On Rails specifically, rather than 37 Signals. That seems to be a more accurate comparison.