Archive for the 'odd ideas' Category

Looking for young programmers to tell me about age-defying older programmers

I’ll be giving a keynote at ACCU 2013 on this topic: “Cheating Decline: Acting now to let you program well for a really long time”.

(Any resemblance to my own looming decrepitude is entirely non-coincidental.)

My premise is, roughly, this:

  • We know that age causes cognitive decline. There’s some evidence that it begins well before a typical person’s working life is over.

  • Programming, like mathematics, seems to be a field where that cognitive decline hits hard and relatively early. (There are all sorts of caveats around that statement, but let’s leave them for the talk.) Old programmers are thought not able to keep up with young programmers, to be wedded to old solutions to new problems, to be [fill in your stereotype here].

  • Nevertheless, some old programmers notably defy this trend. Some are superstars who (unexpectedly) didn’t burn out young. Some weren’t superstars, just good, solid, eminently employable programmers when they were young, who (unexpectedly) turned out to still be good, solid, eminently employable programmers today (once they get past the prejudice).

  • What’s special about those who smash the stereotype vs. those who reinforce it?

To answer the last question, I want to reach out to self-identified young programmers. If you believe you know someone who’s a stereotype smasher, I’d like to:

  1. … interview you about what’s special about that older programmer (with attention focused on behaviors and habits rather than innate qualities).

  2. … interview the older programmer and invite him or her to talk about the same topic.

If you are willing to participate, mail me.

Possible SCNA topic

I’ve been thinking about what talk I might give at Software Craftsmanship North America this year. I have a reputation for “Big Think” talks that pull together ideas from not-software fields and try to apply them to software. I’ve been trying to cut back on that, as part of my shift away from consulting toward contract programming. Also, I’ve heard rumblings that SCNA is too aspirational, not enough actionable.

However, old habits die hard, and I’m tempted to give a talk like the following. What do you think? Should I instead talk about functional programming in Ruby? Since this antique Wordpress installation makes commenting annoying, feel free to send me mail or reply on Twitter (@marick).

Persuasion, Scientists, and Software People

Science, as practiced, is a craft. Even more, it’s a high-stakes craft: scientists have to make big bets by joining in on what Imre Lakatos called “research programmes”. (A research programme is a Big Theory like Newtonian physics, quantum mechanics, Darwinian evolution, Freudian psychology, the viral theory of cancer, and so on.) It’s interesting to learn how scientists are persuaded to make those big bets.

It may also be useful. There are similarities between scientists and software people that go beyond how software people tend to like science and to be scientifically and mathematically inclined. Scientists build theories that let them build more theories. They build theories that let them build experiments that help them build more experiments. Software people build programs that help them build programs—and help them build theories about programming. So ways scientists are persuaded might also be ways software people can be persuaded.

If so, knowing how scientists persuade each other might help you persuade people around you to risk joining in on your craftsmanship “programming programme”.

In this talk, I’ll cover what the science students Imre Lakatos, Joan Fujimura, and Ian Hacking say about how science progresses. I’ll talk about viruses, jUnit, comets, Cucumber, Mercury’s orbit, Scrum, and positrons.

Learning the Stance of Reaction, Part 1: Tango

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.)

Mixer 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:

Mixer 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.

Business value as a boundary object

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.

A common conception of gift economies (that is wrong)

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.


  • 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.

The Stance of Reaction

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.)

201105201611 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.

201105201700 “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.

The “One Team” defined as a gift economy

@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.

Monad tutorial, Part 4

The State monad is a big jump for the monad-learner. It jumps up a level of abstraction by using functions as values. That makes it confusing because you have functions that work on functions, and it can be hard to keep track of whether a particular function is a this-kind-of-function or a that-kind-of-function. I try to tease apart the Gordian Knot thusly:

  1. I start by creating a logging monad that simply logs the value of each step. This is fairly straightforward.

  2. Next, I decide I want only particular steps to be logged. Steps to be logged use a log function which returns either a plain value or a wrapped value. That leads to an if statement in the “decider”.

  3. Then I raise the question: can we get rid of the if statement by pushing its work down into the log function? In this section of the tutorial, I do something like follow Beck’s rules of design: make a series of undirected local changes that arrive at something globally coherent. Specifically, that first simple decision of pushing work into one place forces us to implement the full State monad (though I only show it used for building a log).

  4. Finally, I use that solution to illustrate some key concepts: base values, monadic functions, monadic values, and how they’re put together to make up a monad.

I have my doubts about how well this works, particularly the 3d step. I’d value your opinion.

Monad tutorial, part 3

How the sequence monad works. The need for a “patcher” function to fix up results of the last function called by a chain of deciders. A better description of a monad: a decider and a patcher.

Part 1 of a tutorial on monads

I’ve read or watched several tutorials on monads, and they left me confused. Thinking about why that was, I decided they emphasized a rather uninformative terminology too soon and obscured core ideas with surface syntax. So, following in the footsteps of countless others, I decided to teach monads right (dammit!). I’ve produced part 1 of a tutorial that ignores terminology and uses pictures to avoid the distractions of surface syntax. I’d like you to tell me if the approach is promising. If so, I’ll continue.

Monad Tutorial, Part 1 (Monads as Deciders / Identity Monad)


The tutorial assumes you know some Lisp. I use Clojure for examples.