In April, Mansystems sent HackSystems--a team of 4 hackers--to MxHacks, the biggest low-code hackathon of 2019. Expert Mendix developer and HackSystems teammate, Joost Stapersma shares his MxHacks experience and offers some advice on how to survive a hackathon.

You might wonder: why on earth would anyone, let alone 100 people, spend 24 hours non-stop coding and developing? While I cannot answer this question for everyone who attended the Mendix World hackathon, MxHacks, for me there were 2 reasons. First: I like a challenge. I have participated in a couple of other hackathons before, but this was the first time I had the chance to compete against (and learn from) fellow Mendix developers on a level playing field. Second, on a regular working day, my workload is usually determined by others like managers or product owners. At a hackathon, there are no restrictions on what you can make - other than your own skills and the time limit.

So, when I received an invitation to MxHacks, me and three of my colleagues from Mansystems— Nikie Sweers, UX designer, and Advanced Mendix Developers Agnes Roolvink and Jeroen Appel--came together to form our team, HackSystems. A few months later, we walked into MxHacks ready to “Go make it.”

And make it we did. Out of the 30 teams there, we came in second place. Want to know how we built an app in a day? Follow our 7 simple guidelines to hackathon success.

1. Don’t dive into coding right away

We tackled the hackathon like a regular agile project by creating user stories and forming an MVP like a product owner would do and then developing it ourselves. The main difference is that the sprint was limited to 24 hours instead of 1-2 weeks, which meant we needed a solid game plan and we needed to stick to it.
In the early phases of a hackathon, it is wise to think about the concept you are going introduce or problems to solve before starting actual development. A proper backstory or purpose is equally (if not more) important than making a killer, technologically advanced app.

So, get your post-its and markers ready and start brainstorming with your crew! Pick any brainstorm technique that works for you as long as you feel comfortable with it. Here’s our

MxHacks approach

Round 1 – Agree on theme or use case

One of the unique things at MxHacks was that you were allowed to bring your own idea without any restrictions, while the MxHacks organizers also provided a potential use case. A little more than 15 minutes before the actual start, the emcee, Jeff Goldberg, showed us a few scenarios regarding challenges that those in refugee camps—both the displaced people and the aid workers assisting them—face in those camps. Almost immediately we decided to stick to that domain.

We started out by agreeing on a theme or use case that we wanted to tackle, in our case “World Peace” (You have to start somewhere, right?). Our main goal was to come up with an app that could make the lives of the people living in the camps easier, even if just a little. We all had a look on the internet and found some useful information about challenges which were related to the registration process at camps. We took this and some personal experiences with us to the next round.

When deciding on themes or use cases in round 1, be sure to do a real-world reality check. For example:
• Which problem(s) will the app solve?
• Which people or companies would be willing to use (and pay for developing) the application?
• Are there any existing apps that already solve your problem or tackle your usecase?
If there are existing apps, don’t be discouraged immediately--although you will need to have a very good motivation as to why your app is unique and/or obviate existing apps.

ROUND 2 - BRAINSTORM

Next, everyone on our team got a stack of post-its and we took five minutes to write down any ideas or functionality within the main theme, after which we grouped them in categories.

Want to keep it fun? Try to think of funny app features during the brainstorm phase- as long as they are at least somewhat relevant to your use case.

Round 3 – Adjust scope

Every post-it was plotted in a chart based on feasibility and value. We did this to prevent spending a lot of time on functions that were impossible to do in a short timeframe or building fantastic functions that nobody needs.

Round 4 - voting

Finally, everyone on the team got two ‘votes’ to assign to any of the ideas. Only the top two or three ideas after the voting round make it to the final product, so we had to choose wisely.

The whole design thinking process should take no longer than two to three hours max.

The primary vision for our app was that refugees would be able to find work and activities in refugee camps based on skills and/or interests they already have. Not only would this make them less dependable on aid organizations while in a camp, it would also prepare them for easier integration in society in their preferred destination country. In the application, users should be guided by visuals or speech to prevent language barriers and make the app easy to use for anyone.

In the end, we made a shortlist of main features that needed to be in the app:
• Users should be able to log in to the app using facial recognition
• Users should be able to talk to the app in order to enter forms or navigate through the app
• Users can register themselves and view available jobs/activities in the refugee camp so they can contribute to the community

2. But don’t wait too long before going at it either

A solid idea is about half the work of getting a good result, but the other half is going to take up most of your time. Besides, it’s way more satisfying (and rewarding) to demonstrate an actual working application to the judges instead of having to show screenshots of mock-ups because you just didn’t have enough time to get it to work. Your first 12 hours are going to be the most productive ones, so make them count.

3. Take advantage of available resources

Most hackathons will provide you with several resources like APIs, widgets, code snippets and gadgets ready to use but also breakout sessions, coaches or field experts to brush up on knowledge.

More importantly, there will be experts available who can directly answer technical questions or assist with troubleshooting issues. This can be a huge advantage compared to having to search forums or online documentation for a solution to your problem.
During MxHacks, our team also used additional tools and services such as Visual Studio Code, Eclipse, Adobe XD, Adobe Illustrator and Gulp (for sass-compile operations). Furthermore, we used the Google Chrome built-in Speech-to-Text API and the Microsoft Azure Face API to give our app the ‘intelligence’ we wanted to integrate into our app.
Using provided resources can also get you bonus points if you implement them creatively. We competed in one of the MxHacks sponsor challenges using the provided speech-to-text widget and ended up winning the challenge, so each of us got to take home a neat Google Home gadget.

