3 ms·

"The problem was the problem. Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the

"The problem was the problem. Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges." 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.

setrofim_ 15y ago
"but other alternatives (for example, hiring a thousand engineers and building a thousand planes a year) would have found the same answer" 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.
AlexBucataru 15y ago
You are right: the problem was not the problem, but the available tools, namely the inability to "fail fast and cheap". However, I am not sure what alternative to building better tools first would be viable - throwing more resources into broken processes rarely, if ever, leads to results.
dstorrs 15y ago
Check out _The Mythical Man-Month_ for a refutation of this. 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.
- baddox 15y ago
  Your examples are only true because gestation and many software projects are not easily parallelizable. It's a rule of thumb that applies to many scenarios, but obviously not all. If it takes 2 hours for one person to mow his lawn, then 2 people could mow it in about 1 hour. 100 people really can lift 100 times the weight of one person. Not to mention that nine women can have nine babies in nine months. Making many different aircraft prototypes simultaneously is certainly parallelizable, although it obviously would be enormously expensive.
  - AlexBucataru 15y ago
    In experimental tasks, parallelizing does not provide the same gain in success probability as accelerating the process of prototyping. 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%

setrofim_ 15y ago

"but other alternatives (for example, hiring a thousand engineers and building a thousand planes a year) would have found the same answer" 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.

AlexBucataru 15y ago

You are right: the problem was not the problem, but the available tools, namely the inability to "fail fast and cheap". However, I am not sure what alternative to building better tools first would be viable - throwing more resources into broken processes rarely, if ever, leads to results.

dstorrs 15y ago

Check out _The Mythical Man-Month_ for a refutation of this. 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.

baddox 15y ago
Your examples are only true because gestation and many software projects are not easily parallelizable. It's a rule of thumb that applies to many scenarios, but obviously not all. If it takes 2 hours for one person to mow his lawn, then 2 people could mow it in about 1 hour. 100 people really can lift 100 times the weight of one person. Not to mention that nine women can have nine babies in nine months. Making many different aircraft prototypes simultaneously is certainly parallelizable, although it obviously would be enormously expensive.
- AlexBucataru 15y ago
  In experimental tasks, parallelizing does not provide the same gain in success probability as accelerating the process of prototyping. 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%