Another good day, and as always a quite successful conference: I came into the conference with two areas in which my testing doesn’t feel right, and I came out with concrete suggestions for what to do next on both of those; my off-the-wall session went much better than I could reasonably have hoped for; and a couple of the other sessions were interesting as well.

And it’s funny in retrospect how blase I’ve gotten about open space conferences: of course we managed to self-organize and come up with loads of interesting and useful sessions, isn’t that the way it always works? Amazing when I first saw it, but now I’ve seen it happen four years in a row, so it’s clearly a quite repeatable process.

8:30am

I didn’t end up attending any of the early morning sessions today, what with dog- and daughter-related interruptions overnight; I guess that counts as my session to take a nap in today?

10:00am: Coding Dojo

This ended up rather interesting in a completely unexpected way. I was looking forward to having a technical hands-on session instead of a conceptual touchy-feely session, and the plan seemed promising: we picked a problem to TDD (the Bowling Kata), and there were few enough of us (five plus the convener) that we decided to just rotate pairs through a single computer every five minutes.

But things went wrong in a bunch of ways right from the start: the convener inserted himself way too often (in my opinion), participants ignored each others’ suggestions and blithely threw away their code, they occasionally openly insulted each others’ technical competence, at times a participant had a hard time picking up on what was going on quickly enough to make any progress during the 5-minute coding slot. (And that’s just what I saw in the behavior of the other five people there; extrapolating from that, it seems quite likely that I was behaving badly in a way that I was blind to as well.)

I was thinking of giving up and leaving, but the thing is: these are dysfunctions we see all the time on real teams, they were just magnified because of the quick pace of the format. So I decided to stick around to see if we could resolve them; and, indeed, we brought up some of the worst of the issues and started dealing with them; half an hour later, we were going much more smoothly, and were writing actual workable code.

So: good stuff, though I still kind of wish we’d been able to spend more time on code issues than people issues…

11:30am: Enterprise Agile Transformation

Pleasant enough chatting, but I don’t have a lot to report here.

1:00pm: TDDing JavaScript

This was one of my sessions; I was happy enough for the conversation to go wherever people wanted, but ultimately it came out my dissatisfactions with TDDing JavaScript at work. The problem that I have is that my TDD instincts aren’t working well: the first code that I’m tempted to write (if I start from the user point of view) is so closely tied to the layout details that turning into tests would be tedious and lead to low-value, brittle tests; I’m also not entirely sure about tests that I’d get starting from the back end communication point of view, because there I’d be testing XML parsing that is both relatively simple and could silently go stale if the format changes. So the upshot is that I start off not writing tests for my code, and I stay in that mode for far too long.

For the code adjacent to the back end, I really want integration testing; and, indeed, that would be useful at both ends, I should definitely do that more. So we spent some time talking about possibilities there (basically, me getting more of a Selenium education); that was useful, but I don’t want to go down that path too deeply, because I’ll end up with slow tests that have a hard time getting at non-surface problems.

Fortunately, Mike Wright managed to eventually break through some of my problems: after encouraging me to explain why I didn’t like the tests I would normally think about writing, he took a BDD-point of view to asking me how to express tests that I might like to write. And by taking that approach he managed to come up with tests that get close to the layout to while not being excessively brittle. E.g. if I’m testing a feature that involves voting for one of two avatars in a walkoff, I can test that the layout contains exactly two divs with a “walkoffAvatar” class: that’s expressive enough to force me to be doing something meaningful with the data when generating the layout, but it’s generic enough that it doesn’t tie me to the specifics of the layout, specifics that are only useful to the extent that they produce something pleasing to a human eye. Best of all, it means that I can start happily unit testing right from the start, instead of trying to pick a moment when the code is getting interesting enough to need testing.

Really useful, I’m hoping that this will encourage me to TDD my JavaScript significantly more often than I have been these last few months.

3:00pm: Agile for Introverts

I’m an introvert, as was the convener, but a lot of the participants weren’t; can’t I escape for a moment from those extroverts? (Joke.) Honestly, I was surprised how many extroverts attended, but they were really very well behaved, I probably spent as much time talking as most of them did.

The notes list many of the topics we talked about, but two concrete techniques seemed particularly useful. One is to maximize the chance that introverts will speak up in a meeting: when you’re thinking of moving on to a topic, ask if anybody has questions, then pause for a second, and then count down from five to zero, starting with an open hand and folding down one finger at each number. (A variant of a technique I found very useful when teaching: when you want to elicit questions, wait for noticeably longer than is necessary for people to start feel uncomfortable with the silence.)

And the other is some gestures that you can introduce: wave your hands with fingers spread out to express agreement, hold up a hand with two raised, crossed fingers to express that you’d like to speak fairly soon; and one other gesture whose details I can’t remember (maybe a sort of hitchhiker’s thumb?) to express that you’d like to make a followup comment to the last statement. So normally those last people get priority, but if somebody’s been waiting with fingers raised for a while, you give them priority.

Post Revisions: