Exploration Through Example

I’ve been speaking about the desirability of what I call the stance of reaction in software development. Now it’s time to think about how to learn it. Since one of my inspirations for it is tango, I’ll first talk about how tango is learned. (This post may be tedious for people who don’t care about tango or teaching physical actions.)

Dawn and I took a tango lesson last night. It’s a just-beyond-beginner course concentrating on the milonga and vals, two alternate tango rhythms, but it was also teaching new figures to many of the students.

Here’s the first figure, which is one you can repeat an arbitrary number of times as you proceed sideways down the floor:

Joe and Carlotta (the instructors) began by demonstrating the figure, then explained just a few things to attend to. (Joe will usually say something about which part of the leader’s body signals the next movement to the follower. Carlotta usually talks about where and how the follower’s feet should land so as to be ready for the next step.)

What happened next was typical: everyone practiced the movement separately with Joe and Carlotta making a few comments. We moved quickly to direct practice in a mixer: you meet a partner, go sideways down the floor, separate, meet up with a new partner, and continue. Most of us aren’t confident enough to correct our partners, but it’s usually pretty easy to tell how you’ve gotten it wrong and correct it yourself. It’s also easy to tell by feel when you’ve gotten it right.

Joe and Carlotta observed, as usual. After two or three songs finished, they pointed to some things most of us could have done better. I don’t think we practiced this figure again; sometimes we do.

That typical practice session finished, they then introduced a new figure that can be combined with the first one. Instead of going backwards after the second step, the leader can take the couple to the right for one or more steps, then backward:

This figure makes it harder for the follower. After two steps, she has to be prepared either to step forward or to her left. The leader signals this mostly by just moving in the direction he wants the couple to go, which I think the follower detects mostly via her arm on his shoulder.

We went quickly into another mixer. In this one, leaders were encouraged to switch between the two figures at unexpected moments. So the followers were learning to detect the lead, and the leaders were learning to make it clear enough to be detectable.

The next figure starts at the same position but deviates in a different direction. Instead of stepping forward once, bringing the feet together, and then changing direction, the leader repeats the first two steps:

After that, he can take the couple backwards (as in the original figure), to the right (as in the second) or, if there’s room, continue diagonally forward with the first two steps.

At this point in the lesson, I think we danced several songs in the normal “line of dance” (in a rough counterclockwise circle around the room, rather than down a straight line), switching partners between songs or at most once a song. (Tango songs are usually in the 2-4 minute range.) Using the line of dance approaches non-practice dancing more closely: there’s more time to adjust to a particular partner, and also the leader must avoid more collisions than in a line. (Learning to react to events while preserving your musicality is an important part of tango.)

All that lasted about a half an hour. Then there was open practice. Dawn and I concentrated somewhat on the figures we’d just practiced, but I threw in other variations and also figures that don’t start with the same step. These figures were easy enough that we could just have fun.

Dawn and I also practice in our basement and on our driveway (which I’m sure the neighbors think is terribly cute). We concentrate on what we’ve learned recently. (All these variations are hard to remember!) We’ll often practice the fine points of steps and body orientation in slow motion, then at normal speed. We also just plain dance, though the two spaces aren’t very good for that.

There are weekly to biweekly come-one-come-all practice sessions that Dawn and I usually attend. We do the same sort of practicing as above, but we have the advantage of experienced people we can ask for tips.

After almost a year, we should probably be dancing at real dances, but they’re usually pretty crowded and we’re not so experienced in the steps that work in that kind of a crowd. Also, neither of us is a particularly social animal.

The Constant Reader is surely aware I have a childish resentment of the dominance, in software coaching, of theories that change-is-managing-a-crisis-imposed-from-the-outside. It’s not that I deny the existence of such situations; it’s that I hate the ubiquity of the theory. That’s especially so because humans are so reflexive: our theories about our behavior affect our behavior, reinforcing our theories. If the only model you have for change is crisis, then every change is seen as a crisis, and there is less room for inner-motivated change.

Over the years, I’ve convinced… oh, I’d say, about… no one of my point. So perhaps it’s time to bring out the big guns and fight metaphor with metaphor. The dominant metaphor of change is drawn from family therapy and analogizes the group in change to the family in crisis. My new metaphor of change analogizes change to the adolescent primate leaving its group.

Oops, I’ve just oversimplified:

It is no longer accurate to state that one or the other sex disperses at sexual maturity; dispersal in primates is much more complicated than that. — Katherine M. Jack, Lynn A. Isbell

