Here are some notes on a few of the most interesting points which stuck in my mind from our introductory conversation with Jane, Hugh, Axel and Roberts Klaschka and Woodbury on Monday morning; perhaps they can be of some use in the wrap-up today, and/or for later reference:
- Development cycles, shorter vs. longer – Axel pointed out that kitesurfing ideas are testable within days or weeks, while mono-/multi-hull sailing ideas typically take months or years to develop, construct and test and that kitesurfing has overtaken hulled sailing designs in a relatively short time, though was quite far behind. The lesson: spend less time designing before prototyping/testing/simulating, then redesign as needed.
- “Optimization” of sail construction as in molded (3D) sails with laminations and fiber placement targeting load paths at specific wind speeds and points of sail can be too restrictive in comparison with more flexible (stretchy) and thus versatile sails. Thus, designing for a narrowly constrained niche of conditions may carry an overall performance penalty in comparison with more redundant systems, especially when conditions are more volatile (changeable).
- Sail shape control via boundaries (e.g. halyard tension, cunningham to pull boom and foot of sail, running backstays to control mast bend, etc.) vs. possibility of more local controls (e.g. shape-changing battens, inflatable cells on sail surfaces …). Also the possibility of shape-changing not just aerofoil (sail) but also hydrofoil (mainly the keel – currently limited by and large to daggerboards, retractable keels, swinging keels, but curvable keel and other variations are also conceivable.) Bear in mind, however, the distinction between hard-to-control vs. easy-to-control systems (recall the crash video shown by Robert Woodbury) … thus, the number, type and arrangement of controls must be carfully considered – more is not necessarily better, nor is less … strive for a “sweet spot”.
- Data collection via observations and sensors at/from a single point (i.e. the boat’s own location) versus multiple locations (e.g. shared data among boats) and the dangers of information overload, or over-reaction by responding too frequently to fluctuations (e.g. calling too many tacks). Thus, again with information as with controls, more is not always better, if it cannot be processed rapidly enough and responded to with sufficient intelligence.

The last two points suggest that until automated/artificial reasoning systems become much better than they are at present, we still have to contend with the weaknesses (e.g. inconsistency, quantity) and strengths (e.g. making reasonable assumptions in the absence of actual data) of human cognition for decision-making about responding to dynamic phenomena, though automated systems can certainly help us visualize and gain insights to the data we need to evaluate. In dynamic conditions, one of the most important factors may be an ability to recognize patterns versus chaotic regimes of behavior (remember Robert Klaschka’s example of finding the wind shift cycles.) While the former allow a degree of predictive control, the latter require some balance of agility/responsiveness and a willingness to ‘ride out the bumps’, even though not knowing what’s coming next. Which leaves us with no easy answers in Designing (for) the Dynamic, and underscores the complexity for which yachting has been called the “sport of kings”, as Hugh pointed out at the very beginning (http://designingthedynamic.com/designing-the-dialogue/).

Greets again from Singapore and regrets at not having been able to get to Melbourne in person!