Most conferences nowadays have BOFs, “Birds of a Feather” sessions usually held after-hours on one or more nights of the conference. These are informal get-togethers where folk sit around and talk about a topic. These topics are usually set in advance, either by conference organizers or existing speakers. Like most conference sessions, attendance varies. This is my experience with BOFs, at any rate.

This year, at cf.Objective, Bob Silverberg asked if I’d coordinate a Test-Driven-Development (TDD) BOF with him. I accepted. I expected a handful of people. I was wrong in this expectation. It started small but quickly got way too big for normal BOF comfort. See, the problem isn’t with the number of people who attend: I was thrilled to see so many people. I do not know “how well” we did but I give us a “C”. The reason for this mediocre assessment is the subject of this post.

A BOF should be a place where you, the attendee, go with either A) some interest or B) a burning question. If you’re in Camp A, then all you should expect from a BOF is exposure to ideas. If you’re in Camp B, then I think you should get something approximating an answer to that question. If not “the answer”, then at least guidance. But when BOFs get too big, it’s unlikely you’ll get that. Lots of things stand in your way, probably the most prominent of which is one or two topics (and people) dominating the conversation. It’s what humans do, and I won’t put upon a BOF some expectation that it transcend humanity.

In our BOF, we had at least three burning questions:

1. What is TDD and how do I get started?
2. How do I test database interaction (and perhaps other network-bound services)?
3. How does TDD improve API design? (this is what I wanted to discuss, by the way)

A fourth lingering one was “How do I test ‘the entire app’?”, i.e. how does unit testing differ from integration testing (note that this has nothing to do with TDD at all).

This is simply too many needs to be met in an hour in a traditional BOF.

What a BOF should be

So what should a BOF be? If you’re in Camp B, it should be small and focused. BOFs sprung up lo those many years ago as a reaction to typical eyes-forward conference sessions. They’re a way to bring people together around a topic where everyone gets a chance to talk, not just a speaker. They are a discussion. They attempt to imbue a sense of the “hallway conversation” that conference-goers love to rave about. When BOFs get too big, they have failed this mission. Why is this? Perhaps it’s simply that anything that gets too successful becomes a victim of its own success. Let’s fix this.

How BOFs should be organized

BOFs should not be organized ahead of time, especially by conference organizers or speakers. Oh, I’ll  make an exception for “Meet the Team” events that you get at large conferences like Adobe MAX. Otherwise, they should be organic. This is simpler than it sounds. Here’s a recipe:

1. At the beginning of the conference, put a chalkboard or whiteboard out in some open space. At smaller conferences like cf.Objective, this is in the lobby adjacent to the conference rooms. In a larger conferences such as MAX, this is … the same thing.
2. Promote the chalkboard ahead of time, in emails to attendees, signage, Twitter, and other means. Make it obvious that this chalkboard thing is where you go to suggest BOFs
3. Organizers can put headers on the Chalkboard: D1, D2, D3, C1, C2, “The Bar”, “The Bar with fancy Tequilas”… etc.  These are the available spaces. Call them D1:8pm and D2:9pm if you have multiple time slots
4. People interested in a topic can write it under one of the slots. People who see a topic they’re interested in can put a line or some other marker underneath a topic to signify their interest in attending. Nothing fancy. Numbers don’t matter. A BOF of two is just as important as a BOF of 10.
5. At the time of each BOF session, people meet in the room and ask around to see who’s here for what BOF. My gut says self-organization at start time will take no more than 5 minutes

In our TDD BOF, I wish we had course-corrected immediately… I wish we had realized the interests in the room and asked people if they wanted to break out into smaller groups. Unfortunately, at that time, it probably would’ve been too late. We’d have first had to figure out what those interests were and then hope that a leader emerged (by leader, I mean “the person who says ‘let’s go over to this set of chairs’).  If we were more prepared, we could have had an idea of what kinds of things people might be interested in and when we saw the group get large (this didn’t happen until about 10 minutes in, by the way), we could’ve thrown out those topics for show-of-hands and then broken out. But you should already see why this is a failure in the making: it’s an inappropriate time for such a thing, considering by the time “real talk” started, we’d have been 15 minutes into it because ad-hoc organization is always more chaotic than if the organization had been happening – on the chalkboard – all week long.

