Over the weekend, I planned to go north to Marin County for an art opening. Since that event didn’t start until 5 p.m., I thought I might get a little holiday shopping in, and I remembered a company in Marin that makes products (such as children’s bibs, aprons, lunch sacks, and tablecloths) out of cloth in bright patterns that’s coated and easy to clean. I hadn’t visited the physical location before, but didn’t I read something in the newspaper about a warehouse sale happening around this weekend?

Now, I couldn’t dredge up the exact name of the company, but I knew the pattern: [female proper name] the [animal name]. I actually knew more:  The girl’s name was 2 syllables, like “Emma” or “Anna.” And the animal was something aquatic or amphibious: Frog but not horned toad, like salamander but probably only 2 syllables also.  So I knew many parts of the company’s name but not the whole. (more…)

Photograph detail UPI © 1980

I met Ted Kennedy only once.

In an earlier part of my professional life, I worked as a sign language researcher and interpreter based in New York City.   (more…)



Long before I became an advocate and trained facilitator of Innovation Games®, I was an enthusiastic practitioner of other design games and playful exercises.  (more…)

This aphorism is one I’ve heard since childhood from my mother and other female relatives, many of whom are excellent knitters, crocheters, needlepointers, weavers, or are skilled at other sorts of handwork. This sentiment also applies in realms other than knitting – such as software development.

First, a few knitting basics

Let me not assume that my readers are familiar with knitting. I’ll offer this brief definition (adapted from Wikipedia): Knitting is a method for turning yarn (or thread) into clothing, blankets, or similar tangible objects. Handknitting (in contrast to machine knitting) typically uses 2 needles (or a circular needle, with points at either end), and yarn to create linked loops. The loops, also called stitches, are held on the needle until the next loop is complete. Needles vary in thickness and length. The many available colors, weights, materials, and textures of yarn yield a rich variety of results.

What typically goes wrong

If you make an error in knitting, you may not notice it immediately. The meditative rhythm of the work, where the same familiar actions are repeated for a whole row, allows for some sorts of multi-tasking, such as conversation, listening to music, television or radio. The typical action calls for either looping behind or in front of the current stitch, and it’s possible to use tactile methods to push a stitch into position.  You might not detect that you’ve knit two stitches together where this action was not called for, until a few rows later (which may easily be as many as several hundred stitches later).  More complicated stitches offer more interesting ways to get in trouble.

It’s a good idea to rip out the rows back to the point where the error happened, and re-do the work.  Why?  I can think of at least 3 reasons to undo and re-do:

  • The mistake will likely jump out at you every time you look at the completed project or even the project in progress.
  • If it’s an error that changes the number of stitches, it will prevent you from completing the whole project without a work-around.
  • If the error is a dropped stitch, it may even require you to undo work further away, before the dropped stitch itself unravels all the way to the bottom (beginning) of the piece.

Why do we avoid ripping out rows when we know there’s an error back several stitches or even multiple rows?  Again, I’ll offer 3 quick reasons

  • It’s hard for a novice to pick up stitches after they’re off the needle and
  • Undoing work stitch by stitch is painfully slow going, but mostly
  • It feels like you’re not making progress when you have to rip.

Notice that the adage is both descriptive and prescriptive. Descriptively, we can say that one characteristic of a competent knitter is that you are also a skillful (and not fearful) ripper.  No one likes it, but your work will succeed, both aesthetically and functionally if you rip out work when appropriate.  For those who are still learning, it’s a prescriptive reminder that learning to rip out work is part of what will make you a good knitter.

An analogy in software development

Let’s consider work in the software world:  Does detecting and correcting small bugs quickly keep the whole project more intact or intact for a longer time? We know that it’s unlikely that a software project will be completed without any bugs.

Why do developers avoid fixing bugs when they discover them? I suspect some of the same reasons:  It’s hard to maintain the momentum of the project when you have to undo work that you thought was complete.

I won’t elaborate here on the separation of roles, where a programmer is rewarded for completing a number of lines of code or releasing a module on schedule, while the Quality department (or individual responsible for testing) is rewarded for finding (but not necessarily fixing) bugs. Rewarding coders for the number of bugs fixed may have two perverse effects. First, someone who writes sloppy code and then fixes it post-release may be rewarded for the large number of bugs fixed, but not recognized as the person who introduced them. Second, the person who writes error-free code or self-corrects quickly may not be recognized as a high-quality producer.

Of course the analogy is not perfect:  Software is different from knitting, in that modern software is often built by teams of people, rather than a single individual. Knitting rarely requires multiple participants to complete a project.

Still, I’d like to popularize the aphorism with software folks.

My spoken French is more or less limited to menu items and courtesy phrases.  I’m better at comprehension, but unable to express myself to my own satisfaction in a business setting.  One of the challenges of the managing the tutorial at WIF 2008, was that this session was held in Limoges, France.

As a tutorial leader, I might have been out of luck, but I was ably assisted by two professional interpreters.  In a room of about 35 people, I estimate that there were 6-8 French speakers; the remainder were willing to work in English.  Among them were native speakers of perhaps 4-5 additional languages, but English was the lingua franca for most.

After a brief introduction about design games in the product development process, and Innovation Games® in particular, we broke into groups to create “Product Boxes.”  I said, but perhaps not forcefully enough, that people could work alone or in small groups.  When Product Box starts, people dig into the materials and start making their sketches and notes.  They probably weren’t paying close attention to me (nor, in this case, the interpreter).

In the midst of the game play one participant approached me through the interpreter, identifying himself as a game designer.  He announced that “teams are the enemy of freedom.”  Either this was very deep and philosophical statement, or there was a simpler interpretation that I was overlooking.  Asking for clarification, I realized that he didn’t want to work with the people he happened to share a table and language community with:  he wanted to create on his own.

I encouraged him to go ahead and work solo.  Although this exchange prevented him from completing the full design he had envisioned, he did realize at least one good idea as shown in this photo

ideas filling or spilling from head
ideas filling or spilling from head

The ideas fly freely (into?) out of the head!

Are teams the enemy of freedom?  I might agree that teams constrain individual freedom, but I’m also a subscriber to the aphorism “many hands make light work” (there must be French for this one!).  There’s more to say about games as focused toward individuals, groups or teams, but I’ll save that for another occasion.

« Previous Page