Things learned while pairing

I spent a Sunday in January at Corey Haines’s Code Retreat, out on the LeanDog boat. Aside from being too darned early in the morning, and aside from the fact that I had to bail at the 3pm break because my kid thinks she needs a ride to college, it was a fantastic use of time.

The event is like this: You show up, hang out, grab a pair partner, and start doing test-driven development (TDD) on a specific programming problem. After forty-five minutes, you stop programming, join the big group again for a debriefing, and do it again from the beginning with a new pair partner.

And you do this like six times during the day. (I only stuck around for four iterations.)

The problem space

The actual programming problem was to mplement Conway’s Game of Life. It’s a devilishly clever assignment, partly because anyone who’s taken more than one Computer Science class thinks they’ve already solved it. But oh no.

If you don’t know about the Conway game, it’s not really a game you win or lose. You have an unlimited “board” of square cells arranged in rows and columns. Each cell is considered either “alive” or “dead.” On each “turn” every cell counts its eight immediate neighbors (including diagonals); if it has fewer than two live neighbors it “dies” of loneliness; if it has more than two live neighbors it “comes to life”; and if it has exactly two live neighbors it just stays the way it is. That is all. You just watch it go, turn after turn. It’s just cool. There is no object other than watching the patterns that “grow” from various starting configurations.

(If the above sounds like a really stupid waste of time, you are not a geek. Please find another career.)

Harder than it looks

This is actually kind of hard to implement in a real object-oriented way. How do you design your classes? Is there a Board that contains (“has-many”) an infinte number of Cell objects? That won’t work quite the way I made it sound, will it? How about keeping a collection (like a C# generic) of just the live Cells? (It’s a lot easier if you get to assume a limited playing field. But alas.)

What I learned

Somewhat importantly, Corey didn’t expect us to use any particular programming language. He encouraged us to pair with colleagues who were using languages we might not even know yet.

I learned a bit about object-oriented design, if by “learn” you mean “find things to argue with.” Briefly, master crafters like Corey seem to prefer a lot more abstraction in class design than I feel like wrapping my head around. I usually like a one-to-one relationship between code space and problem space; so to me an object is “a thing that does things,” and a class is the idea of what that object looks like and does. If I can’t think of it as a thing, it’s not an object– it’s a method. Maybe.

I didn’t get very far with my pair partners on any of the iterations. We kept getting hung up on the TDD cycle, confused with the problem space, or stuck on mundane tactical issues. In that way it was frustrating.

On the good side, I got to hang out and pair with Angela Harms on an iteration. There was a mutual aha moment when I said out loud, “A cell knows if it’s going to live or die.” Angela thought it was some Zen kind of cool. I thought I was having fun anthropomorphizing the code. We’re both right.

My man Chris Sanyk was there too. He wrote about it, and wrote about it again, and wrote about it yet one more time. Our favorite insight occurred when Corey said something about running unit tests only on public methods, which annoys me because sometimes all the interesting logic is in private methods. I was launching into a “rant” on this topic, according to Chris, when Chris simply said, “So write the test method inside your class.”

I was stunned for a moment, then opened my mouth to argue, realized what I was about to say would be wrong, then started to say something else that was wrong, and finally looked at Chris and went “aaaaaaah.”

Is that the right answer? Beats me. It’s not mainstream as far as I know. But it turned my idea of unit testing on its side.

Win: Cleveland GiveCamp

I’m probably just about decompressed now from the joy and struggle that is Cleveland GiveCamp. If you weren’t there, you missed a fun and exhausting time. (You also missed out on seeing me walking around with yellow CAUTION tape around my head. I’m learning to accessorize.)

How it came together

Mark telling yet another story at Cleveland GiveCamp 2010 closing demo meeting
Mark tells one of THOSE stories

You know this saying?

It is amazing how much you can accomplish when it doesn’t matter who gets the credit.

Organizing GiveCamp was like that. I was the nominal Leader of our semi-formal organizing committe, but I always cringe when saying that. Jon Stahl was the de facto leader, at least in part, because a) he’s organized big events before; b) he’s hooked up with the larger GiveCamp movement; c) he took charge of a huge portion of the logistical details; and d) it’s his boat. I’m not remotely comfortable giving orders or even strong suggestions, so it was often hard for people to tell it was “my” event. To me, “leading” stuff looks more like finding out what people need and connecting them. It’s a middle child thing.

