Exploration Through Example

First, watch this video. Watch it once for pure enjoyment, if you like, then another time to concentrate on the foot movements of the woman. Ignore the flourishes (where she whips her heels around) in favor of how the other foot moves. (Turning the sound off helps me, and it may help you.)

To the right, please see a snapshot taken just after Sr. Naveira has led a barrida (”sweep”). (For more on that step, see this video.)

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move. I don’t say “mental” lightly: one of the hardest things about learning to follow is learning to squelch the urge to anticipate.

“Mental” goes further as well. As a leader, you can’t see the face of your partner, but you can see those of other followers, and they often display a sort of eyes-closed, inward-facing concentration.

(My description makes tango sound like a very command-and-control dance, where the leader plans and the follower executes. It pretty much is, at least in its traditional form, but the leader also has to react smoothly. See the postscript for more.)

I call this readiness to react gracefully to events that happen too fast to think about the stance of reaction. I contrast it to the stance of reduction, a readiness to reduce (abstract away, simplify, generalize) the world’s complexity into something simpler that you can work with and think about. We knowledge workers are good at that, to the point that we’re often scornful of other stances.

Many of the reductions we humans have come up with have great “stickiness”. For example, economists make their way in the world by modeling that messy species, homo sapiens, as “homo economicus”:

… a being who desires to possess wealth, and who is capable of judging the comparative efficacy of means for obtaining that end. — JS Mill

(Nowadays, economists speak of “utility” rather than just “wealth”.)

So sticky is the “homo economicus” reduction that economists face the occupational hazard of treating it as the only model of human behavior, which can make them say awfully silly things. Similarly, elegant and simple software development models like the V-model are so elegant, so simple, so pleasingly linear that their failure to work with real human behavior and limitations is commonly seen as the fault of the people, not the model.

One of Agile’s original attractions to me was, first, that it doesn’t abstract people into predictable, controllable units as much as other methodologies do, and, second, that it allows people to make decisions by reaction (”gut feel”) as well as by reduction (”rational argument”). My favorite example is the idea of code smells. Smell is one of the strongest and least rational senses: if you open a bottle of milk just under your nose and get a good whiff of rotten, you don’t stop to analyze the situation—you do something. So smell is a good metaphor for the reaction of an experienced programmer to dodgy code: the perception and reaction comes first. The justification for that reaction comes later, if at all—perhaps only if someone else demands it.

(I think of code smells as tacit knowledge with motive power.)

Programmers have long talked a-rationally about code, using phrases like “I think the code wants to…” Agile (or perhaps only XP?) makes that respectable.

Now let’s turn again to the quote I talked about in my gift economy post:

The question that keeps getting asked is what value does the customer get from paying back this technical debt? What value does the customer get from simplifying this design? What value does the customer get from cleaning this code? The answer is almost universally none. So, the [product owner] keeps pulling those activities out of the backlog because these are all internal codebase issues, the customer does not see it or realize value from it, at least not directly.

I want to claim that the true answer to questions like “why should I let you simplify the design?” or “why should I let you clean up the code?” is “because cues that you can’t perceive are making me move in that direction”—in the same way that cues you (my reader) probably can’t perceive are making Srta. Muzzopappa move in the video above.

But that would almost certainly not convince the product owner in the quote above. First, in modern hierarchical society, instinct is something leaders use to justify orders to subordinates. Subordinates don’t get to do that; they must provide their leader with rational (reduced) arguments for decisions and claims.

Second, the product owner has declared that the rational argument must be of a certain form: one that boils down to numbers (or at least to tokens that can be placed in order of increasing value). That can’t be done with code cleanup, which is about reducing the cost of an unknown number of future stories by some unknowable amount. The programmer must either lie or speak what, according to the groundrules, is nonsense.

What’s the effect of this habitual favoritism toward the stance of reduction?

Well, we know that the expert human brain disfavors what we normally think of as rational thought. Read Montague argues that’s because rational thought is expensive in terms of energy consumption, so the brain uses it as a fallback position. By default, we mostly act unconsciously, with the unconscious mind forwarding only anomalies to the rational part of the mind.

But rather than playing to our minds’ strengths, we ignore them. We spend our precious learning time training our rational mind instead of practicing our graceful reactions.

I’m not saying we shouldn’t train our rational minds: we need them to handle those anomalies. But if we train only them, we get… well, we get what we’ve got. So I suggest reversing our learning budget.

I especially think we should practice our graceful reactions to the rather unnatural human interactions that make up a software project. We should downplay weak-to-useless reductionist approaches like MBTI (about which, more later) in favor of the intentional learning and adoption of an appropriate stance of reaction.

I will write more on this topic, including some thoughts derived from how tango is taught.

Postscript: The reacting leader

Here is a picture of a tango milonga (dance):

The room is often very crowded. And each one of the men could go in any direction at any time. If you plan a complicated set of steps, your plan will surely be frustrated by someone moving into a spot you intended to go. So the leader must react to unpredictably changing surroundings.

He must also react smoothly to his partner. For example, suppose I make a bad lead: I thought I asked my partner to move forward and turn to face me, but I didn’t signal the distance of her step correctly and now she’s beyond me. I had intended to ask her to gracefully reverse her direction, but she’s not in the right place for that. I must make my next lead fit where she is, not where I wanted her to be.

Credit where credit’s due

The clip and snapshot of Federico Naveira and Inés Muzzopappa are used with permission of Gigi Canavese.

The picture of two couples is the cover image of A Passion for Tango, by David Turner.

The picture of a milonga is used with permission of Alto Maltés.