This is a draft. Worth continuing the series? Let me know.
Critter4Us is a webapp used to schedule teaching animals at the University of Illinois Vet School. Its original version was a Ruby/Sinatra application with a Cappuccino front end. Cappuccino lets you write desktop-like webapps using a framework modeled after Apple’s Cocoa. I chose it for two reasons: it made it easy to test front-end code headlessly (which was harder back then than it is now), and it let me reuse my RubyCocoa experience.
Earlier this year, I decided it was time for another bout of experimentation. I decided to switch from Cappuccino to jQuery, Coffeescript, Haml because I thought they were technologies I should know and because they’d force me to develop a new TDD workflow. I’d never gotten comfortable with the testing—or for that matter, any of the design—of “traditional” front-end webapp code and the parts of the backend from the controller layer up.
I now think I’ve reached a plateau at which I’m temporarily comfortable, so this is a good time to report. Other people might find the approach and the tooling useful. And other people might explain places where my inexperience has led me astray. (more…)
“The anarchy of evasion” is a term that (I think) I read a few years ago. I occasionally search for it, but I’ve never been able to find anything about it again. As I recall, the idea is a reaction to the fact that an anarchist movement that forms an independent new society or transforms an existing society is… hard. So an alternative is to live within an existing society but try to make as many as possible of your activities and interactions run according to the principles you wished the whole society ran with. You behave as you wish, but in a way and context that increases the chance you won’t be noticed and therefore stopped.
The idea appeals to me, perhaps because I’ve always liked the idea of complex and interesting things happening unnoticed in the cracks. Probably a result of reading The Littles as a kid and books like You’re All Alone and Neverwhere later.
In some way, my original post makes it seem as if normal programmers are like the drug dealer D’Angelo Barksdale eating in a fancy restaurant in “The Wire“—everyone stared, the waiter rubbed D’Angelo’s ignorance of fine-restaurant customs in his face, and D’Angelo’s introspective attitude doesn’t hide a desperate desire to leave. Well, yes (though nothing in a programmer’s life is as bad as anything in a “The Wire” character’s life), but there’s more to it.
I think Clojure already suffers from being a language for hardcore programmers to solve hardcore problems. For example, that hardcore attitude makes things like nice stack traces seem unimportant. More: fishing through stack traces can almost become a perverse right of passage. Do you have what it takes to program in Clojure, punk?
The history of programming, as I’ve lived it, has been a march where expressiveness led the way and performance followed. I came of age when the big debate was whether us new-fangled C programmers and our limited compilers could ever replace the skilled assembly-language programmer. C won the debate. When Java came out, the debate was whether a language with byte codes and garbage collection could be fast enough to be a justifiable choice over C/C++. Java won the debate. Ruby is still being held up as too slow in comparison with Java, but even the pokey MRI runtime is fast enough for a whole lot of apps. Perhaps the emerging consensus is that Twitter-esque success will require migrating from Ruby to JVM infrastructure—and that’s exactly the kind of problem you want to have.
Against that background, it’s notable that Clojure 1.3 is taking a step backward in expressiveness in the service of performance. (By this, I mostly mean that performance—calling through vars, arithmetic operations—is the default and people who are worried about rebinding and bignums have to act specially. So my super-cool introduction-to-Clojure “Let’s take the sum of the first 3000 elements of an infinite sequence of factorials” example will become less impressive because arithmetic overflow is now in the programmer’s face.) That’s worrisome. There’s not much new in 1.3 to tempt the hitherto-reluctant Java or Ruby programmer. And unless I care about performance or am a utility library maintainer, I don’t see very much in 1.3 to tempt me away from 1.2.
Now, 1.3 is not a huge hit to expressiveness, and Clojure already has pretty much all the expressive language constructs that have stood the test of time (except, I suppose, Haskell-style pattern matching). So what else is left for someone of Rich Hickey’s talents to work on but performance? Documentation?
That’s a good point, but I worry about how performance will drive the constructs available to Clojure users. For example, multimethods feel a bit orphaned because of the drive to take advantage of how good the JVM is at type dispatch. There’s a whole parallel structure of genericity that’s getting the attention. And conj is a historical example: it’s hard to explain to someone how these two things both make sense:
As with arithmetic overflow, it strikes those not performance-minded (those not hardcore) as odd to have lots of generic operations on sequences except for the case of putting something on the end. “So I have to keep track of what’s a vector? In a language that creates lazy sequences whenever it gets an excuse to?”
Catering to performance increases the cognitive load a language puts on its users. Again, the hardcore programmer will take it in stride. But Lisp and functional languages are different enough that I think Clojure needs more focused attention on the not-hardcore programmers.
Now, the quick retort is that Clojure isn’t my language. It’s a gift from Rich Hickie to the world. Who am I to demand more from him? That’s a good retort. But my counter-retort is that I demand nothing. I only suggest, based on my experience with the adoption of ideas and languages. It’s hard making something. More information (from users like me) is probably better than less.
If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem.
… I could say that I read a snarky “[those losers]” implicitly attached to “okay for them.” I could say that “fifty percent of your time writing tests” and “rather spend that time thinking about my problem” are complete mischaracterizations of TDD as it’s actually done. And I can say that those mischaracterizations and that snark will be aped by programmers who want to be Rich Hickey.
I could say all those things, but the statement as written isn’t false. It can even be given a generous reading. But—if I’m right—programmers like me won’t stick around to hear defensible statements defended. They’ll just look for friendlier places where they aren’t expected to deal with decade-old arguments as if they were new and insightful.
Please note that I’m not saying Rich Hickie’s design approach is wrong. I suspect for the kinds of problems he solves, it may even be true that his approach is better across all designers than TDD is.
In the Agile2011 fringe, I’ll be doing a session with that title. Here’s my blurb:
One of the characteristics of Agile is that it favors the reactive over the proactive. For example, you grow the program in response to new feature requests rather than needing to know all the features in advance. Programmers regularly talk of reacting to “code smells” or paying attention to “what the code’s telling us”.
Being appropriately reactive is a skill. You’re not born knowing how to attend to subtle details, or how to react in a graceful, helpful way.
Skills can be taught. All over the world, people are learning the complementary skills of leading and following in tango, an incredibly improvisational and reactive dance. I believe the learning techniques tango instructors use can be adapted to learning other kinds of reaction—like the reactions of pair programmers to each other and to the code.
In the first part of this session, I’ll teach you some simple tango moves. We’ll concentrate both on learning the moves and also on how we’re learning the moves.
In the second part of the session, we’ll break out computers and write programs or tests (or collaborate on some other task of your choice). Will you be able to react more appropriately to your pair? Will you give off better signals? Will consciously practicing the skill of pairing help you be better at it? We’ll see!
Important note: In my experience, most people are more comfortable learning to dance with someone of the opposite sex. I’ve also noticed that there are a lot more male programmers than female programmers. I worry the title will attract only programmers, leading to a big imbalance. So I encourage everyone to encourage women at the conference to attend at least the first half of the session. They’ll get something out of it (beyond an introduction to tango).
I’d like to program for you as a temporary, on-site member of the team. I prefer that to coaching these days, though the latter isn’t out of the question. I’m not bad at Clojure and Ruby1, and my Java skills are adequate. Because I’d expect to spend a lot of time pair programming, the language isn’t nearly as much of an issue as it would be for solo work.
I’d prefer to be in one place for one to three weeks, though longer or shorter is also possible.
I’d like you to commit to paying for travel. (If I’m visiting more than one place on a trip, I’d divide up the responsibility.) I prefer you pay for lodging, but I’m also willing to couch surf (especially on shorter trips).
I don’t care all that much about working on cool technology or products. I do care about the atmosphere of the team, because their mood strongly affects my own. I’m looking for teams that are optimistic, enthusiastic, context-driving and cheerfully naive in the way I talk about in this video. That rules out a large number of Enterprise teams, who so often seem incredibly burdened by the institution. (Though that does mean that the rare optimistic etc. enterprise team would be particularly tempting.)
I have a chance to run my Top-down TDD in Clojure workshop in Oslo, Norway, in September, so I’m especially interested in European companies so that I can spend a month over there.
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.
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].”
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.
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. 
