Hackathons need focused, realistic scopes supported by sufficient technical talent.
I’ve attended a few in the shorter number of years I’ve been coding, including Gonzo Camp in Seattle and the more recent Hacks/Hackers opensourceathon. Each had a low to moderate level of success, from my perspective, mostly because peoples’ expectations weren’t met. For some, the expectation was to deliver a mostly functional piece of code. Others didn’t have any expectations. In addition, another problem is that a certain group of attendees run into the challenge of wanting to contribute but not knowing how to do so.
These problems can be mitigated by better preparation.
Specifically, I think a hackathon should have the following established in advance of the event:
- Accurate listing of who is attending and what their skill set is.
- Mechanism for identifying, expanding and voting upon project ideas. Bonus points if people can express interest in contributing to a project and volunteer for a role.
- A mission for the hackathon, which helps to articulate expectations of what will be accomplished in the time allotted.
In 24 hours I wouldn’t try for a breakthrough. But it is possible to focus for a few hours on a problem and come up with alternate approaches. Or to rework something that fell by the wayside in the past because of scaling issues perhaps. Or some piece of the puzzle was missing last time it was attempted, where a solution now exists.
The description for the Hacks/Hackers Hackathon at ONA10 details the what of doing but never the why of doing. Same for the Great Urban Hack. It’s difficult to know whether an event is a success if you never set expectations for it.
Sure, it’s possible to do this type of preparation the day of. If you can put these pieces in place before the event, it means they don’t have to happen at the event. The event can then be focused on the most valuable use of in-person time: working on the project.