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.
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].”
As the ground rushes up to meet him, Kevin thinks about missiles again. One missile in particular, a shoulder-fired anti-aircraft missile, blasted from a tube balanced on the bump where some guy’s clavicle meets his scapula. What guy—a Saudi? An Egyptian? A Yemeni? Some pissed-off Arab anyway, kneeling in the back of a dinged-up pickup truck with Texas plates, or crouching on the springy backseat of a rented convertible on a track just outside the airport fence. One of those portable weapons from Afghanistan, back when Afghanistan was somebody else’s problem, called… something, a Slammer or a Tingler or something like that. Kevin recalls that it’s the same name as a cocktail—a Whiskey Sour? A Tom Collins? A shoulder-fired Banana Daiquiri? No a Stinger, that’s it! Four parts brandy to one part crème de menthe in a cocktail glass, or a fat olive-green tube that farts flame out the back while the missile erupts from the front, its backside trailing a wobbly spiral of smoke until the missile gets its bearings and climbs like a sonuvabitch in a long smooth curve into the heat-hazy Texas sky toward the sleek underbelly of Kevin’s plane, a Pringles can with wings, packed full of defenseless Pringles.
That’s the first paragraph of James Hynes’ novel, Next. If its style grabs you: the modern stream of consciousness, the use of detail to capture a scene, the exaggeration of situation and low-culture references (”Pringles can with wings”), you’ll likely find the first two parts of the book readable enough to get to the payoff in the third.
I say that because the first two parts take place mostly in the protagonist’s head as he wanders, Leopold Bloom-style, around Austin Texas killing time before a job interview.
Kevin is a typical Hynes protagonist: take Woody Allen’s Alvy Singer character from “Annie Hall“, subtract Jewish culture, add in whitebread American culture, and substitute actual failure for imagined failure. Hynes’ job as a novelist is to make such a character something other than a dreary collection of white whines. He’s always done that by making the whines clever and well written, as above, but I think he’s also relied on the nature of the books around the characters. With the exception of his first, they’ve been satires that toss the protagonists into wildly exaggerated situations. (In Kings of Infinite Space, the lead character is a failed academic with a temp job at the Texas Bureau of Motor Vehicles—who’s haunted by a malevolent ghost cat and runs into a small problem involving human sacrifices.)
In Next, Hynes sets himself a harder job: to explore such a character more deeply but keep the reader balanced between dislike and sympathy, while also discarding crutches like human sacrifices chosen at karaoke parties or knife-throwing English professors. Indeed, the secondary characters in Next are more fully human than in previous Hynes novels, and (to me) it’s clear that any cardboard-y aspects are because we’re seeing them through Kevin’s eyes and it takes a jolt for Kevin to pay attention to other people long enough to flesh them out.
The plot starts simple. Kevin thinks of himself as “an underachiever in every way he can imagine, professionally, personally, financially.” He’s a book editor with a marginal job at an academic press, a failed marriage behind him, a girlfriend he probably doesn’t love and may not even like. He’s fifty, so he’s flown to Austin for a job interview, telling no one, with thoughts of making a clean break:
It’s not a real choice so much as it’s a choice between two equally risible clichés: Count Your Blessings, or Follow Your Dreams. Look it up (\mid-lif kri-ses\ n) and find a line drawing of Kevin Quinn in a sporty little convertible, with his perky young — well, younger — girlfriend beside him, her hair loose in the breeze. See MIDDLE-AGED MAN.
The plot’s set in motion when Kevin gets an absurd crush on his airplane seatmate (a much younger Asian-American woman) as she walks down the jetway away from the safely-landed plane:
Kevin cannot help but admire the enormously fetching way she moves, a sort of well-lubricated slouch by which she lets her shoulders droop and leads with her hipbones. It’s not an aggressive catwalk strut, it’s much less self-conscious and much more feral, and as Kevin follows her into the filtered light and cathedral echo of the terminal itself, into the delta of debarking passengers fanning across the carpet and onto the cool marble, he thinks, I know that walk, I’ve seen that walk before. And for one thrilling moment, his heart swells with the possibility that I know that girl! But of course, he couldn’t possibly—she’s twenty-five, maybe thirty years younger than him, he’s never seen her before in his life, and if he had, he’d have remembered. But by God he knows that walk, someone else used to walk that way, he’s felt that walk up close, he’s curled his fingertips around those hipbones from behind, and then his heart fills up again, only this time with honest-to-God hundred-proof middle-aged melancholy. It’s Lynda, he realizes, Lynda used to slink like that, Lynda used to glide away from his touch just like that. Lynda on the dance floor, Lynda à la plage, Lynda on the railing.
It’s a later chance sighting of the same woman that takes Kevin out on his Ulysses-like wandering around Austin instead of staying where he belongs, waiting in a Starbucks. (Don’t worry, though: this isn’t a Woody Allen movie. They don’t “meet cute”, he doesn’t get the girl, and she disappears from the story well before the end.)
So, another possible warning: the first two parts mix Kevin’s mild misadventures and his reactions to them with his recollections of, and musings on, the four key women in his life. Those musings increase to the point where a cabbie warns him “You need to pay attention, man.” Kevin does not, which sets him up for Part 3, which is fifty devastating pages.
I won’t spoil the sudden shift, or the pages that follow. Just let me say this: I found myself in a Pringles can over the Atlantic with tears running down my cheeks for Kevin and two other characters, even though I kind of think I despise him, even though I stopped reading every few paragraphs to focus on the in-flight movie until I collected myself.
So: it seems I recommend this book. It’s worth noting that I’m in many ways like Kevin. I’m peripherally academic. I examine my life too much. I’m the same age (though I claim my midlife crisis started at 28 and never stopped.) I too can get set back on my heels by the accident of a woman’s stance. In a later bit of the book, Kevin thinks back to a single devastating sentence a woman said to him, one that may have changed his life, and I’ve had a similar experience. So it’s possible I’m too much Hynes’ ideal reader. Perhaps I should read this to Dawn and see what she thinks.
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.
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?
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.
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.
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.
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.
Long ago, I worked for Motorola in Urbana, Illinois. Another programmer there, Eric Bina, was the first person to get a color X Terminal. Being a hacker type, he did graphical things on it and would show them off to people.
One day, he dragged me into his office to show me I-don’t-know-what. I do distinctly remember adopting my curmudgeonly persona (even then!) and telling him, “Oh Eric, no one will ever want color on a computer.”
Shortly after that, Eric quit, citing the stupidity of (at least) some of the people at Motorola. I like to think it was my comment that tipped him over the edge, because Eric then went to the University of Illinois’ Center for Supercomputing Applications, where he wrote rather more of the code for Mosaic, the first graphical browser, than (I believe) did the more famous Mark Andreesen. Eric later became one of the founders of Netscape.
Had it not been for me, we’d all still be using Gopher.
Over the past few years, some people who I would have counted as “being Agile” are now counting themselves as members of the Software Craftsmanship movement. I’m interested in the reasons why.
I’m not saying that craft isn’t a part of Agile. I’m not saying that people who identify as Software Craftsmen think that Agile is bad. I’m not saying that they’ve abandoned anything. I’m not pointing and shouting “Look! A fight!”, nor am I trying to start a fight.
I’m saying that some people who had energy for, and put energy into, Agile are now doing it for Software Craftsmanship: they’re on one mailing list instead of another, they go to conferences with one label instead of the other, their company’s marketing material used to use the word “agile” and now uses the word “craftsmanship”.
So: this is a matter of the emotion and self-perception of actual people, not of the definitions of terms.
I’m not interested because I think these people are wrong, or need to be fixed, or anything judgmental like that. I’m interested because knowing why people do things is interesting.
If you feel like you’ve made such a move, why did you do it? Thanks.
To the right, please see a snapshot taken just after Sr. Naveira has led a barrida (”sweep”). (For more on that step, see 
“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.
