Noel Rappin Writes Here

I want to tell you about LoneStar RubyConf and how my session went and all that, but first I want to tell you this seemingly unrelated story.

Once upon a time, my Senior undergraduate project was an educational software tool I built to teach fractions to elementary school students. (To give you the time frame here, it was written in Visual Basic 1 on Windows 3, and I had to ship my own desktop to the school to ensure that they’d have something I could run it on. Also, I travelled to the school via dinosaur.) Anyway, the metaphor for the program was slices of pizza, and at the beginning of the game, the student saw an uncut pizza on the screen. Times being what they were, I was using the VB graph library to draw the “pizzas”, so a new pizza was represented by a red 3D pie chart, which means it basically looked like a red cylinder.

The first student sits down and starts clicking on the pizza like there’s no tomorrow. I immediately realize that the red cylinder that I had set up to be a pizza looked like a huge red button right in the middle of the screen. I couldn’t possibly have given it more focus – honestly, it looked like it might launch missiles or something. And I know, that even though I had never thought of it in that way, that every student is going to do the same thing and that I’m going to spend my day telling people not to click on the pizza. Which is what happened. And I felt like an idiot – how could I not have seen it before?

Which brings us to my workshop at LSRC, “Correctness is only a side effect: Improving your life with BDD”. Here was the plan:

• I wanted the workshop to have kind of a code retreat kind of flavor, where the attendees would be able to focus on the pure process without regard for real-world constraints.

• The idea was that there would be a hands-on code problem, some discussion of how that was done via BDD based on the student’s concerns, then some prepared material based on the topic.

• The extended example was some kind of restaurant recommendation system, where each restaurant would have a score based on, at first, just ratings, then cuisine, price, location, and so on. The plan was to build up an increasingly complicated score function than show the process of using BDD to refactor it to it’s own scoring engine.

Well, that didn’t work out. Some of it did. The prepared material was decent – I’ve used a lot of it before. A couple of other things happened, of which the most interesting was how the attendees interacted with the problem.

I started by presenting the problem and mentioning that we were going to be focusing on testing a score method, because that was where the interesting logic to test was going to be. We walked through the failing test for initial conditions, did the method returning a literal to make the test pass, forcing a dynamic method with another failing test. So far, it seems to be going smoothly from my point of view. This was quite an advanced group of students – often when I do these workshops at regional conferences, the attendees are on the newer side, but this group was experienced, knowledgable, and already largely bought into the idea of BDD. (Based on earlier experiences, I had pitched the material maybe a little to beginnery for the crowd, causing me to worry if I was presenting any useful information to them at all).

Soon it’s time to break out for the first hands-on example, which is adding some new features to the score function. And the conversation went something like this: (I’m compressing this a bit for dramatic effect…)

Me: And the task is to make recommendations based on cuisine and price. You can do this by filtering a list of restaurants, or, I’d recommend trying to do it by modifying the score function.

Clever Attendee: How do we store the list of restaurants?

Me: Oh. Um. I don’t really care. In a real system the framework would manage that. You can explicitly pass an array of restaurants if you want, or just test the score function for a single restaurant.

Clever Attendee: Okay. But how should I store the list of restaurants?

Which was my red button moment. Of course somebody coming to this problem for the first time would want to know how things were stored. Of course a person who didn’t know what I had planned for the rest of the day would worry about that.

And I realized that I had landed in the uncanny valley of example problems – close enough to realistic for people to care about practical concerns, but not specified enough for those concerns to be nicely handled. And I missed it because I was fixated on how I would test the score method.

We worked through it, though, and even did another round of examples using mock objects to fake out a location service. Still, we weren’t able to get anywhere near my plan of building up a complex system via BDD. Again – my fault for not getting the example right – the attendees were all great.

Ironically, I think I could have gotten away with it if the example was in print, where I would been able to just work through the changes in the score example.

Toward the end of the day, I kind of got the feeling that everybody, including me, was a little frustrated, so I just came out and said it. “I think the prepared material has been fine, but I don’t think the example has really worked. Would anybody mind trying a more abstract, code kata-like problem via BDD as the last example.” Everybody pretty much unanimously picked the abstract example, and so we pivoted to the abstract problem that I wrote for Ruby Learning a little bit ago. People seemed to work on that enthusiastically.

In the end, I think I provided value for everybody that was there, many attendees said nice things. But I’m annoyed with myself that I wasn’t able to deliver everything I wanted to.

Lessons for next time:

• For this workshop, it seems likely that a well-specified but abstract problem is going to be better than a less-specified but nominally real-world problem. I think if I did this next time, we’d build up a simple game.

• The content of any workshop like this is always dependent on the attendees needs. As the presenter, I have to be paying attention to how people seem to be doing. As the attendee, you should feel free to let the presenter know what you are hoping to get out of the session and if it’s working for you.

So, thanks to those of you that came out – you were great, I hope you learned something, and I appreciate they way you helped me improve my teaching skills. But I really hope you learned useful stuff, too.