Recently we organized a hackathon for the Kraków Java community. In this post I’d like to share our lessons learned. I do hope you will find this helpful in making your own coding events great.

From the conception of the idea to organize a hackathon we knew it would be tremendous fun to get all the ingredients right and see how they come together to form something big. But would the participants share our enthusiasm at the culminant moment? We didn’t have a definite answer, so we decided to plan everything carefully and leave as little things to chance as possible.

The decision was to hold the event under HackKRK which is already a well known brand in Kraków for providing an absolutely amazing level of creative fun to the attendees. Previous stunning HackKRK hackathons were an additional motivation for us to aim very high from the very first moment.


We spent some time brainstorming, arguing and rotating ideas to eventually agree on our mission that would be to resurrect the long-dead joy of the late 80s and early 90s. As kids we had all been playing our Ataris, Commodores and Amigas and we share the same belief that those times were so much better in terms of gaming.

As for our particular implementation we stuck to Good Old Tanks so the idea was to create a Scorched Earth multiplayer clone while keeping its great 8-bit feel. Attendees’ mission was to develop a bot that would outsmart the opponents and bring endless glory to its’ architects. Simple as that! ;)

And now what?

At this point all we had was:

  • a truly ambitious goal of delivering exceptional fun to the participants
  • woolly vision of getting there
  • strict deadline that we knew could not be moved even a single bit
  • none of the final solution
  • 6 enthusiastic Java engineers (including myself)
  • and indispensable Agata, who’s the Event Manager of Tech Space.

We started with disucssing and confronting our initial concepts to quickly move into proper planning.
Before long we already had an idea of the number of moving parts and the complexity of the thing we were trying to build.

We were able to identify significant components of the technical solution including:

  • game server
  • game rules engine
  • simulation engine
  • landscape generation
  • game visualization
  • ranking visualization.

The number of interdependent parts, 6 developers simultaneously pushing code and a strict time frame left us confident that we would have to approach this very seriously. And that was just the technical side of it. It quickly became a project that engaged us on a daily basis. On the other hand of course we did not want to apply superfluous measures if they were not fundamental to achieve the goal. This is why we approached it in highly agile manner by adding pieces only if needed and using totally lightweight tools.

Things you do not want to overlook

1. Redefine quality

Make sure you understand what quality means for a hackathon you’re organizing. Think out of the box as this might be something completely different to what you are used to in your day to day job. Pay attention to the environment you will be running your hackathon in, as it may have not much in common with your production setup.

In our case one of the crucial quality defining elements was the number of teams we would be able to support via our WiFi. So this was what we were optimizing for. We invested in an asynchronous HTTP protocol consisting of a long lasting connection, which resulted in lowering the number of requests required. We also made sure compression was enabled.

On the other hand we had no interest in scaling out the server as regular MacBooks Pro were able to handle the load. We just made sure that the game server might be run independently from the UI server.

We also had no interest in deploying into the cloud, as it stayed in contrast to the server being able to handle 30+ teams simultaneously. Everything would than need to go through Internet rather than through local network. This would additionally cause unwanted latency which might have had a significant impact on the attendees’ experience.

Of course there are many more quality considerations you will have to deal with, so do not allow yourself to get tricked by your routine. Surely, there will be a lot of details you will need to nail down to make it happen.

2. Build execution plan

You do not want to find out that some vital piece is missing if the hackathon is just about to start. So plan properly and think as broad as you can. Do not be fooled that a hackathon is only about geeks coming to code. Everything around the code is at least as important as the coding challenge itself. Be aware that some items have to be acted on in great advance and overlooking them might be costly. Be creative when planning, think of aspects that will make the event unique and unforgettable. You will not win participants’ hearts just because the event you organize is so-so.

And if you pick a theme, make sure you have someone who can leverage it. Our theme was old games and we had a dedicated event manager from Tech Space, Agata Laskowska, who took care of the event’s coolness. Just by herself, she built a stunning tank, filled the venue with great 8-bit posters and made sure there were amazing prizes for the winners. She also had old computers like Amigas and Commodores brought to the venue so everyone could play a chosen game of his/her childhood. Here’s just a small piece of her contribution.

tank photo

3. Continuously track progress

Make sure you are always able to tell if you are on track with the plan. If you are not able to move the deadline you need to act timely to cut the scope if your project is at risk. Remember that at the end of the day you need something that will be running. While tracking progress make sure that you are constantly focusing on the right things and do not treat the initial plan as set in stone – the plan has to evolve as you go along.

On top of that make sure you use the right tool for the job instead of using overcomplicated solutions that will add unnecessary project management overhead. We’ve been using Google Sheets and Trello for “project management” and it was more than enough.

4. Approach top-down

Accept the fact that the most beautiful code is not a goal here and rush for the first runnable solution instead of prematurely extracting abstractions that you might never need. State all your assumptions about the hackathon challenge explicitly. Make sure you are able to verify them as early as possible. If you make wrong assumptions (everyone sometimes does) about the origin of the joy at the hackathon and fail to correct them early enough the hackathon might end up catastrophically. One of the best means to avoid unexpected outcome is dogfooding – you might need to perform a full realistic simulation of the event ahead of it. Ask your colleagues to participate if needed – the feedback will be invaluable.

In our case we had a lot of moving parts, so we wanted to see how they fit together at the earliest stage possible. We had to make sure that components like terrain generation, physics, gameplay, visualization are all aligned, and that it was still a fun to develop a bot attempting to outmaneuver the others. If we had been wrong in our assumptions and unsuccessful in verifying them we could have failed miserably at the hackathon.

