Innovating on Developers Events, Building the API Escape Room
It’s been almost a month after the first world edition of API Escape room at the Red Hat Summit in Boston. We thought you might be interested to hear details on how we prepared this event.
With the 3scale team, we often participated in classical hackathons where developers gather for 48 hours to come up with a working prototype. These were awesomely fun (!), but the outcomes of those events are quite uncertain for organizers, sponsors, and participants. You cannot guarantee that hackers will build stunning original hacks and it can be a tough ask to keep working for such a long period. You can’t be sure that it won’t just be another “recipe app” or “Uber for X”.
As a sponsor, although you have people in the room promoting your API, you have the best swag ever and came up with a nice expensive prize to give out, you are not guaranteed that a lot of hackers will use your API. And if you are a conference organizer, it’s hard to make people come 2 days in advance of your conference, “just” to hack. Worse, at conference events, hackathons are often in conflict with program content, so people are conflicted about missing such large parts of the program.
We thought there might be a better way to run hack events at conferences, where everybody wins. That’s why we came up with the SpeedHack idea. We launched it at APIstrat Chicago in 2014 and had these events in Berlin and Paris. The idea was to provide a nice hacking experience where developers could discover new APIs through guided challenges in a limited amount of time. It was easier to bring people for a 3-hour time slot. The API providers had a chance to talk and engage personally with each team. For API providers it was also a chance to test new features of their API or in their documentation and receive feedback.
For the 2017 Red Hat Summit, we were offered the possibility to organize a developer focused event one of the nights of the conference. Our first thought was to organize a SpeedHack event, where developers will come to test their API skills. But… never being one to take it slow, just a day after we’ve submitted the abstract and the title of our session we had a better idea. Wouldn’t it be cool to build our own Escape Room, and use APIs to solve puzzles?
We had a few Escape Room aficionados on the team, so it was easy to get everybody interested. The hardest part was about to start… we had less than a month to improve our game designing skills and come up with a fun puzzle.
We selected 3 APIs that people will have to use: Flighstats, Kairos and a custom API we would build ourselves.
Now that we had the APIs, we had to come up with ideas on how to link them and how people will find clues to use them correctly. Until a week before the event, we did not have the puzzle complete. We needed time to come up with all the craziest ideas possible and later reduce the number of options. Some of our ideas would require serious carpenter skills; sadly, we did not have to build them. We’ve put in a good production effort to turn the soulless convention center room into an airport terminal, adding posters, arrival screens…
Here are some examples:
We gave, for example, to each participant in the API escape room a boarding pass when they entered the room.
The hacker had to start with very little info and start exploring both their digital and physical surroundings to find clues. Ultimately they had to break the combination on a locked luggage case to win the prize. To make sure that all we had imagined worked well in-situ we asked two team members Vanessa and Manfred to run a test few hours before the event. Thanks to them, we were able to solve the last of the glitches in the scenario. For this first edition, we had about 25 people in the room playing all at the same time in the same room. We received a lot of great feedback and ideas for our future events. You can check the twitter stream here:
This format is definitively good to use in conferences as it’s happening for a limited time. The entire puzzle should not take more than an hour and a half to solve. It’s a very inclusive activity as teams have to work together to find solutions, and it does not require expert coding skills to solve the API challenges.
We have plenty of ideas for the next edition, let us know where you want to see it happen, and we will bring it to you. 🙂
To build your Java EE Microservice visit WildFly Swarm and download the cheat sheet.