Based on the capacity of the LeanDog boat, the organizing committee figured that 75 volunteers would be an ideal number. Working back from that, given an average of five volunteers per team, we thought it would be good to do projects for fifteen local nonprofit organizations.

Those goals turned out to be challenging. We didn’t have a surplus of applications for help from nonprofits, and while it seemed that we’d probably reach our volunteer goal we didn’t expect to go very much beyond it.

Then Margaret Bernstein visited the boat, and this article hit the Plain Dealer. Within a week, the requests came in by the dozens and we eventually received sixty-eight. About 130 volunteers registered in advance. I openly asked my fellow organizers, “How many volunteers is too many?” After all, that was nearly doubling the capacity of the boat.

And it’s a boat. It can sink.

That’s when Jon asked about using the terminal at Burke Lakefront Airport, which is less than fifty yards from where the LeanDog boat is moored. Burke said okay, and we became a two-site gathering.

Who did what

Among many, many other things that got done by other organizers:

  • Andy Craze went to a zillion user group meetings to recruit volunteers, and assigned them to teams a day or two before the event;
  • Larry Mingle made the Cleveland GiveCamp website;
  • Matt Beyer collated all the volunteer registrations;
  • Trish Rouru networked with many of our nonprofit partners, solicited food donations, and (together with Deb Stahl and Jane Winik) prepared all the meals;
  • Sam Nasr served as our Sponsorship Coordinator; and
  • Nick Barendt set up our fiscal sponsorship with IEEE Cleveland, talked to media people, and took care of many, many site details.

In summarizing like this I am leaving people out, and minimizing the accomplishments of those I did include. It really is amazing how much work goes into an event like this, and in the heat of getting things done it’s hard to remember who did what.

While they were not part of the organizing team, I especially want to pick out two other volunteers:

  • On Friday night, Amy Wong told me she was available to help write website copy for any and all nonprofits. Amy was busy all weekend with this. I think her words are on at least half the websites we did.
  • Also on Friday night, Heidi Cool (who was there as part of our social media team) foolishly reminded me that she can help with WordPress and design issues. We ended up doing about fifteen WordPress sites! Heidi was incredibly in demand. She also taught an hour-long seminar on WordPress content management for our nonprofit partners on Sunday.

What got done

Bottom line:

  • We took on twenty-two projects in software and website development.
  • Twenty of them were successfully completed during GiveCamp weekend.
  • All the nonprofit clients got training on using and maintaining their new software and websites.

That makes Cleveland’s the largest and most successful first-time GiveCamp. Anywhere. Ever.

Retrospective

Jim Gorjup solicited “retrospective” notes from all the volunteers and nonprofits. We wanted to know what worked really well, what could have been better, and what really sucked about this year’s event. Mostly, I took these handwritten scraps and passed them right along to Jim so he could collate them and talk about the themes, but one line got my attention. It went something like this, approximate quote:

I liked the way everyone cooperated and shifted from team to team as needed.

This was particularly evident when a scheduling application for the Richmond Heights Fire Department looked like it wasn’t going to get done. Jon–being pretty much the King of Agile around here–collected what we called the “rockstar team” of Ruby developers who were done with (or could be borrowed from) their other projects and prompted them to self-organize. The upshot, unfortunately, was that the project simply couldn’t be completed in a weekend. It was just too ambitious, and since the project was a last-minute addition to our lineup it was hard to know that ahead of time.

I count that as a win for the Agile concept. At least we were able to conclude that project wasn’t going to go, which gave us permission to drop it (for now) and reallocate our developers to something that had a better chance.

What’s next

In my closing remarks to the assembled GiveCamp community, I referred to “next year” even though there weren’t any specific plans to do this again. I caught myself and asked, “Wait, who wants to do this again next year?” I’d say the response was strongly in the affirmative. So we’re on for next year.

Which reminds me. There is still time to contribute cash for next year’s event!

Yeah, Jon gets it

Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.

It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.

Continue reading Yeah, Jon gets it