For anyone who enjoys (or has a knack for) planning, organizing a hackathon is not terribly difficult: it’s a matter of understanding your goals, assessing needs, and figuring out how to bridge the two. Naturally, this is much easier said than done.
The most important part of a hackathon, by far, are the demos. Why else — it’s what makes the event worth attending in the first place. Sponsoring companies wouldn’t offer money to anything that didn’t provide exposure. Developers wouldn’t forsake sleep if they couldn’t show an eager audience the hacks they built overnight.
Pulling off demos at Photo Hack Day and Photo Hack Day 2, for example, has proven to be a continuous learning process, with a much more public (and much less forgiving) learning curve. There’s no need to be a n00b, I’ve done a lot of the screwing up for you.
Almost every sponsored hackathon will have two sets of presentations: those that kick off the event (for sponsors to introduce developers to their APIs) and those that close it (for hackers to show what they’ve done). Since demos are the most visible component of the hackathon, ensuring that this portion runs smoothly is key to the overall opinion of the event’s success. The caveat: extensive preparation is useful to a certain degree. You can – and absolutely should – do a number of related tasks in advance, but a significant portion of hacker demos requires efficient, on-the-fly work that takes place within a short amount of time.
Photo Hack Day 2 was organized almost entirely through three tools: email, spreadsheets, and HackerLeague. How you choose to keep track of everything is up to you, but I’d strongly suggest the following for each set of demos.
Part I – API demos:
Part II – hack demos:
To-do on the fly
Remember the aforementioned caveat? This is it, and it’s the trickiest, most stressful portion of the event.
By creating incentives (i.e. sponsor giveaways to those who follow the feed, tweet about the event, or retweet any official posts), you gain a stronger following while making sure that hackers stay in the loop. This translates to a less chaotic process of organizing demos.
Here’s what I still haven’t figured out
Should there be a cap to the number of demos?
This has some very obvious pitfalls, but after four hours of demos, the judges and audience at Photo Hack Day 2 were equally exhausted. This translated to a rushed prize ceremony: it was getting dark, everyone had been at General Assembly since lunch, and hackers were beginning to shut down after a night without sleep.
If judges and attendees are only interested in the high quality hacks, should there be some sort of screening process? The tradeoff for a large turnout is a long Demo Day, and you’d hate to end the event on a poor note (read: tired, grumpy hackers and attendees.)
What alternatives exist to the monotony of demos? Is it worth dividing hack submissions into categories?
After the hackathon (and a much-needed day off), our team broke down the areas where we thought there was room for improvement – and there were plenty. Though the demo tech mishaps were the most glaring, the actual process of demoing needed work.
The consensus among a wide range of suggestions was to encourage (and more importantly, reward) creative and entertaining presentations with prizes; they provided a much-needed spell to monotonous ones. Good demos – especially those that are funny – make the entire afternoon worthwhile. In terms of condensing the block of time required for participants to demo, the jury is still out.
A final note
This is the summary of everything I’ve seen and experienced from the two hackathons I’ve organized, and the three cumulative months I’ve spent planning. There are certainly alternatives to all of these “methods”; a better way of approaching these things is to consider them variables. Trust that you understand the nature of your hackathon well enough to know what will work and what won’t.
Yes, demos are time consuming, and yes, they are stressful, but I absolutely wouldn’t mind doing it all over again. For the developers who appreciate cool APIs, for anyone who loves observing the creative process, and for the many people out there concerned with building community: organizing these type of events is so gosh darn rewarding. Awesome people should meet awesome people, and awesome products beget even more awesome products.
This, in a nutshell, is why we throw hackathons in the first place.