Nevertheless, it’s the case that our closest animal relatives do follow patterns where the (mostly) young leave one group and, despite considerable risk, join another. The typical explanation is something deterministic like incest avoidance. The summary link above claims that explanation, too, is an oversimplification. The behavior of social primates is complex and, to my layman’s eyes, often defies simple linear “Because of X, the animal does Y” explanations.

Although it’s probably dangerous to anthropomorphize even close relatives like chimpanzees, I’ve read articles (none of which I can dig up) that tell stories of ape dispersals that invite us to attribute emotions other than fear to this huge life change. The young ape is curious about another group, finds them tantalizing. It sneaks around watching them, hesitantly getting closer and closer, scampering back to the safety of the home group if threatened, but gets increasingly brave over time. At some point, it makes a commitment and joins the group, despite a typically unfriendly early reception and often ending up as the lowest status animal.

Change here is desirable and motivated internally. Rather than a move forced out of desperation, it’s one important enough to “save up for”:

Instead, female emigration was predicted by dietary quality, suggesting that females wait to have sufficient energy reserves to buffer the high costs of dispersal. — A summary of a longer article.

I think that makes a good metaphor for the kind of change that we can seek, not avoid, in software development: change that is risky, yes, but change that we are impelled to try, because of our nature.

Are you saving up for the next change that’ll tantalize you, that you just have to try? What? You’re not expecting one? You haven’t been tantalized by the possibility of big change since you-can’t-remember-when? You are violating your primate heritage. Perhaps you should align with the Porifera.

Here’s an app that’s used to reserve teaching animals at the University of Illinois vet school:

A user selects procedures to perform by clicking in the leftmost window; animals to perform them on in the rightmost window. Clicking moves the procedure or animal to the corresponding center window and can also narrow down the possible choices. For example, some procedures can only be performed on horses. If you pick one of them, all the cows disappear from the rightmost window.

The first user interface didn’t look like this. It used three windows instead of four, and drag-n-drop instead of clicking. It was heavily tested using a mock-centric style like that of Growing Object-Oriented Software. The switch to a new interface broke all those tests. Bummer!

However, I discovered an interesting thing while dealing with the broken tests. None of them applied directly to the new user interface. However, each of them had some original purpose; each captured an issue that had been important. The exact issue was no longer important, but usually one very like it applied to the new UI. So the broken tests became something of a checklist and spur to the imagination. Rather than just fixing them, or throwing them away, I used them to ask questions: “What user intention or user safeguard does this test represent? How would that intention be exercised in the new UI? [And what test should be written?] Is there a similar danger in the new UI? [And what test would show that the user is protected from it?]”

It was something of a revelation. Allofasudden, maintaining the tests had actual value. Yes, mock-heavy tests do require more maintenance. No, that doesn’t bother me.

Being prone to grandiose statements, that’s led me to proclaim the dawning of the Third Age of Programmer Testing.

The First Age

In the first age, the vast majority of programmers thought testing was boring, pointless, beneath them, and a big waste of time. A much smaller number of programmers thought it was worth doing, although virtually no one was happy with it. I think we all realized, at least unconsciously, that something was wrong with our practice.

The Second Age

Around the beginning of this century, the practice of programmer testing took a big jump forward. Things like one-test-then-just-enough-code are, in part, mental tricks: avoiding one big chunk of testing (at either the beginning or, more usually, at the end) fools our lizard brains into thinking that we’re programming the whole time, so it knows not to be bored. We know much better how to write code that’s easy to test, avoiding tedious and time-consuming test-writing (especially setup). And so on.

Many, many programmers are still stuck in the First Age, but I don’t particularly care. I don’t have to work with them. There are plenty of Second Age folk around.

However, an interesting thing about Second Agers: the vast majority of them think test maintenance is boring, pointless, beneath them, and a big waste of time. A tiny minority (maybe just me?) embraces it.

The Third Age

Just as test-writing took a big leap forward in the past 12 or so years, I predict test-maintaining will do the same over this decade. We’ll develop mental tricks, coding and testing strategies, and tools that will make maintenance as much a thinking-about-design activity as test writing is today.

In response to my earlier “A common conception of gift economies (that is wrong),” a correspondent writes:

The fact that you mention “cheating the system” in your post tells me that you realize this: that even in a “real” gift economy or high-trust economy, there still exists an expectation of some type of quid pro quo. Whether you call it status, whuffie, social mores/expectations, karma, honor, or simply a fulfillment of the givers’ desire to bring the world more in line with their own vision, this counterbalancing force exists. If it did not there would be no motivation for the gift in the first place.