4. Use your strengths

Every team member will have their own strengths. Use them to your advantage! During a hackathon it is best to stick to things you know or are comfortable with, as there is not much time to learn and master entirely new skills. If you know your team members well it will be easy to divide the workload based on expertise, but if not, be sure to reserve some time to discuss who is good at and/or likes performing certain tasks.

At MxHacks, we had a mix of three developers as well as a UX expert. While Nikie, the UX expert, made the mockups and designs which were implemented by Agnes, Jeroen worked on the facial recognition API, and I implemented the speech recognition API. This worked perfectly as each of us has had previous experience with these techniques and we also avoided getting into each other’s way.

5. Timeboxing is key

Essential hackathon resources like coffee, energy drinks or pizza were always available at MxHacks. There is however one resource that steadily runs out every hackathon and is never resupplied: time. Prevent wasting time by setting a time limit for every feature or screen that you are building and stick to it.

But remember: Go Have FUN! I made it to the semi-finals of a Mario kart tournament. I didn’t win, but it was a fun experience and the adrenaline helped counter my after-dinner dip.

A hackathon is not about completing a production-ready and monkey-proof product; you are presenting a proof of concept and you are allowed to make shortcuts. If you are nearing to a working solution and running into a final bottleneck issue that will cost you a lot of time, it is usually faster to think of a quick workaround instead of troubleshooting and fixing the actual issue.

If you are nearing of exceeding your time limit and not even half way there, start looking for alternatives:
• Extend mock-ups and add them in your slides presentation instead of demonstrating them live
• Simplify features and explain which additional features are needed to get to the end result
• Skip the feature all together and choose another one from your brainstorm session

In the late night/early morning, I was working on using voice commands to perform actions like showing a page. Initially I wanted to use the phrases “please show me how I can contribute to the community” in order to show a page where refugees would be able to view jobs/activities where either help or materials were needed.

As it turned out the longer the spoken phrase was, the harder it was to analyze the text and convert it into an actual microflow action. I finally managed to demonstrate the functionality using the phrase “I want to contribute” ... but I had also built in an escape. Just saying the word “Next” served as a backup trigger and would also open the page.

6. Pay attention to the package

It’s better to complete just one feature that works flawlessly and looks awesome, compared to 10 ok-ish features that look like rubbish. Again, you can always use mockups to explain or show your roadmap.

During the last few hours of the hackathon, you are most likely very tired and a lot less productive, building and testing a new feature at that time is very risky. We spent the last few hours mostly on eye-candy, fine-tuning and bug fixing.

This also applies to the sales pitch. Whoever is going to do the pitch to the judges should take enough time for preparations. The story you are telling is largely supported by your demo application, but having a good story is half the work. Usually hackathons provide breakout sessions on how to do a sales pitch, so if you are not feeling comfortable on stage be sure to attend them.

These pitches usually last 2-5 minutes including the demonstration. Speaker should rehearse their pitch multiple times and use a stopwatch to measure duration. Timing is perfect when you manage to shout the final one-liner on or right before the timer ends.

When I heard the word “hackathon” for the first time I associated it with words like “interminable,” ”fatiguing,” and “tough,” like a marathon. Although this is partly true -- especially during that last few hours -- hackathons are ultimately rewarding and fun to do. Don’t forget to take a break every once in a while and take your mind away from coding, even if it’s a low-code platform.

7. HAVE FUN

Remember that if you do get tired, you can always Go have FUN! Fun fact: MxHacks coincided with the birthday of one our co-workers. Exactly at midnight we sang “Happy Birthday” and toasted with champagne.

Closing notes

After a long 24(+) hours without any sleep we finally got to show our product to the judges on Tuesday morning. Despite some connection-related hiccups, we managed to present our vision and MVP product to the judges. See below for a small impression of the result.

Based on the judges scoring, we were among the top five teams.

As we awaited the final tally, we tried to get some sleep in a nearby hotel but by the time we got there, all of our phones started ringing. We had won one of the sponsor challenges!
At the Day 1 closing keynote for Mendix World 2019, we anxiously awaited the winner announcements. The top 3 teams would be invited on the main stage. Sleepy as we were, we still had the strength to jump up once the speaker announced: "And the 2nd place goes to....... Hacksystems!!!"

It was a fantastic conclusion to a great MxHacks and all our efforts that were made in only 24 hours. I would especially like to thank my team members who made it happen (starting from the left in the picture above):
• Jeroen for not giving up (he managed to continue working and demonstrate the app despite having suffered from an unexpected nosebleed. Respect!)
• Nikie for designing a minimalistic user interface that anyone can use
• Agnes for making the app look like a work of art.

Finally: If you ever get the chance to participate in a hackathon yourself, I would strongly advise you to do so. It is a fantastic event that allows you to test and hone your skills, but also gives you the opportunity to work with awesome technology, people and ideas that usually don't come up in your everyday work.