I find it interesting that this was considered an innovative approach considering the popular history of how the wright brothers succeeded the very same way: by basing their plane on a bicycle and testing rapidly.
We often frame this in terms of keeping the cost of failure low...but that failure isn't really failure is it? No more than running a round of unit tests.
Keep the cost of learning low.
If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.
This is trivially incorrect. If the problem is the creation of a magnum opus, then the solution is creating a magnum opus.
Failure doesn't have anything to do with it. It's not necessary to fail at all to improve your process; that this is the approach that's often most effective has nothing to do with the approach itself, it's a reflection of our poor models of the problem space.
If we had a thorough understanding of the problems surrounding human-powered flight, we'd be able (or much closer to being able) to create theoretical solutions that could be effective.
I don't know if Mr. Macready actually stated that "the process" was the problem, but if he did, I disagree with him as well. That the process many people use is sub-optimal and you find a better one does not mean their process was the problem. It means it was one of their problems. Further, that it can be much faster to iterate on experimental results without a solid model of the problem does not mean iteration is somehow "the answer." It means it's one way of getting to a solution without an accurate fundamental understanding of the problem.
"This is trivially incorrect. If the problem is the creation of a magnum opus, then the solution is creating a magnum opus."
I would say you just proved the point. If the problem is the creation of a magnus opus then it is the wrong problem. Creation of a magnus opus with no further use is pointless and a waste of everyone's time, so don't solve that problem.
> If the problem is the creation of a magnum opus, then the solution is creating a magnum opus.
The problem is rarely the creation of a magnum opus. But people usually think that their problem is the creation of a magnum opus. And generally, they are wrong.
I think Paul MacCready really solved a different problem. Earlier man powered aircraft (SUMPAC, Toucan, Puffin etc.) had been based on glider (sailplane) technology that emphasised the highest possible lift/drag ratio achieved by large span high aspect ratio wings and careful control of the aerofoil shape. The span and aspect ratio make the aircraft complex and comparatively heavy. MacCready realised that if the aircraft was made much simpler and lighter it could fly at a lower speed and although the L/D ratio was poorer (all those bracing wires!) the drag would be lower (V2) and the power required (V3) much lower, within human range. The quick to fail, quick to rebuild was a consequence of this simplicity.
Incidentally the photo showing the "speed ring" is nothing of the sort. Speed to fly rings are about 80mm in diameter to fit on an instrument face.
A bit too generalized for my taste. If you're solving a problem of passing a well-defined benchmark (or closer to home, iterating on a kitten meme-sharing app), then yes, fail away. If you are solving a problem of putting a man on the moon in the 60s, then you get to coordinate hundreds of thousands of people from education to fundamental science to industry to alloys to god knows how many other things for years. And only then you can launch and really find out if you succeeded or failed - both outcomes have precedents.
Well maybe the lesson is to always think how you can verify your solution quicker. To take your example, that is the same line of reasoning Boeing is taking as a subcontractor for NASA, but where SpaceX has shown that they can verify their solution for half the cost that Boeing can[1].
I think the problem is that we tend to treat everything as a moon-landing. There are very, very few times when we should put all our eggs in one basket yet we do it all the time.
Sometimes solving a hard problem is simply hard, and trying to treat it like an easy problem by shortcutting is the wrong approach, but you might not realize it until too late. Take building your own rocket technology vs. using old Soviet engines from the 1960's. Ask Orbital Sciences today which approach might have been better.
The moral of the story should be a warning against analysis based on insufficient understanding. MacCready was working on exactly the same problem, in the same way, as everyone else. He just figured out a way to speed up the experimental phase.
We often frame this in terms of keeping the cost of failure low...but that failure isn't really failure is it? No more than running a round of unit tests. Keep the cost of learning low.