Solving puzzles #
Like most software developers I like tasks that involve solving more or less complex problems analytically. Most
developers I know love puzzles - either those that involve dis-entangling metal rings, or those involving putting
wooden pieces back into order, or even solving Rubik’s cube:
 |  |  |
Working on the schedule for Berlin Buzzwords, I noticed that coming up with a good schedule actually has a lot more in common with solving puzzles that one is usually aware of: First of all talks on similar or related topics should not take place at the same time. Presentations should be grouped according to common topics so attendees don’t have to switch room after each and every talk. In addition some speakers have a tight schedule themselves and can only be at the conference for a day.
It gets even more interesting if after having put up a draft of the initial schedule you start filling the gaps, publishing those talks that were confirmed later than others or could be accepted only after freeing a spot somewhere else.
I spent the past few day re-arranging the Berlin Buzzwords schedule a bit. I added Christophe’s talk on Apache Hadoop from an industry perspective. After adding it, I had 45min left in the NoSQL track - on the other hand there was a speaker from the Lucene community that we very much liked to have in. So off I went, sorting and shifting around until finally the Lucene talk ended up in the Lucene track and a Hadoop talk that was formerly there ended up in the Apache Hadoop track, resulting in one NoSQL talk from the Apache Hadoop track moving over to the NoSQL track…
To cut a long story short: The schedule is final now - unless changes need to be made last minute.