|
We attended the Foursquare hackathon yesterday as participants and ended up winning with our thedealio.at private messaging app. To be honest, the only thing we had completed prior to arriving at 1:00p was that we knew the idea. We had no name, no code written, had not heard about the new API features released, nothing. So at least it's one datapoint that the winners aren't all pre-developed, polished products. For me, the biggest benefit of hackathons are that you are absolutely forced to use all sorts of skills, not all developer-focused. We had to discover a problem that was worth solving for a lot of people (P/M fit, I suppose). We had to battle with stupid issues like buying an .at domain name and having my credit card get locked up due to an overseas suspicious purchase, then having to wait for DNS to propagate so we could get an SSL certificate issued as required by a new feature of the Foursquare API. Also how the look and feel should be, the UX--simplicity, fun, and engaging. We spent the first three hours writing no code, just getting our game plan in place. Then of course in the actual development we broke all kinds of rules like code duplication, no testing, editing code directly on the production server, etc. We focused squarely on speed, knowing that time would be our biggest threat. Which brings me to my main point. Building any software product is all about compromises, and knowing when to make them. It does go against the spirit of a hackathon to bring a polished product to demo, while just networking all day. We didn't do that and did okay. But only by using every means available (including pretty much skipping dinner). I hope that the possibility of polished products doesn't hurt the hackathon spirit, and this post is mostly to offer encouragment that single-day hacks can still hold their own. There were some really great hacks there, and the ones I know that were built just yesterday were among my favorites (4squareand7years being my particular fave). |