company hackathons
A couple of weeks ago we had an Astun “Company Hackathon” for the first time, after the success of the MapAction Hackathon that we hosted a couple of months ago. I think it was a big success, and something that we will continue with in future. You might ask what the big deal is about a hackathon- we’re a technology company, what’s the difference between a hackathon and our normal work? There are a couple of key differences, which are also the things that made the event a success and worth persevering with. I think they are generally applicable to all hackathons, but definitely to company-based events, although as usual these are my own opinions and don’t represent Astun policy etc etc etc…
-
Do have a couple of ideas for what you want to achieve prepared in advance. These don’t need to be fully fleshed out, but should allow you to get to the end of the event with something concrete and visible to show for your efforts.
-
Do consider those people in the company with different skill-sets, and provide topics that they can get involved with or take ownership of.
-
Do appoint someone to informally lead the hack, even if all they do is ensure it actually happens and people don’t fall back to doing their normal work or checking email all day.
-
Ensure the work gets committed to your repository or the equivalent, and that it can be taken forward and not lost/forgotten. This is important even if it was just a proof-of-concept or something you don’t intend to pursue as you still need to record what you did and what the conclusions were.
-
Do make people present the results of their work. This provides an extra incentive to achieve something concrete within the allotted time, and also ensures that people get the recognition and ownership for what they have done.
So what did we look at in our hack? The overall focus was on a test suite, and a set of data to be included in an install for workshop or testing purposes. For the test suite we ended up using PyTest, basically because it’s very easy to install and configure (even on Windows), is actively maintained, and has good documentation. It’s also really easy to write tests! At the end of the hack we had a good initial set of tests, a workflow for installation on a client’s server, and a set of objectives for we want to implement in future.
The “data group” looked at putting together a dataset that we can supply with installations, and that demonstrates all the functionality of the our software. This is in no way less important than the test suite- good data that shows off your software is vital. You can have the best software in the world but if you can’t demonstrate it, or it looks superficially rubbish, then that won’t stand for anything.
In conclusion, hackathons (targeted and well managed) are good for rapid assessment/development of discrete ideas. They are expensive- getting everyone together to work on unbillable tasks for a day or two costs a fair bit, but if you plan them properly and take the ideas forward then the benefits will definitely outweigh the costs. They are also very good for company morale and cohesion, which has to be a plus!