Jacob Tomlinson
A couple of weeks ago I attended a hackathon hosted by the Met Office as part of the 2014 NASA Space Apps Challenge. It was a weekend event and the basic idea was to meet with other technology professionals/enthusiasts, form teams with these like minded folk, select a challenge from a long list of challenges set by NASA and solve it during the weekend.
Some people arrived at the hackathon with a challenge in mind and gave a pitch to all the attendees to inspire them to join their team. I was one of those people and I think my pitch was pretty good as around a fifth of the attendees joined my team. The challenge I proposed was to develop a game about mining asteroids.
One of the main reasons I decided to lead a team at this hackathon rather than just join one as I have done in the past was because often I find that the team leaders are too ambitious (or possibly naive) about what they want to achieve and then end up with a project at the end of the weekend which isn’t even half finished and doesn’t really work. At the end of a hackathon you have to give a presentation and I’ve seen far too many people, including myself, say “If I had more time it would have done this”. I wanted to approach the project differently to avoid this from happening.
Me giving my pitch. Photo by Adam Burt
Firstly I wanted to do as much prep work as possible. Now it is against the “rules” of a hackathon to start the projects before the weekend but there are lots of admin type tasks you need to do before you get going with the project. Things like creating a blog and twitter account for the project, installing all the necessary software, deciding which tools and frameworks to use, etc. I wanted to get all of this done before hand so I could walk into the room, get a team, sit down in front of my laptop and start building. This allows the maximum possible time for working on the project.
While planning the event I wrote an article about how to prepare for a hackathon.
Secondly I wanted to take a more iterative approach to developing the project. I wanted to start by very quickly building something small and simple but also complete and “showable”. My intention was to use the tools and frameworks I had already selected to build a very very simple game within the first hour (in actuality to took two). I also wanted to have a big emphasis on being transparent and social with the project so I wanted to ensure that the game was available on the internet and had people playing it right from the moment we had this working prototype.
The plan then was to build on top of this simple game in a modular fashion in quick bursts. My intention was to create and implement new layers of features/functionality and deploy them every hour, but again it actually seemed to take around 2 hours per deployment. The main reason behind doing this is that it was inevitable that we would eventually get to a stage where we are racing the clock to implement something. Doing it this way means that if the clock wins (as it usually does) we still have something which is whole and working despite not having the final feature we failed to implement.
Many people refer to this approach as agile development and I did take some inspiration from that methodology. However I made a point of not mentioning the word agile at all while explaining my methods to my team. It’s all too common for people to get hung up on following a methodology or process to the letter and waste time discussing it rather than focusing on the project itself.
During the weekend we managed to add 6 full layers of functionality taking the project from a simple web game similar to the old asteroids arcade game to something much richer with multiple asteroid classes, different pickups dropped by the asteroids, objectives, achievements, a full back story, lots of educational resources and much more.
We were awarded “Best Gameplay” and are currently awaiting results from the global judging being carried out by the challenge’s creator Dr. Phil Metzger at Kennedy Space Centre.
I am very grateful for the excellent team I worked with but I am especially thankful to my friend and colleague Ian Gentry, not only for helping me plan the project and for bouncing ideas off but also for helping me manage the team when it grew far larger than I expected.
Most of the team. Photo by Adam Burt
For more information on the project see the following resources: