I’ve participated in a handful of coding events and hackathons in the last few years including a coding sprint with UCOPS, Startup Weekend (winning in 2011 with HeroBox), and more recently, the MaRS Energy Hackathon (honourable mention with Emmit).
These events typically take place over weekend. At the reception, visionaries and entrepreneurs pitch their ideas to developers, designers and business folks in hopes of acquiring the best talent. For the next 48 hours, teams are required to develop enough value in order to convince a panel of investors or experts that they’ve created the best product.
There’s three things that I love about these weekends.
- There’s always an incredible about of energy. You may not have worked with your team before, but you know that everyone who is there, chose to be there. They aren’t getting paid, and quite often it’s the opposite–there is a registration fee. They work for more than 8 hours a day and many choose to stay the entire night to get it done. You learn to appreciate how much people can accomplish when they have a vested interest in the problem.
- It really captures the spirit of software development.
- Like most projects, you start by being overly ambitious. Wouldn’t it be great if we had amazing graphicsor a fully integrated backend? But as the deadline approaches, it becomes increasing clear that with fixed time and resources, we must begin to cut scope. We reach a point where even adding extra bodies won’t necessarily increase output due to prohibitive overhead costs.
- You’re forced to prioritize features and deliverables. What is the objective and what’s the roadmap to get there? At Startup Weekend, the goal was to demonstrate a viable business, so we spent a fair amount of time creating glossy mockups to be used as props to engage potential customers. It helped us pre-sign $25,000 in commitments thereby showing there was a problem worth solving. Actual development took the back seat. In contrast, at the MaRS Energy Hackathon, showcasing what can be done with the Green Button API was more important. In the end, we sacrificed some of the glamour in favour of more functionality.
- With 2 days to develop a proof of concept, you can’t afford to spend a lot of time on a problem. If you get stuck, you ask for help. If they can’t get it work, you try a different approach. The goal is always to get the smallest piece of functionality to work, and to build on top of it.
- Subconsciously or otherwise, teams tend to fall into agile practices. Everybody sits at the same table, steering meetings are held in front of a easel pad or whiteboard, and activities are pinned where everybody can see them. Smaller groups are broken down by expertise so that they can task individual exercises. Problems are raised and solved by talking across the table, crowding around a screen or sketching on a piece of paper.
- Cross functional and interdisciplinary teams. These teams shine the most at the demos. Given the same set of criteria, people can create vastly different thing. You can tell the composition of the team by the final deliverable. Polished designs are favoured, but people are really wow-ed by working software—things that they can play and interact with. Business developers and marketers are often overlooked until now. You need a good narrative to sell the product and make it relevant, and when someone hits a key point, collective nods are witnessed across the room.
At the end of the weekend, everybody is celebrating the amazing ideas and proofs of concepts borne of the hackathon. Some become successful startups (Visual.ly came out of the 2010 startup weekend), others inspire future generations to participate (UCOSP).
If you’re interested in participating in one of these events, here are a couple of hacking events that run annually: