In a hackathon, a group comes together with a shared goal to build something, or solve a problem within a fixed time period that can then be demonstrated typically with a minimal viable product.
Here’s 7 themes we see from winning teams at past GovHack events:
Forming a team
The key is in getting a variety of skills, including things like data analysis, programming, graphic design and storytelling. Diverse skills are best, and a wonderful side-effect of working together is seeing others do things that you could not do, and vice versa. It’s great to say ‘wow, I couldn’t do that’ and hear the same said back to you.
Dominic Astley of 2016 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.”
The team should share some common interests, perhaps social justice, the environment, health or a new technology.
Finding an idea
GovHack encourages Government to open up interesting new data each year. Take time to browse Data.gov to see what’s new and what catches your imagination. Many past 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.
Review the 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 creates a non-critical environment so that fanciful ideas can be freely expressed without fear of rejection, 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.
The judges need to understand who the users are and be able empathise with how each user will want to use your project. Keep it simple and remember that in the video you need to tell a story from a user’s perspective and show them getting real value from the interaction.
User stories are in the form “As a drone flyer I want to find out if it’s ok to fly where I am right now” or “As a resident I want to find out which recycling bin to put out tonight”.
Classify the stories into must have, nice to have and stretch goals.
These stories will form the narrative of the video and the implementing of them will drive the required data, user interaction, and presentation of information.
While much of the data is in convenient to read comma separated text files, there will be many columns that are not required. You’ll find that joining different data sources may not be straightforward, for example some data expresses locations as suburb names, while others might use postcodes and some will use latitude and longitude. There’s work to be done to bring these together, sometimes requiring joining tables.
Real data has bad items and these may need “cleaning” before use in software. Data providers welcome feedback on the usability and correctness of their data.
At GovHack there are data mentors available to help with data and suggest ways of normalising it, make use of them.
While not all 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 GovHack but this is risky and a review of past winners show 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 the team 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.
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 weekend. This also avoids a disaster due to hardware failure.
Over time flesh it out your entry by making parts of the project begin to work. As the outcome is a video it’s possible to not delve into parts that haven’t been fully built so you can concentrate on the core user stories and leave placeholders to come back to if time permits.
After each iteration it’s great to 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 before you make your video.
If possible, get a minimum viable product going early. This reduces stress and lets the video makers start to practice.
Sourav Shah of 2016 prize winning team “AAYA” said “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.”
Preparing the writeup and video
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.
Making a video is time consuming. Many teams allow much of the last day for the video preparation and editing. 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.
See the competition handbook for final requirements of your entry and how to submit it.
You can include a real working site or app but the busy judges are more likely to focus on your video and description in evaluating your work.
Dominic Astley said that some of the team started the video “as soon as we had the product vision available. Pretty much on the Saturday when we new what we were making they went and started collecting stock footage and footage of city cycle racks. One of the things we did on the Sunday was record the audio track”.
If you’d like to experience a hackathon, check out http://govhack.org
Written by Peter Marks for GovHack.
Peter Marks is a software developer and technology analyst.
He is a regular contributor to ABC Radio National and blogs at http://blog.marxy.org