Paul B. MacCready Jr., the Gossamer Condor and the Kremer Prize
I heard a very interesting story about the engineer who solved the problem of human powered flight and won the prestigious Kremer prize.
In 1959, under the auspices of The Royal Aeronautical Society, the industrialist Henry Kremer offered the Kremer Prizes of £50,000 for the first human-powered aeroplane to fly a figure-of-eight course round two markers half-a-mile apart.
The prize stood unclaimed for 18 years despite many attempts. It was finally won in in 1977 by Paul B. MacCready Jr., with Dr. Peter B.S. Lissaman. They created a human-powered aircraft, the Gossamer Condor, that was formed from aluminium tubing, plastic foam, piano wire, bicycle parts, and mylar foil for covering. It was cheap, quick to modify but robust. It was designed to be easily modified.
I think this story should set off light bulbs for anyone who does research through experimentation.
The point of this story is that MacCready approached the problem differently than everyone else who had attempted it. Rather than spending years and an entire budget on building a single prototype before testing it, he first designed a system of rapid iteration. He didn’t build a system for human powered flight, he built a system that would allow him to rapidly gather a large amount of information about what would make human powered flight possible.
The prototype he designed could be flown in the morning, reconfigured and flown again that afternoon. It was with this iterative approach that MacCready was able to gather more real data about what worked and what failed than those before him. It was cheap and quick to test a modification. This encouraged the team to test ideas and each test informed the next. Finally, they succeeded and claimed a prize that had stood for 18 years.
I think scientific experimentation should be like that. Modular, easy to modify. Automated. Preferably the data should come out in a standard format so the analysis routine can stay the same even when the type of data changes. Ideally it would be written in a common language that everyone on the team knows, or can be quickly taught. A language that is consistent and easy to understand, so that changes can be made by anyone in the team and everyone would follow the same logic when making changes.
A language that could be used to operate and gather data from hardware, perform statistical analysis, create visualisation and produce a web site to show everyone else what the findings are. A general purpose programming language that could be turned to specialist tasks by adding libraries, for instance. Python for instance?
This would encourage incremental change to hypotheses and method based on data. Which is what science should be, or so I was told at the start of my scientific education. This principle seems to gets forgotten somewhere along the line and we end up planning one huge experiment every 6 to 12 months that produces a mountain of data that ‘might’ contain an answer, any answer, hopefully.
So just like those entering the Kremer Prize, we put everything into an idea before we’ve gathered any real data, then when we do gather data, it’s too late and too hard to act on what it tells us.
Maybe we need to follow the example of Mr. MacCready and first design a system for doing experimentation well. A system based around Python…..
To reserve your spot in the next free Python workshop for researchers at Melbourne Uni -