Water runs off a cliff. Politicians run for office. Rabbits run away from dogs. That the same word is used doesn’t mean it’s the same action, or has the same consequences.

Consider the recent Rubygems brouhaha. In my reading, the feeling people had of being cheated stems from reasons that would make no sense in a transactional economy.

• Rubygems users felt their gifts (patches, pull requests) were refused and belittled. That makes sense in a gift economy, in which there’s a continuing obligation and relationship between givers. It makes no sense in transactional or “whuffie-flavored” gift economy: how could my giving you something produce any sort of obligation that I then take from you?

• Rubygem versions came too often and required committers to other projects to make frequent changes. Again, from a transactional point of view, their feeling of being cheated is unjustified. They got something for free before, graciously given by high whuffie committers to a core part of the Ruby ecosystem. Why are those givers now obligated to work extra hard to make the recipients entirely satisfied with the next gift? Isn’t that presumptuous and grasping on the part of J. Random Committer?

  I’m reminded of Graeber’s comment about a reaction of missionary physicians to African gift societies. If I remember it right, the missionaries were surprised that natives got offended when asked for payment. The missionaries thought of the natives as cheaters, trying to get something for nothing. But the natives had a different view: by saving lives that would otherwise be lost, the physicians demonstrated their great whuffie. By asking for payment, they’re pretending to be lesser than they are, to need gifts that they don’t actually need. That’s cheating.

In sum, gifting produces an expectation of a “quid pro quo” in only the loosest and (I feel) misleading sense. Rather than a “what for what”, gifting produces a social relationship that—like all social relationships—captures expectations about future behavior. But that relationship is not an exchange (even deferred) of things. Rather than “quid pro quo”, the phrase should be whatever the Latin is for “[behaves] how because of how [she or someone else behaved].”

Context for cluelessness: I was a reviewer for the first paper on mock objects. I completely missed the point. Indeed, it took me most of a decade to finally get it. Now that I have, it’s become my preferred approach to TDD. I’ve carried my preference over to Clojure, going so far as to write a tool, Midje, that supports it (as well as the more-common “state-based” style of TDD).

Given my history, you’d think I’d be smart enough not to expect that people would immediately and completely understand top-down design in Clojure. Nevertheless, I had exactly that expectation. Oops. It seems I must do more than write a tool and record a screencast or two.

I write this in Stockholm. Earlier this week, I taught/facilitated a course/workshop on TDD in Clojure, hosted by the fine folk at Agical. It went well, and it inspired me to do it again. So here’s my proposal.

The course. The course is two days. It’s loosely structured. It consists of my demonstrating how I’d solve a problem, Randori Kata where everyone works on a problem, individual pairs working on a problem, all punctuated by discussions of issues and questions that come up during the day.

The organization. Although I’m calling this a “tour”, it’s actually a series of trips. Ideally, I’d take the train(*) around the USA, stopping to do courses. I could also do the same in Europe or other continents.

My minimum requirement for teaching the course is that I not lose money. What that means, most likely, is that some local company, user group, or person commits to host me, advertises the course locally, and charges other people at least enough to cover expenses. (”Expenses” includes up to two days of extra room and board. I have some hope that teaching the course will lead to something that’ll fill those two days.)

I’ve become fond of Enrique Comba Riepenhausen’s idea of visiting some people, doing some work with them, and saying “Pay me what you think it was worth.” (I did that for the first time today, when I gave a talk to Valtech Stockholm and told them to tell me after the talk what I should invoice them for.) If we could organize that kind of payment so that I’d actually make money on the course, I’d be happy. However, delivering the course and spreading the word is more important to me.

If this intrigues you, contact me.

(*) I’m a “million mile member” of the American Airlines AAdvantage program, but flying has gotten so unpleasant that I’ll take the train when I can.

Earlier, I claimed that one of the distinctions between a money economy and a gift economy is that, in a money economy, it is the transaction that matters. The person with whom you’re transacting is, in principle, irrelevant:

That is, when I buy a candy bar from a convenience store clerk, I don’t need a personal relationship with him, nor does the exchange of coins for candy create one—any more than putting those coins in a vending machine would establish a personal relationship with it. In contrast, gift economies are both about moving goods around and also about managing (creating, maintaining) the personal relationships that make up a “We”.

If you’ll forgive me broad strokes, prior to Agile, software development was transactional. “They” (marketing, product planning, “the suits”) gave “Us” money and requirements documents. In return we gave them features that had business value for them: that is, features that could be traded to third parties for more money (and thus allow further transactions).

