In a hackathon, a group comes together with a fixed amount of time, a lot of caffeine, and a shared goal to build something or solve a problem. By the end of it all, they need to prove results with a demonstrable minimum viable product (MVP).
Read more: What is a hackathon?
Here’s seven themes we see from winning teams.
While it’s natural to gravitate towards those you share the most in common with, the key to assembling the right hackathon group is in getting a variety of skills.
Include things like data analysis, programming, graphic design and storytelling. Diverse skills will get you the best results, and a wonderful side-effect is seeing others do things that you couldn’t or wouldn’t have done, and vice versa. It’s great to say, “wow, I couldn’t do that”, and hear the same said back to you.
Dominic Astley, from 2016 GovHack prize-winning team ‘Cylindrical Books’ explains: “We had a team of six people; three or four people who were mainly dedicated to the software development side of things, one dedicated to the graphic design, and another dedicated to doing the video.”.
It’s still important to identify common interests and values though, such as social justice, the environment, health or a new technology.
Using publicly available data, such as the government data that is made available through events like GovHack, can be one way to uncover a winning idea.
This data is available from Data.gov, so it could be worth taking a look to see what’s new and what catches your imagination. Many past GovHack winners “mash up” data from disparate sources, but that isn’t always the case.
Harry Smithes of 2016 prize-winning team “Four planners and a panda” said: “We just decided which challenges we were going to go for based on what we liked and what we thought we could do well on and which data looked cool”.
Topics that are on the national agenda can inspire interesting new solutions, bringing together data and software technologies in winning ways.
It’s also worth reviewing prize categories, as sponsors often offer great prizes for use of particular data or tools that they’d like to see used creatively.
Brainstorming, where the team can freely express ideas without fear of rejection or criticism, is a great way to get ideas flowing. Try to avoid switching to the critical-thinking ‘editing mode’ until the new ideas are starting to dry up.
Hackathon judges need to understand who the users for your idea are and be able empathise with how they will want to use your project. Keep it simple and remember that you need to tell a story from a user’s perspective and show them getting real value from the interaction.
You’ll need to tell a ‘user story’. This is something in the form of: “As a drone flyer I want to find out if it’s okay to fly where I am right now”, or “As a resident I want to find out which recycling bin to put out tonight”.
These stories will form the narrative of your final presentation and implementing those user stories will drive what data you require, how users interact with your idea, and how you present information.
Joining different data sources may not be as straightforward as you’d like.
For example, while a lot of data is in convenient-to-read comma separated text files, you may find chunks that need filtering out. Some data you source might express locations as suburb names, for instance, while others might use postcodes and some will use latitude and longitude.
There’s work to be done to ‘clean’ data before you can use it.
Often hackathons have ‘data mentors’ available to help with data and suggest ways of normalising it, so make use of them.
While not all hackathon entries are software — some are infographics for example — most do require some programming.
It’s tempting to learn a new language or library during a hackathon, but this is risky and a review of past GovHack winners, for example, shows that most teams use rather conservative platforms such as PHP/MySQL for the weekend of work.
Pick something you’re pretty fluent with and perhaps come armed with a skeleton application ready to customise.
Having something up and running early really helps hackathon teams to stay motivated and positive. Get the site, or app, or bot up quickly — even if it’s just showing static images to start with.
For many hackathons, you’ll need to provide your source code and assets as part of your entry, so it’s wise to create a git repository at the start and to use it during the hackathon. This also avoids a disaster caused by hardware failure.
Flesh out your entry by making parts of the project begin to work, bit by bit. After each iteration, present the system to the group or even to fresh outsiders to make sure what you’re showing is understood and to get important feedback.
If possible, get a minimum viable product going early.
Sourav Shah of 2016 GovHack prize-winning team “AAYA” offers the following advice: “One secret is not trying to do everything. You can’t get a fully functional app in two days, but we got the basic concept enough to explain to the judges. That was the key.”
In an event like GovHack, the end result is a presentation in the form of a video. Making a video is time consuming, and while it’s nice to produce a slick production, it’s best to focus on a brief introduction to the need for your idea and then get down to a demo based on your chosen user stories.
You’ll need to write up your hack on a project page describing what you did, the data used and the location of your source code. You can include a real working site or app but the busy judges are more likely to focus on your final summary or video presentation and the description you’ve provided to evaluate your work.
Always check out the guidelines behind the competition for final requirements of your entry and how to submit it.
This is part of a 12-part series into hackathons SmartCompany is publishing in association with GovHack.
Peter Marks is a technology commentator appearing weekly on ABC Radio National Breakfast. He’s previously worked in various technical roles for CNN, News Interactive, and Apple. Peter is a past competitor and now volunteer at GovHack.
Comments