How to win a Hackathon

7 easy steps to success on Cloud Foundry Summit Hackathons

At last Cloud Foundry Summit in Philadelphia my friend Benjamin Gandon (from Gstack.io) and I won the bi-annual hackathon for the second time in a row. So in the aftermath of it we were asked to share our knowledge on how to win these contests because it was my third win in four participations.

For those of you who do not know about the hackathons, at each of the last five Cloud Foundry Summits (North America and Europe) the Cloud Foundry Foundation organizes together with IBM a contest to extend the Cloud Foundry ecosystem in some way. The contestants can team up in groups of up to four people and have to develop their software in a little bit more than a day. Afterwards they have to present their work to a jury of Cloud Foundry old hands like Chip Childers or Michael Maximilien their ideas.

So to make you fit for the contest I recommend you to follow these steps:

1. Think big!

At the start of the contest you have to come up with an idea  of what to develop during it. Thereby people tend to solve a complex issue in their own niche of the Cloud Foundry ecosystem. That is always cool stuff and would benefit most of  the people in that setting. But when it comes to win the hackathon, you have to be the one with the bravest and perhaps most unusual idea. So you should always aim for huge impact. If you look at all the winners of the last contests there was no small minded idea:

  • Fusion of Functions-as-as-Service (aka serverless) with Cloud Foundry – like cf map-route you map events to your function you pushed to Cloud Foundry
  • Software-as-a-Service-Broker – The development of a service broker that is able to automatically provide applications pushed to Cloud Foundry to be made available in the marketplace
  • Fusion of Blockchain and Cloud Foundry – Creation of a Hyperledger Service Broker so Blockchain and Cloud Foundry Applications can work together
  • A Package Manager for BOSH – Development of a central package manager server and a CLI to manage package for BOSH releases and share work between them
  • Careless Delivery – The cf push experience extended to the creation of CI/CD workflows
2. Time is short - iterate or loose

The time until the end of the contest is not very much (one day). So focus on a very small MVP (Minimum Valuable Product) and then extend it in several iterations. I can’t point out often enough how short time you have is. In case you run into obstacles and you spend too much time on solving them, you will run out of time. So you always need a MVP to go back to, which was not long ago in case you have to present your work and are not finished with the last iteration. I suggest a MVP to be finished every two hours or more often. This means these iterations’ differences are very small.

3. It's all about the vision

Because time is so short and your ideas are huge on impact, there is no chance to have something production ready developed at the end of the contest (or it is too small in impact to win). So you have to sell the vision behind your project not what is done so far in the presentations. The judges know that you can not achieve the whole idea. What they want to see is that you have a road map for the time after the contest. In return, that doesn’t mean you don’t have to have anything done. But you have to sell your vision not the actual outcome at the end of the contest. The hackathon shall inspire the people inside the community to work together on new projects and ideas and by that give new impulses to the community. So aim for something that can extend beyond the hackathon as a new incubator project. Also your presentation is short timeboxed (5-10 minutes plus question time including demo time). So stay focused on presenting your vision.

4. Fake it until you make it

In the hackathon you are iterating hard and very fast. That means you produce a MVP at least every two hours. In the end you need to have something working to demo it in your presentations. On the way to your final version of code, you will face several obstacles. But things like integration are hard and time consuming. The judges know that you do not have much time. So hacking, tweaking, hardcoding, mocking, etc. are all allowed in your first MVPs. Do it if it speeds you up. Is there a good solution which takes time or short cut which is nasty but fast. Choose the nasty one. You are producing a proof-of-concept in a maximal short time frame. As long as you clean up with later MVPs its o.k. Judges want to see your idea working. If some details are not finished in the end, that is no big problem. But always play with open cards in your presentation. If you had to take a shortcut tell them. Do not forget to tell them what the real solution would be. Explain it with the time you needed to do the right solution.

5. The stage is yours

Your presentation is what is important. Here you present your work to the judges. Prepare for it. It is at least as important as your product. So prepare it right from the beginning. You may let even one member of the team do nothing else as the presentation. Right from the start. Iterate your presentation like you iterate your code. You make MVPs of your product. You should also make MVPs of your presentation and keep them in synch. So that you can easily present your work at any time. Your presentation is very short timeboxed (5-10 min including demos), so do not get distracted. Focus on your vision. Show that your stuff is working in a demo (I know live demo is hard. So train it. Have fallbacks prepared). Let the judges feel you thought that idea to the end and they can ask extending questions in each direction of the topic and you will be able to answer. Make it a good stage show. They want to have fun.

6. It's all about the team

Do not forget, Hackathon is a team effort. Find three other people who are good to team up with. You do not have time. Maybe your team is heterogeneous from different cultural backgrounds, different companies, different lines of expertise, etc. You have to get work closely together. So bring your team to the contest or adjust. You will have different approaches to things, do not take too much time with discussions on how to do things. Both approaches may be good. Simply use one.

7. If needed, be a prepper

Some of your ideas may need preparations. For example you need a Cloud Foundry installation or a Concourse. For some of your ideas you may need to mingle with that installed stuff and may break it. So you need an environment you are able to change without customers on it. Prepare it in advance. The one hackathon I participated and did not win, my team needed too much stuff prepared before getting started. So we spend too much of our time with preparations before getting started with the development. These things are not what gets judged. So you can bring them with you. The judges are interested in the new stuff not the environment they live in. You want to focus on your project not your development or test environment.

Conclusion

Hackathons are fun. They bring new ideas and expansion projects for the cloud foundry community. Working in a team with people from all over the world and from different companies on one project has always enriched me a lot. I hope my tips will help you and I am convinced that everyone has the chance to win. I keep my fingers crossed for you in any case and look forward to the next Hackathon.