We love a good hackathon for the purity of the data science. “Here’s the data. Have fun!” It is all the best bits of data science crammed into one session. Here at Oakland, we recently held a successful hackathon with one of our clients. They came with clear expectations, we analysed the data, provided answers to their questions, and the client left happy with their expectations met.
These are our top 6 tips to ensure your hackathon runs smoothly:
- Client Requirements
- Access to Data
- Business Insight
- Cloud Services
- Follow up
- Time Management
The first tip is the most important by far – we can’t overstate its importance. It should probably be included in this list multiple times! Understanding the client requirements from the outset is critical. Seriously, it’s important. Like, really important! Even if they are only high level, having clear concepts will focus the hackathon and ensure everything on the agenda has a purpose.
Imagine this scenario: you receive the data, create a few features, train and run a model, and you get fantastic results in record time. You are filled with joy that it has all gone so well. You run to tell the client the incredible news and they give you puzzled looks. You don’t understand why they aren’t thrilled, so you repeat yourself only for them to tell you the results don’t address their concerns. Nightmare! Best to avoid this scenario by always double-checking the work is meeting client requirements.
By constantly keeping the client in the loop, you keep them engaged, you ensure the hackathon is always on the right track, and you minimise the risk of the client leaving unhappy. No one wants that. If the client leaves happy and has been engaged the whole time, they are much more likely to participate in a future hackathon, continue working with you, and even recommending you to prospective clients. It’s a win-win for everyone.
Have we said this one is important?!?!
Access to Data
If there is one thing that brings a hackathon to an abrupt halt it’s not having access to the data. No work can be done. People are left idle. Everything stops. And the clock…continues…to…tick. Having access to the data is a huge priority. So much so, it should be sorted out before the hackathon even begins.
Talking to the client and being granted access to the data before the hack begins ensures that time during the hack is well spent, it demonstrates to the client that you are serious about getting things done, and it starts the hack on a good note, setting a positive tone for the rest of the event.
Given a data set with no column names, no labels, and no context, some analysis could be done to find something insightful. However, this is not in the true spirit of the mighty hackathon. We are all gathered in the name of collaboration. This is why it is crucial to get business insight from the client before, during, and after the hackathon. Sometimes the client doesn’t realise how valuable their knowledge is so you may need to tease it out of them.
Now that we have access to the data, business insight tells us what data to use, which data to make a priority, and what data is not relevant. The insight works like a microscope, focusing our attention on what is important.
To be fair, we’re pretty good at figuring out what data is important without the business insight but that would take much longer and we only have so much time in our hackathon. It is better to use all the tools at your disposal to ensure your hackathon prospers.
“Don’t reinvent the wheel, just realign it” – Anthony J. D’Angelo
We could spend our time during the hack worrying about memory storage on our PCs or configuring GPUs to optimise performance during model training. Or we could just throw the data on the cloud and run our code quickly and efficiently in an optimised environment, using services like Amazon Sagemaker or Azure Machine Learning. On top of this, these services provide the perfect environment to make quick dives into the data, carry out exploratory analysis, and throw together some plots of various relationships. All of which are very useful in the fast-paced spirit of the hack. Also, it makes the code a lot easier to productionise afterwards, which is always a nice bonus!
The benefits of using cloud services are clear. We can collectively spend more time digging into the data and generating results for the client rather than worrying about small details that don’t add any value to the hackathon experience. This, in turn, allows us to produce better results, meet our client’s requirements, and everyone leaves happy. A far better outcome than getting lost in configuration files.
The hackathon version of the question “If a tree falls in the woods and no one is around to hear it, does it make a sound?” is “If a hackathon happens and nothing materialises from it, did it even happen?” Following up with the client after the hackathon ends is mission-critical to ensure the work produced in the hack lives to see the light of day. Otherwise, it could very easily be lost into the abyss of Forgotten Hackathon Work (FHW). Things very rarely return from FHW.
We would suggest adding “Create a follow-up plan” to the list of things required to organise a hackathon because, without it, are you really running a hackathon? From the client’s point of view, it is probably quite important that something comes from the hackathon. For all the time and resources spent on it, the least we could do is ensure we follow up and make the transition from the hack to the next steps of the work.
In every other point, we have mentioned the concept of time in some form or fashion. It is so fundamental to the concept of the hackathon that it deserves its own point. We could spend three months working on a project or we could condense it into a two-day hackathon. If that two-day hackathon then overflows into becoming a three-day/one-week/one-month event, expectations are not met, deadlines are missed, and bridges may be burned. This could all be avoided with effective time management in place.
There are many ways to implement time management. You could introduce a schedule, time slots for different objectives, or even a timer for more exciting finishes. We can see it now: ten seconds flicker on the timer. Coders sweating, mechanical keyboards clacking furiously, coffee flying everywhere. The suspense. The drama. The excitement!
We would pay good money to watch that. But your client probably will not pay you if the hackathon overruns so make sure you manage the time in your hackathon.
Kevin Minors is a data scientist working at The Oakland Group