5. Set clear boundaries

When working in a team make sure everyone is clear on her/his deliverables and that there is clear contract between components that are being developed in parallel. It is very important to define unambiguous boundaries so everyone understands and agrees upon them. It will ease your team’s collaboration by limiting the number of interdependencies and it will make integration much smoother. Last but not least remember to push yourself and others to integrate as often as possible.

We had 6 developers working alongside on the same solution. We used several languages for different parts of it and we were able to keep the solution working pretty much all the time. It basically worked out for us like a charm and we believe trying the same approach is worth your while.

6. Plan for failure

There is always a trade-off between creating a fault-free and a fault-tolerant application. You can’t achieve both if time under your disposal is limited. So you better choose the priorities with your eyes wide open. On one hand you don’t want an application full of bugs that crashes all the time and requires your 100% attention during the hackathon.

On the other hand you definitely need an application that will support recovery from fault when it happens.
If we talk in context of a hackathon, creating a fault-free application might be enormously expensive (if achievable at all). No matter how hard you try, you (your test suite) won’t find all the problems you might encounter when people start using the application. So what I suggest is having some level of confidence in the application, while accepting the fact that the fault is going to happen sooner or later. And making sure you are ready for it. And by “ready” I mean you need to have the means to recover from failure situations you can think of… and, ideally, the ones that you fail to discover in advance. Risk management techniques apply perfectly here.

In Good Old Tanks not everything was as smooth as we would like it to be from the technical standpoint. However, we were prepared for the failures and were able to act promptly. In result the problems we encountered had no noticeable impact on the hackathon and the experience of the participants.

First two failures happened quite soon after the start and were caused by null being sent by the attendees’ bot in an unexpected field. It caused server to hang in the same turn due to inability to simulate the outcome of unfortunate turn. Fortunately we had implemented persistable state machine that would let us stop and start the server at any time without losing game state. So we stopped the server, fixed the obvious bug and started it again. The whole thing took us no more than one minute and the server was back again, so it was almost unnoticeable to the participants.

When implementing the application we made a decision to keep the complete game state in memory, so there is no unnecessary overhead of getting it from hard disk or database. It wasn’t a bad idea at that point, however there were some changes to the game state model later on that caused it to get really big and we had failed to revalidate that decision. So 1 hour into the coding challenge our game server started to have memory issues. We bumped up the memory limit and restarted the application. We kept monitoring it to make sure we were not going to hit the new limit and, luckily, the new limit was high enough. We used the food break to stop the server, clean up the game state file from things that it would no longer need and start it again. What really saved us here was a human-readable and clear to understand format of the game state file. It was easy-peasy to get rid of the unwanted stuff and get the server running again.

Another problem we got into was related to the ranking. We announced to the players that they would not be given any points for games that happen during the food break. Unfortunately the script that was responsible for turning off the scoring failed to run. We have noticed it almost immediately however the ranking was already different from what it was supposed to be. We needed to fix it and it didn’t turn out difficult at all as we had fine-grained backups in place, each with a timestamp. What we did was just stopping the server, taking the ranking from an appropriate backup file, placing it in the most recent game state file and starting the server again. Voilà!

The very last thing we had to react to were attendees, who decided to play manually instead of creating an AI-equipped bot. Playing manually was not formally forbidden so there was nothing illegal about what they were doing. However, we wanted to premium the teams that were working on real bots. What we did to make it happen was just a simple runtime configuration change that lowered the turn time and made playing manually not impossible but much harder. After the change we immediately noticed that teams playing manually were dropping down the ranking so the goal was achieved. Important take away is that we were able to apply that quick fix, because we planned for it and exposed a wide API that allowed us to configure almost every single bit of application behavior without the need of restarting it. The same API we used to modify game difficulty levels during the hackathon.

7. Take care of the hackers

No matter how great challenge you prepare, your hackathon will never be successful without the hackers. So not only make sure that you invite them ahead of time, but also make sure that they have the required skills. You can achieve that in a number of ways – one of them is to be explicit and verbose about what is expected from a participant.

Another one might be to announce the event only at diligently picked forums or placing a requirement to an offline puzzle that will prove the attendee’s skills. Also ensure that attendees know what to expect from the event, so they are not disappointed just because they had their expectations set differently.

Do not ever forget the hackers are the ones whose opinions really matter. Any hackathon is as good as the attendees grade it. So despite technical things make them feel comfortable at the venue, always be interested in their progress and be there to help them out if they are stuck. And make listening to them and gathering all their feedback your priority, so you can apply the changes to the event as it goes along or use it to make your next hackathon even better.

Remember that good hackathon does not end when the event is closed. Great hackathons are long-lived memories for the attendees. So give your hackers a place were the memories might live by providing a way to express their impressions. Do not forget to publish photos/videos from the event and if possible share the solution used through the hackathon so the participants might run the private hackathon on their own.


We are still in shock after the Good Old Tanks. And increadibly positive shock. The success of the event was amazing and we are extremely proud and happy about that. We’ve put a lot of hard work into that, but the satisfaction we got from it is just enormous. We had a clear goal of delivering an outstanding experience to the hackers and that was key driver behind our near perfect cooperation. And now we know that at no point it was a matter of luck.

So do you know now what it takes to organize a great hackathon? We still keep on learning :)

We are already looking forward to the next hackathon and we know the bar is set even higher now.
But before we move forward, let’s keep the memories of Good Old Tanks alive for a moment with the video from the event.

And one more thing. It is still to be decided, who had more fun from the hackathon – we organizing it or the attendees hacking AI-controlled tanks.


Posted by

Michał Mally

Share this article