(Note: I am speaking mostly of the Enterprise and Big Company software contexts. Smaller companies and consultancies often operate differently.)

A simplistic way of looking at one part of Agile was that it simply exchanged the requirements document for a product owner, who is both more efficient and more effective at answering questions than a requirements document can be. But something else happened. The product owner was extracted from Them and placed in close contact with Us. He was converted from a symbol to a person. In projects that work right, he becomes one of Us.

As such, he plays a unique role, that of Our main interface to Them. We give him valuable software at frequent intervals, and he turns around and uses that software to represent Us (including him) to Them. In return, he helps us when we need it: he protects us from many of the gyrations of the business as it decides what it needs, who has control, and the like. He pushes back against bad decisions and encourages good ones. When We are less than perfect, he gives us slack to do refactoring sprints and the like.

A transactional economy has been turned into a gift economy, mostly hidden from the world outside the team.

Within the team, people use the phrase “business value“, but I don’t believe they mean what the world outside means. The phrase stands in for the network of social obligations oriented around the product owner. “Business value” is that which keeps the product owner happy, gives him strong evidence for his arguments, and allows him to give the gift of protection. [There’s also a strong identification with the end user, but I’m going to leave that out for now.]

Within the team, I claim, “business value” is a symbol, much like the cross is a symbol to the devout Christian. The cross represents the stance a believer should take to the world and the people around her. In case of doubt, the cross can remind the believer of the kind of action that’s almost always a good idea. In the same way, “business value” reminds the team member of the kind of action and attitude that will keep the team functioning: when in doubt, err toward making something the product owner can show off.

Business value is, then, a boundary object. A term from the sociology of science, “boundary object” refers to an object (physical or mental) that allows groups with different goals to coordinate their actions. In the original paper, a museum of vertebrate zoology means different things to University administrators (it’s a way to compete with their rival, Harvard), California legislators (a symbol of their State’s coming of age), scientific researchers (a tool for a particular ambitious research programme), and specimen collectors (a way to preserve the memory of a vanishing environment). So long as the goals and meanings don’t conflict, it doesn’t matter that they’re different.

The same is true of “business value”. No one should care that the team’s meaning for that phrase has all sorts of different connotations and relationships that have nothing to do with exchange-for-money. The software people are a goose that’s suddenly started laying golden eggs. Who cares what they believe about what they’re doing?

This person, that’s who:

The question that keeps getting asked [by the product owner] 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.

The product owner is breaking the tacit agreement that a boundary object requires. Not only must the team justify their request, not only must they justify it in terms of business value, they must also adopt the product owner’s definition of business value. This, I think, is an act of, well, cultural imperialism. Not only must we be useful and productive, we must be useful and productive for the right reasons. Not only must we do the right thing, we must believe the right way.

This insistence on goodthink is related to the scorn toward the stance of reaction I claimed earlier. The team cannot be a black box operating according to its own rules; it must have a visible interior that operates correctly.

I’ve done precious little reading in colonialism, but all this reminds me of the attitude of colonialist rulers towards the colonized: they must be remade. For that reason, I think learning about the strategies the colonized used to preserve their culture might be useful to us in Agile.

Gift economies have a place in software lore. Eric Raymond used them to explain how open source works. Corey Doctorow built a non-monetary economy in his Down and Out in the Magic Kingdom.

My reading is that neither one of these are normal gift economies. Doctorow’s “whuffie” has the essential properties of money: it is quantifiable, you can lose it, and you must be concerned about whether the books balance.

Raymond also tames the gift economy by describing the open source hacker’s motivation as reputation, conceptualized as something numerical. By giving away software, the hacker gains reputation—just as the Doctorow character adds to his whuffie. This is perhaps because Raymond (if I recall correctly) takes as his exemplar of the gift economy the potlatches of the Pacific Northwest. However, as David Graeber points out, those examples of extravagant givings-as-status-competitions were taken from a time when the traditional culture was incredibly destabilized by sudden contact with an outside civilization (us) who flooded parts of the economy with wealth. It’s dangerous to assume they represent not-destabilized gift economies.

What both of these authors are doing, it seems to me, is characterizing a post-scarcity economy as one where we’ve just replaced money with something else that follows the same rules. They assume we are all, forever, homo economicus.

A better exemplar of a gift society is a well-functioning neighborhood in a high-trust society. A neighborhood like mine. I help one neighbor fix his bicycle (easy). I help another elderly neighbor chase a bird out of her house (took me forever). After our first zucchini-growing attempt, we gave excess zucchini to as many neighbors as would take it. In what-I-claim-is-not-a-return, one neighbor lights the pilot light for Dawn when I’m away. Another gives us excess pears. Another lends some muscle and advice when our car got iced+snowed in.

