Kinesthetic Program Design

I thought CrcCards were pretty neat when I tried them. I was astonished to learn that their power comes from holding them, waving them around, pointing at them, and sliding them on the table. I found that you don't have to write much on them -- sometimes nothing.

A participent of an AG Communications study group said something that caught my attention. He was in a design meeting where Linda Reisling had everyone pretend to be objects and throw different-colored Koosh balls to each other to represent messages. I got the impression he thought that it was both a fun and productive meeting. He especially remembers how, at the end of the exercise, the programmers insisted upon throwing the balls back whence they came to represent the unwinding of the stack.

There seems to be something powerful about involving your body in the design. When I asked LeoScott about this, he wrote this poem (he was so surprised by my calling it a "poem" that his email to me had more capitalized words, exclamation marks, and question marks than I've ever seen him write in one email message):

  We are 3space creatures. We are good at 3space.
  We have hardware coprocessors for location management.
  We are dynamic creatures. We are good at dynamics (or we die).
  We have hardware coprocessors for movement tracking.

  This is what makes a telephone so hard to use - because so much is missing.

What other examples of this pattern have you seen? I invite your insight.

  --WayneConrad

---

I learnt most about distributed algorithms when our professor got us to act them out at the front of the class. Volunteers each played one member of the protocol and passed messages between each other on large coloured cards, so that the other students could see what was going on.

---

I wonder if this is a point in favor of VisualProgrammingLanguages? I've always noticed that it's easier to teach someone how things are happening with the computer by naming the salt shaker the internet, the pepper shaker is your ISP, and suddenly things are easier for the listener to grasp. --ShaeErisson

Do VisualProgrammingLanguages involve your whole body the way Koosh balls, CrcCards, and salt and pepper shakers do?

so maybe we need lego style programming languages? true 3D VR and blocks to put together? This still brings me back to the rune magic in the Riftwar fantasy series, 'spells' were constructed by plugging hexagonal runes into each other in that universe. Rune magic sounds like a 2D lego style programming language. --ShaeErisson

---

I would write a lot of commentary, but I can snip most of what I'd write about the topic from [1], an article called "d(Ad)/d(Hf): Growth of Human Factors in Application Development" which never saw the light of day (on paper):

"People constantly request examples. It is as though they operate internally and directly from the examples. There is some evidence from cognitive psychology that that may be so and there are research projects associated with that idea (see www The Conceptual Metaphor Home Page ). Whether it is actually true that people work directly from examples, it certainly is clear that most people work better given examples than simply working from abstract theory. So it is not only true in expository writing, but in technical development,

"(P10) Provide examples.

"The modern style of eliciting application requirements is example-based. We find that people give better requirements when given specific situations to discuss and walk through than when just asked for their input. Even better than discussing the future system is to enact the use of the new system, making an actual performance of it. The performance is both example-based (P10) and tangible (P11) . Some organizations create fictitious employees having different personalities. The users describe how these made-up employees would get their work done. A lazy employee might find ways to defer work until later, while an ambitious employee might find ways to get the most accomplished soonest.

"Example- and instance-based design techniques are well received by designers. Where a few, talented individuals can handle the powerful, abstract techniques, the masses of developers have trouble with them. It is not a matter of teaching. Abstract techniques will always attract fewer practitioners, however powerful it might be.

"Better than working from an example is working with something tangible. The tangible item is both an example, and it plays into our senses.

"(P11) Provide something tangible, where possible.

"An example of working from tangibles is the "CRC" (class-responsibility-collaborator) card exercise. Index cards represent components of the software system under design. The designers write on each card the component's responsibility to the functioning of the system. They pick up the cards and walk through the operation of the system in particular situations. CRC cards have been transferred onto the computer screen by numerous practitioners, but somehow lose their effect there. There is a particular effect in working through the design that comes from reaching over, pointing to a card, picking it up, and perhaps moving it to the side.

... "Cognition in Design

"A set of design techniques have shown up over the last years which improve the match with the cognitive factors mentioned earlier. In the requirements gathering phase, written "usage scenarios" and role playing have gained acceptance for discovering more obscure requirements and user needs. In user interface design, there is an entire school of thought devoted to using paper, cardboard, and other tangible prototypes, in addition to usage scenarios. In object-oriented design, the CRC card technique has been found effective by many teams who have tried them. The discomfort to software developers usually is that these techniques involve role-playing, a relatively extroverted activity for a relatively introverted group of people."