You're solving the wrong problem
azarask.in
azarask.in
I think this is untrue: people were solving the right problem, but doing so with insufficient tools. MacCready's solution was to improve the tools, but other alternatives (for example, hiring a thousand engineers and building a thousand planes a year) would have found the same answer. Of course that answer would have come at a much higher cost and for this problem it would have been uneconomical, but there are plenty of domains where MacCready's approach would have been suboptimal.
"Iterate faster" is a good lesson that I think is probably applicable for all of us, but the temptation to solve tangential problems is a hard one to resist and often unnecessary.
Before MacCready came along, there were a thousand (well, a large number) of engineers building a thousand planes a year. But because these attempts were disjoint, there were all making the same mistakes and were slow to learn from them.
The point of the article (as I understood it) is that when you're working towards a goal, you usually don't fully understand why that goal may be difficult to achieve -- what the real problems are. This is why is import to get early feedback about whether or not you're on the right track, and to adjust your attempts accordingly.
Quoting from memory:
- Nine women cannot have a baby in one month.
- Adding more developers to a late project makes it later.
The problem is that in order for throwing a thousand engineers at the problem to be time-effective, each one must communicate what he has learned to all of the others. That takes time and adds friction.
Making many different aircraft prototypes simultaneously is certainly parallelizable, although it obviously would be enormously expensive.
Building prototypes in parallel does not provide the benefit of a feedback loop, as the iterative process does.
Let's say you have a 10% probability of success on the first attempt, which improves by 40% after each experiment (to 14%, 19.6%...), and you have resources for 5 attempts. The chance of getting at least one successful solution is: parallel ~ 40.95%; iterative ~ 72.19%
http://paulbuchheit.blogspot.com/2007/04/secret-to-making-th...
Just some fact checking. Could someone confirm this? I've been told in the past that Youtube was originally built with Python.
“Quotes about Python” (http://www.python.org/about/quotes/) also has an entry for YouTube:
> “Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers”—Cuong Do, Software Architect, YouTube.com
I found the previous discussion interesting as well:
"The problem is we don't understand the problem" (April 2011) http://news.ycombinator.com/item?id=2591367
In startups, you often start with one problem in mind but stumble on another (and another, and another...). And even when you solve the technical problem, you still have to solve the business model problem.
Yes, you may solve the problem of finding the cheapest flight through search, but can it make money? And how long will it take to break even? etc etc
Of course that's only going to help address the first stage of the pipeline, eventually you still need to do a bunch of research in to manufacturability of the drugs, clinical trials, etc. Those all take time. Maybe they could be sped up as well but I can't say that's an aspect of it I know much about :)
For example, they keep presenting an argument about how milk protein is harmful because lab rodents developed liver cancer when fed with a diet of 20% milk protein, as opposed to rats fed with a diet of 5% milk protein. What they don't mention is that many of the rats fed 5% milk protein died.
In terms of meat, they don't make a logically sound argument against eating lean white meat or fish. Fish can be extremely healthy and nutritious. Every argument presented in that movie applies mainly to red meats or unhealthily-cooked white meats. They just use red meats as an example, and then make generalizations.
And like most documentaries, they include anecdotes to keep your attention.
It's a movie with good intentions (it's a lot easier for the average American to be healthy just by cutting down on meat consumption), but exaggerated claims (meat -- especially fish and lean white meats -- and milk protein isn't going to kill you, and can actually be very nutritious).
While the prize hopefuls were only focused on the outcome, MacCready realized that the process was equally important.
You can observe this in many industries. Find the biggest bottleneck in the process, solve that problem, develop faster, rinse and repeat.
All in all, a very valuable lesson I think.
How would Google look like if they were to release GMail using an "iterate faster" mentality? Your INBOX just got accidentally erased because of our UI bug. Oops sorry, we'll release a fix in 5 minutes.
How about Windows? or a generic OS driver? Oops, your machine is just blue-screening now. Don't worry, we'll just release an update in an hour. It'll certainly make your OS drivers very reliable.
Don't confuse the Web 2.0 "iterate faster" era with "the right way". Building "iterate faster" systems is easy. Building systems "the right way" is hard.
> Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.
I bet GMail and Windows do iterate and fail fast, internally. They probably often do fix bugs within 5 minutes, and have continuous integration tests running at least hourly. This is "the right way", and yes, it's hard. You don't see the fast iterations in the final product, but that doesn't meant they're not there.
You can also use techniques like feature switches to roll out experimental features to only part of your userbase, although even then you'd ensure basic reliability first.
To be honest, it sounds like you've confused 'iterate faster' with 'write crap code'. That's not what it means at all. It's HARDER to iterate faster with crap (presumably untested/untestable) code since you're piling technical debt upon technical debt.
Clean, tested, maintainable code is essential for quick iterations to succeed.
I think this line best summarizes the article, and applies in problems beyond engineering.
I disagree. If your goal is to create something great, you aren’t necessarily so misguided—how you go about realising that goal is what’s relevant. The Gossamer Condor was no less a masterpiece for having been created iteratively.
"Fleet-footed" perhaps?