How to win a Hackathon

Posted on Jan 20 by admin

Camillus Cai was part of the 3 person team that won Hack&Roll 2013, and later a part of the 4 person team that won 3rd place in PenApps Fall 2013, the largest student hackathon in the US (and possibly the world). He’s now one of the organisers for Hack&Roll 2014.

Are you dead serious about winning?

Hackathons are supposed to be fun events for networking and learning, but sometimes, you might just want that top prize that badly. Whatever your reasons are, hackathons, like any other system designed by mere humans, can be gamed with impunity.

Plan well in advance

Most hackathons, including ours, require you to produce original work during the course of the competition, while imposing no restrictions about the planning that you may have done beforehand. This makes the degree to which your team plans and prepares decisive in the outcome of the competition. Everyone we know who has won a hackathon had usually put some thought into their product before turning up.

However, not being able to write code before the competition begins also removes the feedback loop in the engineering process, resulting in an inability to validate ideas and architectures. Thus, the measure of a good plan is not whether execution transpires as planned, but whether the plan facilitates effective action in the face of unforeseen events.

One corollary of this observation is that a highly detailed architecture-level analysis that one might do in a drawn-out software engineering project is at risk of becoming more of a hinderance than an aid. While your high-level analysis should establish the conceptual basis for the application or service you want to develop, it should remain as a starting point, and not become the centre piece of your app.

Time management is especially important in a hackathon because you have to get a lot of work done in very little time. One way of organising time is to divide the competition period into discreet phases of development like “setting up the stack”, “prototyping”, or “achieving a Minimum Viable Product”. This is not dissimilar to the concept of code sprints, except that each sprint is as atomic as possible.

Each phase should have a set of deliverables, and a reasonably accurate time frame for achieving them. At any point in time, you should be keenly aware of how your current phase is progressing, and not get distracted by additional details that you can only decisively deal with at a later time (the oft-quoted example of such a distraction is premature optimisation). When transitioning between phases, the entire team should stop to reevaluate the progress made so far in relation to the high level plan, making changes to the plan going forward as necessary.

Polish in a hackathon product is unexpected, and if present in yours, scores an inordinate number of bonus points. If development is moving faster than expected, consider continuing by touching up on the look and feel of your product, rather than trying to extend its feature set. On the other hand, consider pivoting or rehashing the problem if you find that the team is consistently falling behind on the development schedule: the end state of a hackathon product is not immutable, and a simpler (or even different) product that works well will do far better in judging than a grandiose idea with a failed execution.

Have a concept of operations

Elect the visionary as the team leader. Assign the most technically competent person to be the chief engineer. The period of the competition itself is not a good time to discuss things in committee.

Make sure that everyone on the team knows their role in the development process, and is working within their domain of expertise. This arrangement of labour tends to evolve organically if the team has worked together before, but the process can – and must – be engineered if you are putting together a team for the first time.

Collaboration tools like Git and Asana are immensely helpful. If you are using them, make sure they are set up and accessible before turning up at the competition venue, and that everyone on the team knows how and when to use them.

In particular, task management systems like Asana are invaluable in keeping the development process organised towards the end of the competition when the team is operating under fatigue. However, these systems require effort to maintain. When the team is fresh and on the same page at the beginning of the competition, it is easy to lose the discipline to keep your task record up to date.

Size up the competition

Walk around when taking breaks to observe what other teams are doing. If you encounter another team that is doing something similar, you will be faced with a decision to accept the competition, or to do something else.

Direct competition between teams is a tremendous waste of resources, and should only be entered into if your process or product is clearly superior to its opposition. Pay careful attention to morale and team dynamics in addition to the scope of the competing product. A tired or stressed out opposition will quickly lose cohesion when confronted with subtle displays of success on your part.

Avoid accepting competitions that cannot be determined decisively by specialising, or pivoting to a slightly different niche from the opposition.

Manage your pace

While working fast allows you to do more than other teams, working too fast leads to fatigue. Never burn out team members by trying to achieve too much in too little time. Burnt out people are disproportionately less productive, less cohesive, and are more prone to bad decisions than people who are working consistently at a slightly slower pace.

As a team leader, be aware of the mental state of your team at all times. Block off whole hours for rest and reconstitution if necessary. Avoid heroic code sprints, except perhaps just before the end of the competition. Rapid tempo should not degenerate into haste – you do not want to be faced with a massive regression half an hour before the buzzer.

Don't be a dick about winning

Remember that hackathons are supposed to be fun, and that each team is there for its own reason.

You are free to play this meta-game with other people dead serious about winning, but always be considerate and do not ruin the event experience for everyone else. Above all else, do not discourage people there to learn.

Whether you’re in it for learning, or in it to win, you may find out more about Hack&Roll 2014 at the following link: hacknroll.nushackers.org