Original post by Michael Bleigh via Intridea
This past weekend I participated in Hack the Midwest, a Kansas City hackathon. The event was a huge success drawing a crowd of around 100 developers. As one of the visiting developer evangelists said, it was a great turnout for a New York hackathon, much less one in the midwest.
At the competition I built Qup.tv, a simple service that will send you email alerts when Netflix adds new titles to its streaming catalog. I was lucky enough to win top honors at the event, but this wasn’t my first rodeo. With three Rails Rumbles, two Node Knockouts, and a Startup Weekend under my belt I’m beginning to get a sense of what works and what doesn’t. So here’s my list of things to keep in mind when competing in a hackathon:
1. Have a Layered Strategy
You will never accomplish everything you set out to complete at a hackathon. Something at some point will take ten times longer than it was supposed to, so you need to plan for having multiple goals any of which could end up being the final product. Your first stage should be something that you expect you can complete in well less than half the time allotted. For example, here was my layered plan for Qup:
- Users can sign in with their Netflix account and will receive emails of the latest Netflix releases
- Users can add items to their queue or watch them with one click from the email. For queueing, users should not have to be logged into Qup or Netflix
- Users can filter based on Netflix rating, Rotten Tomatoes score, and
exclude genres they don’t want updates about - Track usage activity to be able to
show which of the titles are most popular Add in support for Amazon Prime Instant Videos and/or Hulu
Even though my app won I only got through about half of what I thought I might be able to accomplish in 24 hours. I also ended up doing a decent amount of work tracking genres and usage activity which didn’t show up in the final product at all because I didn’t have time to polish and expose it. Which brings me to tip #2.
2. Cut Everything That Doesn’t Work Well
It’s a hackathon so judges will excuse a bug here and there, but regardless of how cool or important a feature is if it is likely to glitch more than 20% of the time you should cut it out of your final product. A smaller, less featured, but smoothly working project is going to win over a more featured but buggy project.
This applies to any kind of live demo in addition to a “go check it out” URL. Don’t demo anything that the judges can’t do themselves when they use the app (unless they don’t get to use the app, in which case you’d better work hard to make sure your demo runs glitch free).