The important difference from the Doctorow/Raymond interpretation is that no one keeps track. I don’t have a ledger in which I record the value of my helping-my-neighbor-fix-his-bike and letting-him-extend-his-driveway-across-the-property-line and deduct from his debt to me the value of recommending-a-contractor and lending-me-his-snow-shovel-when-mine-broke. The very idea is absurd.

The assumption of a gift economy is that if you do neighborly things for all your neighbors, all your neighbors will do neighborly things for you. It’ll all balance out in the end, without anyone keeping track.

Caveats:

• There are people who cheat the system—the neighbor who often takes and rarely gives. That person is excluded from the gift economy to an extent compatible with peace in the neighborhood.

• This sort of gift economy happens in the egalitarian portion of society. (Graeber has a phrase for this, but I forget what it is, and my copy is thousands and thousands of kilometers away.) The Big Guys may contend under different gift economy rules, but you and I are not Big Guys.

Bruce Sterling wrote a short story that I think captures the difference in attitude between the participant in the gift economy and in the money(like) economy.

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.

@Vaguery tweeted:

Someday I would like to explore who “we” is. The company, the team, or the people on it. Saying “all of those” is glib.

Item: a gift economy is one characterized by people giving other people things without knowing or caring when (or perhaps even if) they’ll get something in return, and without assuming that their gifts to person X will eventually balance out with X’s gifts to them. (In the egalitarian portions of society, the closest assumption is that their gifts to All of Us will balance out with the gifts they get from All of Us.)

Item: pre-money economies were primarily gift economies. They were not, as I was taught, barter economies. Barter economies have the same “books must balance” concerns as money economies—they’re just less efficient. Like money economies, barter economies are, uh, instrumental. What matters is the transaction, not the counterparty. That is, when I buy a candy bar from a convenience store clerk, I don’t need a personal relationship with him, nor does the exchange of coins for candy create one—any more than putting those coins in a vending machine would establish a personal relationship with it. In contrast, gift economies are both about moving goods around and also about managing (creating, maintaining) the personal relationships that make up a “We”.

Item: Gift economies still exist alongside money economies. I helped my neighbor with his bike brakes a while back. Did I add that to an “aid to/from the family directly to my east” account? No. If our lawn mower broke, I do expect that Dawn could borrow theirs while ours is being fixed. But it’s absurd to think that I would wonder whether whether he’d now repaid his debt exactly, or if I owed him more help now, or if he still owed me. Only a University of Chicago or GMU economist would think that way, not a normal person.

Item: Teams of people in a workplace typically have a gift economy going on. I’ll go further than that. I’ll define a team—who “We” are—as a group of people who are knit together through a gift economy, particularly the exchange of favors (asked for or unasked for).

Example: Many Agile teams have “refactoring sprints” or the equivalent, where the Product Owner explicitly gives the team time to deal with accumulated mistakes and uglinesses. While (especially the first time) there might be hand-waving about how this cleanup will pay for itself eventually by allowing faster change etc etc blah blah blah, no one keeps any books that are eventually expected to balance. I characterize this as a gift from the Product Owner, who is one of “Us”. He gives this gift because he knows the rest of “Us” will go out of their way to help him someday, probably someday soon.

Example: In a comment on this blog, Daniel Hinz wrote:

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.

This product owner sees no reason to make a gift to the team, only a transaction that trades quantifiable-ish value for quantifiable cost. He has only weak social ties to the team. He is not part of “Us”.

Conclusion: The people on the team are those who do favors for others on the team for no good, sound, logical, defensible reason.

Disclaimer: I’ve just begun serious reading on gift economies. More research is needed.

I’ll be giving one of the keynotes at XP2011 (Madrid, May 10-13). Here’s my tentative abstract. How do you like it?

What Forms of Work-and-Life Make Sense for Us?

It’s widely agreed that Agile has “crossed the chasm” to mainstream acceptance. Along the way, some of the more interesting bits have fallen off. This talk will be the latest in a multi-year effort to recover those bits, rehabilitate them, make them stranger, and encourage you to put them to work. There will be no overarching “Big Idea”, but some smaller ideas will include the distinction between what I call “the stance of rationality” and “the stance of reaction” (I favor the latter), the high cost of thinking, the virtues of habit, and some criticism of the optimistic ideas about teams, enterprises, and leaders that infest our field. There may also be a tango lesson.