I was asked recently to help our Social Committee with a problem: They arrange coffee meetups between employees at MaRS Discovery District, which is manageable with a short list where they know pretty much everyone. They are looking at expanding these meetups to (possibly) include an order of magnitude more participants. But this becomes a list management problem, as they need to figure out a way for these participants to be paired in a way that the list manager doesn’t tear her hair out every month going crazy with a list of participants hundreds of people long.
Enter the graph database! Or not. I’ve played around with Neo4j in the past, and as cool as it is, I didn’t have a bandwidth to maintain a Neo4j database on top of everything else. Also, the group in question is very comfortable with Google Spreadsheets and has a Google Form plugged into their current list.
When building out a solution that I don’t want to have to go back and keep revisiting, I do a couple of things: build it using a technology that is common enough that the client could hunt down a solution (or find someone else fairly easily) and use something that client is already comfortable with.
Basically, an interested participant would fill out a Google Form to populate a spreadsheet. A screen capture of the form is below. 
Once a list of interested participants was built up, there should be a ‘one click’ pairing of matches and then another ‘click’ to move approved matches to the final list. There was some ‘common sense’ logic that needed to be built in, that would be obvious to a human, but less obvious to an algorithm without being explicit:
- the participant can’t be paired with themselves
- since this is about meeting new people, they can’t be paired with someone from their own department, or organization, if the company is small enough
- they can’t be paired with someone they have already been paired with
- maybe there is some organization and/or department they already closely work with, so we should avoid pairing with those
- you also want to be able to deactivate (and possibly reactivate) a participant for whatever reason
- as alluded to, above, the list manager wants to be able to eyeball the list of potential matches
- date stamp automatically
My solution meant a script entailed creating a ‘no-go’ list using Google Scripts embedded in the Google Sheet and then looping through potential matches until it finds someone that can be matched (e.g. is NOT on the ‘no-go’ list). It’s sort of a negative option approach and, yeah, if there were thousands of names and this had to be done in real time, for sure another solution would be better. In this case, because this script can take a few minutes to run and we’re looking at a few hundred names, maximum, then this solution fits the current scope. (Also, given this is a ‘side of the desk’ in-my-spare-time favor-for-a-friend kind of job, this should work).
Logic and workflow displayed visually, below:
As for the logic itself, it works pretty well. One small hiccup it that it doesn’t optimize matches, but rather locks in the first match it finds. So the last two participants may get ‘shut out’ even though there is a match out there, for them, somewhere. A graph database would be less likely to do this, but in the short term, this can be tweaked manually by the list manager, who still comes out ahead given the alternative of plowing through hundreds of names manually, cleaning up one or two at the end isn’t so bad.
You can see the result in the Google Spreadsheet here. Or if the link is broken, here is a screen capture of the first sheet, with the button controls (basically two images which trigger the scripts).
