Back in December, I attended Angelhack Toronto along with a couple friends of mine from the University of Waterloo. Together, we built PictureThis, a simple web application designed to let users create silly MadLibs-style stories featuring randomly selected photos of themselves and two of their Facebook friends. I'd never built a complete Rails site before; in fact, the last time I used Rails was probably in my second year of University when I built a semi-functional ranking site for our in-house NHL 08 matches. Needless to say, I was amazed when PictureThis managed to grab an honourable mention from the judges amidst all the incredible entries submitted by the other four hundred or so attendees. I'm looking forward to what the winners (AirPost.io and Raffi) put together for Global Demo Day next week... But I'm getting ahead of myself. What was the event like for a first time hackathoner like mef?
The event itself was a blast. For my first hackathon experience, I thought the entire weekend was run exceptionally well even with the enormous turnout. I'd heard a lot of great things about hackathons from friends and colleagues coming into the event, but had always come up with some weak excuse not to attend. This time, however, I had the benefit of an excellent team, a fun idea to run with, and a renewed enthusiasm in picking up Rails, so when I arrived Saturday morning I was eager to get started.
The first thing I should mention is the location. Angelhack Toronto was held in the Burroughes Building in Queen West, home of the Extreme Startups accelerator. It's a pretty gorgeous open space when it's not full of a bunch of overworked, pungent hackers; there's lots of natural light, exposed beams, etc. It's also in a great area downtown since there's lots of good food & drink nearby (Banh Mi Boys and 416 Snack Bar, for starters). However, that doesn't really help during the event, does it? Thankfully the catering for the event was surprisingly good and there was plenty of free beer.
With over four hundred attendees split over three different floors, it was clear that not everything was going to work perfectly. The WiFi service ended up being pretty spotty, which made Github pulls a bit slower than normal and caused problems for some of the presentations. I'd made sure to download everything I needed ahead of time (namely Rails and the gems I used for our site) so the slow WiFi didn't end up affecting us much, it was just something we had to plan around, During the final presentation, we had offline backups ready if our connection ended up being too poor to do a live demo, which ended up being the case. When we noticed how long it took just to sign into Facebook during our presentation, we quickly transitioned to our offline pages and carried on (I wonder if anyone even noticed). Other than the spotty WiFi though, I was surprised by how smoothly everything went. I'd like to thank the organizers and volunteers once again for doing a fantastic job controlling the chaos over the weekend.
In terms of development, I was pleased with how the code turned out (you can browse it all on the Github repo), but it certainly didn't happen by accident. I went into the event with a rough design document that described the work flow, data model, and pages ranked by importance. Once the coding started, we divided up the work and within a couple hours had something functional, albeit hideous and a bit clunky. By midnight, we had built out the key pages (landing, story creation, and story view) and everything worked, which meant we had the remaining time to polish the experience and clean up the design. I tend to believe that for every "unit of time" spent on a project, you should be able to finish 90% of the remaining "volume" of work. I call this my 90% Rule, and it has two practical results:
- You should always assume that the first 90% takes just as long to finish as the next 9%, so plan accordingly
- No matter how long you spend on a project, you can never be 100% finished
This theory has never been published or peer-reviewed so I can't say with confidence that it is universally true, but it's served me pretty well thus far. For this project, it meant we could spend the first half getting 90% of the site built (all the core functionality), and the second half cleaning around the edges and buttering up the design. I feel like controlling scope is something that a lot of the hacks had trouble with, leading to unfinished and unpolished results. For us, when Sunday afternoon rolled around we had polished the product to a point where it worked and looked pretty good (for a first time effort), so we were ready to demo.
Presenting our project in front of a crowd of approximately six hundred people (including ten local industry judges) was a bit nerve wracking. I don't think I've ever presented in front of a crowd that large before. With only two minutes to present, we had to be very economical with our time, so we cobbled together a rough plan:
- Only use two speakers, to simplify the flow
- Pick a good opening line to set the tone for the presentation (in our case, it needed to be silly like the product)
- Spend less than thirty seconds pitching the idea before starting the demo
- Quickly walk through the three main pages, with offline backups of each page ready in case there are technical problems
- End the presentation by explaining where the project could grow from here
I'd like to think we nailed all of these things, but truthfully I kind of bungled the finale by trying to sneak in another technical detail (which was completely unnecessary). However, we still delivered on everything else well enough to win the judges over and get an honourable mention along with six or seven other winners.
All in all, Angelhack Toronto was an awesome weekend. If you're thinking about entering a hackathon, I'd highly encourage you to attend the next one that pops up in your area. Just make sure you set realistic goals, come prepared, and enjoy the ride.