Slashdot Mirror
How To Make Moonshots
An anonymous reader writes Google Glass failed. Its self-driving cars might change the world. At Google[x], pursuing the biggest, craziest projects means getting comfortable with failure — and embarrassment. Astro Teller, who leads Google's experimental lab Google[x], embraces the idea that failing fast is a way to learn even faster. "Larry Page told me, a little over two years ago, that he wanted to see us crash at least five of these scale versions of the energy kite. Obviously he wants us to be safe and we work very hard to be safe in everything that we do. What he meant by that was that he wanted to see us push ourselves to learn as fast as possible and though the learning from the crashing itself would be close to zero, he was pointing out that if you aren't failing, if you aren't breaking your experimental equipment at least occasionally, you could be learning faster."
I don't see how you'll avoid the minefield that is considered "prior art" if you're just enthusiastically fucking around.
...if you have the financial resources to afford to crash and burn. For most of us there's a significant incubation period that might even require profitability before we can afford to push past the point of safety or reliability and dial it back.
Do not look into laser with remaining eye.
2 oz Gin
3 oz Clam Juice
1 dash Tabasco
They could have just googled for it :-)
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
This is ridiculous, upbeat bullshit intended to convince people that Google is a positive, dynamic, agile, bleeding-edge, open, otherbuzzwords place to work.
You learn no more from failure than you learn from success. There are many ways to fail and few ways to succeed, thus it is better to learn what to do than what not to do. Failure simply slaps people upside the head and makes them think before trying again. Failure is a learning experience if you didn't plan ahead in the first place. Further, there are many scenarios where failing is not an option (e.g., medical, military, and space ventures). Failure in these areas is seen as a shameful mark worthy of criticism, lawsuits, retaliation, etc. more than it is a learning experience.
If Google wants to drive people's cars around or float massive objects above their heads they better not be prancing about on Unicorn Rainbow "Failure is Okay" Island.
It should be "How to Make Segways"
Google glass failed, but I suspect that they allowed it to fail due to lack of persistent development.
The way most people work is that they try something, it doesn't work, and they give up. I've heard lots of things like "I can't learn to whistle, I've tried" and "I tried that, but it didn't work". Mostly it's amateurs building stuff and giving up on the first try: "I put the circuit together and it didn't work", or "I tried to build a spice rack for Marge, but it turned out awful".
If you really want to make something, you have to be prepared to throw the first one out and start over. If the circuit doesn't work, find out *why* it didn't work and fix it. If your spice rack is awful, spend some time on YouTube looking at proper technique, then spend some time using the router (or table saw, or whatnot) with pieces of scrap until you get the hang of it. Then start the project over.
Google glass could have been popular if they noted the feedback and piloted the project into more popular waters. For example:
1) A flip-down cover for the camera, so you can interact with people and they know you aren't recording them
2) A less restrictive interface, so that developers can show anything instead of storyboard images like a viewmaster. IOW, a direct graphical interface.
3) a less expensive device (costs $150 to make, $1500 to buy). (Note: Cell phones have largely the same functionality and don't cost $1500)
Rather than fix the problems, they decided to just let it die. Maybe they did market analysis and thought that it would never sell in any form, but I really doubt they went that far.
At first when I read about championing failure as a path to success, I thought they were talking about Larry Ellison.
It explained so much about the quality of Oracle.
Quantum computers, nuclear fusion and a manned expedition to Mars are moonshots. This is just a novelty. Please don't cheapen the actual lunar landings by overusing "moonshot" for what is essentially just regular R&D.
Easy. Do you have a mirror?
Slashdot, fix the reply notifications... You won't get away with it...
Yes everyone knows they set out with failure in mind with the Moon landing.
You are right. They didn't. But failure was a really high likelihood at various parts of the program. For example, I've heard that the odds of losing at least part of the crew on Apollo 11, the first landing on the moon, were estimated at about a third, prior to the mission. Failure was a possible and way too likely outcome despite the "failure is not an option" mantra.
The problem was not that Apollo program had a better solution to "moonshots" than "fail early, fail often", but rather that they couldn't do that. The program could have been made a bit more incremental and resilient to failure, but in the end, you're either landing people on the Moon or you're not. There are huge jumps in technology and risk taking that Apollo just couldn't avoid.
According to you google itself shouldn't exist. As google the search engine was a moonshot. Hell ms DOS was a moonshot.
i thought once I was found, but it was only a dream.
It always seems like these guys are missing something. Bell Labs had this figured out. Arguably, IBM has done a better job of this in recent decades. I get the impression the people at Google just kind of heard about a bunch of failed DARPA projects and decided to try and fix them up. Self driving cars, enhanced reality headsets, balloon based networks, nanoparticle diagnostics, jetpacks, neural network enhanced computer vision... all legacy military development projects... all very cool, but not really lightning strikes of inspiration.
Is it that they don't have the right people? Are their projects too fast? Are they too structured? Maybe they're purposefully trying to only do things others have already tried and failed for some reason. Perhaps it's that they've forgotten the difference between innovation and invention. Innovation builds successful companies, but they'll need a hefty dose of invention if they really want a "moon shot."
I think you are missing the point. The point is that there are ways to mitigate the risk. There are approaches to learning and innovating that do not involve "build it and watch it implode". In fact, most of the innovation and learning that is not done by SV hipsters is done by incremental experimentation, not by watching something crash and burn.
I don't think so. Everyone who has any exposure to Silicon Valley knows stories. Mine is that I was friends with someone who involved with a start up run by a couple of Stanford grads that was given $70 million to provide services for virtual ISPs. The business case was remarkably weak, the organization was structured badly (their billing system was built and operated by a contractor and most of the staff was for show), and the leadership seemed more interested in the weekly parties than in running a business. Sure, I wouldn't have learned anything from that failure, but I bet a lot of really gullible people did.
Googling around, I see that a number of the leadership also moved on to other things. So the failure didn't really hurt them either (assuming it actually was failure from their point of view). Maybe they learned to plan or something.
But just because people do dumb stuff in Silicon Valley doesn't invalidate the claim. If you're doing something where failure just isn't that costly, then you should be aggressive enough to fail on a regular basis. That's even more so when you expect a variety of failures to happen during normal operation.
The "energy kite" of the story just isn't that expensive a prototype. It's also something that you would expect to fail every now and then even under normal operation. If they aren't breaking a few of them, then they aren't really exploring the envelope in which this vehicle operates or how to detect and recover from such failures.
"and though the learning from the crashing itself would be close to zero" - he doesn't get it
I'd really want a guy named like that in charge of my experimental lab :-)
Or SDD as it is known in HughBar-Labs [inventors of llama-case, one capital letter at the beginning of stuff] has been in use since about 1930. Some blame it for the rise of the Nazis in Germany, they used plenty of slogans, too. Our lawyer tried to sue them, but we never heard from him again, last thing was a postcard from some place sounding like Tribblinka, maybe the tribbles ate him?
Seriously though folks.
On y va, qui mal y pense!
You have a point. On the other hand, many approaches that WERE impractical 10 or 20 years ago are quite practical now. Consider any solution that in involves a modern computer. Twenty years ago, you'd need a cluster of computers to do what can now be done on a cheap prepaid phone. Any solution to an individual's daily hassles that involves a multi-Ghz processor was written off as impractical. Now, there's an app for that.
Then there are all of the building-blocks that have become available. Facial recognition and machine vision in general cost a few million dollars ten or twenty years ago. Now it's a readily available service already built into the Android OS. When you have readily available modules to easily do what used to cost huge amounts of money, things suddenly become practical that weren't before.
Additionally, but in the same vein, the experts doing all the deep study for decades wouldn't have even THOUGHT of how to leverage technologies which were not available at the time. Knowing about the different technologies that are available or likely to become available, one sometimes sees solutions that you wouldn't think about if you weren't familiar with the tools.
Lastly, in my experience domain experts know a lot about how things are done. Their idea of how things should be done is often based on how they were taught to do it. That's an entirely different mindset from looking at it fresh and considering which methods are actually best suited to the current situation. I've been able to significantly improve processes simply by asking "why"? "Why is this data held in a Word document (actually three versions of the same document) rather than a spreadsheet?". The domain experts knew exactly which version of the Word document to send to each person, and had procedures for change control so that updates to one version normally ended up being reflected in the other versions. I pointed out the "hide column" menu item in Excel and now they no longer need to maintain three different copies of the data in order to look at different sets of attributes.
failing fast is a way to learn even faster.
This can't possibly be true. If it were...
For Democrats: Congress would be full of rocket scientists by now.
For Republicans: Obama would be a Republican by now.
Just another day in Paradise
All these people using the moon landing as an example of why FAIL FAST isn't needed are making me chuckle. You're absolutely right about the very high risk of the mission. Arguably NASA took some huge risks purely because speed was seen as critical; they could have done dozens more missions with smaller evolutionary steps and/or waited for technologies to be better tested or refined.
There's a certain demographic that hear "Fail Fast, Fail Often" and create the most absurd straw-men. Fail Fast doesn't mean try to fail, it means try to do the riskiest stuff first so that you know if you have issues quickly. Fail Often doesn't mean try to fail, it means don't be afraid of trying to do something just because their is a good chance of failure. It's been pointed out enough times before, but sadly it's like trying to explain the wonders of beverages to a block of sodium.
MSDOS was initially a cutdown CP/M workalike Bill saw running and bought (eventually) so that's playing it about as safe as you can get.
Google was initially the science citation index ranking (not that the kids would remember such a thing on microphish) applied to web pages so not a huge leap in the dark either, even if it was a bit of a surprise to just about everyone.
If they didn't have Aldrin on board with a slide rule and his vivid memory of his thesis on orbital rendezvous (http://dspace.mit.edu/handle/1721.1/12652) then it's very likely that they wouldn't have made it back when the computer on Eagle failed.
That's just an example of a component failure that was prevented from causing a mission failure.
Nice Intel joke from 2006! Hahahahahahahahaahahahahahahahaahaaaahahhhahahaaaahahaahsoclever*burp*
You bring up good points. The actual "moonshot", the Apollo program wasn't a good example of how to do a moonshot due to the huge risks and jumps that NASA took. They had their reasons, but it was a tremendous gamble that might not have paid off. And really, if you're speaking of moonshots in the Apollo sense where you don't have the same urgency or the same willingness to gamble a considerable amount of effort on getting it right the first time, then you're doing it wrong.
Besides that kind of failure never happens, so why would we ever need to learn about it?
You can only learn from the mistakes if you have the courage to make mistakes.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
This is the most clueless post I've seen here. You've clearly never done any R&D, or worked on a serious (multi-million dollar) engineering project. Come back if you care, and do so w/o posting as AC.
Just another day in Paradise
Yes everyone knows they set out with failure in mind with the Moon landing.
To deal with failures, Apollo program also consisted of a huge infrastructure to deal with failures. Many test stands and test articles were built, a lot of F1 engines were built as one failed after another. I'm sure many a thousands of engineers pulled many allnighters trying to make things work including s-band transmitters. First flight of Saturn V rocket had significant pogo oscillation problems (heck many other rockets had same problems). Immediately many engineers and techs built a test stand to learn how to mitigate pogo oscillations. And there was Apollo 1 capsule fire. Lots of resources were poured into complete redesign and construction. Lots of problems occurred i.e. computer problems on Apollo 11 lunar lander but there were resources of engineers and programmers to attack and solve that problem before it became a disaster. And Apollo 13 but there was a huge infrastructure of people and hardware to come up with contingencies to deal with the situation that allowed crew to safety return.
mfwright@batnet.com
I really don't get the fashion of saying 'fail' when they really mean 'take risks'. They aren't the same thing, and a lot of people misunderstand before they think about it. It's very easy to fail without risk of success or learning.
"Fail fast, fail frequently, fail cheap" I forget the book I read that in. --Josh
I suppose it depends on how you define "failed". In my book, no way was Google Glass a failure. If you think they meant to make megabucks by selling a product, sure... but I can't imagine that that's what they expected to occur. It was a big experiment, and a lot of data was collected from it.