There is a precedent

If this sounds strange to you… if this violates some sense of control that you feel needs to be exerted by those-in-charge, know that what I’m proposing here isn’t an original thought, and it’s not untested. In fact, entire conferences are run this way (Google “open space conference”). The entire Java Posse roundup is largely run this way, and it’s a smashing success (not because of attendance numbers, but by a far more important criteria… attendee reaction).

Imagine

You go to an eyes-forward conference and you have a list of topics to attend during normal hours. But you also have a burning question. You put it on a board. One other person comes. You talk for an hour about your shared interest. You might learn something, teach something, make a friend, make an acquaintance, learn “I can’t stand this person”, learn “I want to start a business with this person”. Maybe you yank out a laptop and code for an hour together. You never know where it might lead. It’s unpredictable, and energetic.

That’s the kind of spontaneity that is the hallmark of a great BOF.

Conference organizers: make it happen.

A few of our source code files contain Spanish text strings and smart quotes (i.e. curly quotes) copied from MSWord and pasted into Eclipse. These “special characters” have never caused problems in CFEclipse, but they were showing up as little boxes in CFBuilder:

I knew it was a file encoding issue but couldn’t solve it. The default text file encoding (window – preferences – general – workspace -– Text file encoding) was Cp1252, which was the same as CFE. However, viewing the properties of a file showed that the file was UTF-8 in CFBuilder but still Cp1252 in CFEclipse.

To get CFBuilder to behave like CFEclipse with respect to file encoding:

1. Window – preferences – general – Content Types
2. Expand the “Text” tree
3. Select “CFML Source File”
4. Down at the bottom, change the Default encoding

Warning: I wouldn’t change this setting unless you’re experiencing this problem yourself. To be clear, this falls into the “if you must do dumbass stuff like copy text from Word into Eclipse and retain the funky characters, then here’s how to fix it”

It’s hard work getting your team to enter bugs/issues into your issue tracker (“can’t I could just email you?”), and it’s even more difficult getting them to provide enough description to make the issue summary helpful. As the person who’s job it is to report issues to you, they need to “transfer context”. They know this bug intimately, either because they found it themselves or a customer/user reported it to them.

You – our heroic developer – don’t know anything about the issue. They want you to fix it quickly, and you want to fix it quickly… so why is it so damn hard to get them to understand that the more detail they provide, the faster you both get what you want?

I don’t have any good answers to that question, but I’m hoping this tip can help you incent them to give you more of what you need.

Editing the Description textarea

Often, you want users to enter the following:

1. a link to the page that’s causing troubles
2. relevant IDs (order ID, for example)
3. a description of the behavior they expected
4. a description of the actions they took that resulted in the unexpected behavior

Here’s what my description template looks like:

You probably have others. To Pre-populate your with a customized template:

1. Navigate to your jira install directory. Drill down to WEB-INF\classes\templates\jira\issue\field
2. Save a copy of description-edit.vm (to be safe)
3. Edit description-edit.vm, like so:

#controlHeader ($action $field.id $i18n.getText($field.nameKey) $fieldLayoutItem.required $displayParameters.get('noHeader'))

## setup some additional parameters
$!rendererParams.put("rows", "12")
$!rendererParams.put("wrap", "virtual")

## marc's custom hoogie
#macro( setDescription )
-- All your custom stuff goes here --
SYSTEM: Dev  |  Test   |   Staging |  PROD

LINK TO DEMONSTRATE BEHAVIOR:

ACTUAL BEHAVIOR:

EXPECTED BEHAVIOR:

STEPS TO REPRODUCE:
-- your custom stuff ends here --
#end

## let the renderer display the edit component

#if ($description=="" || !$description)
#set ($description = "#setDescription()")
#end

$rendererDescriptor.getEditVM($!description, $!issue.key, $!fieldLayoutItem.rendererType, $!field.id, $!field.name, $rendererParams, false)

#controlFooter ($action $fieldLayoutItem.getFieldDescription() $displayParameters.get('noHeader'))

Restart Jira

That’s it!

You can read more about customizing Jira templates here.