Hackathon 2022 Project Debrief: What did we learn?

In some ways, a hackathon is just like every other project — we’ve got a deadline, deliverables and a demanding client. The key difference is that it’s an environment of extremes. The timeline is super tight, compressed right down to a single, intense week. The deliverables are deliberately vague, to enable as much creativity and autonomy from devs as possible. And the people we need to impress are ourselves, who can be our harshest critics. In this extreme environment, you succeed harder but you also fail harder, making it obvious what’s working within the team and what’s not.

So, what did we learn? Here are my top takeaways:

There’s a list of must-haves before you even start

Whilst we try and keep the design, branding and tech decisions open to discussion, it’s beneficial to have a couple of things ready before the hackathon starts. You should already have an idea, and a set of wireframes so basic functionality is plotted out. This will give devs enough work to do straight away on day 1, whilst the finer details of UX and design get hashed out.

Another thing you can do is have your CI pipelines ready to go, with your app deployed to test channels before any "real work" has even begun. This is not something we did, but it would have saved so much time and hassle, and prevented the bottleneck of a single dev responsible for all deployments.

Have a leader, and remind everyone you’re on a hackathon

This time we had a few new starters who’d never been on a hackathon before. Whilst the week was still hugely enjoyable, the intensity of the hackathon was a little surprising for some.

Whilst the devs are deep in the console, it’s important to have a leader to act as product owner, with the outside perspective to keep everybody on track. It’s also their job to remind everybody that it’s ok to hack something together, even if that meant the code wasn’t up to our usual high standards. The goal of the week is to get something done - it doesn’t mean we won’t ever come back to refactor janky code.

The leader can also act as a floating resource, helping others where necessary and keeping everybody productive and sane.

Refocus every morning, during stand-up

We hold daily stand-ups (and stand-downs) to make sure everybody has tasks assigned and the opportunity to talk about any problems they might have. It’s the leader’s responsibility to remind everybody of today’s goals.

This time around, we stuck post-its on a 150-year old mirror, but you can find what works for you. However, here are some golden rules to live by:

• Don’t add tasks if they are too big (they should be a day’s worth of work, at most)
• Don’t add tasks if they don’t get immediately picked up that day
• Look for red flags. If there is a task in "to do" all week, it’s probably not a priority. If there’s a task "in progress" for more than a day, then break it down to get something over the line

If something’s not working, find an alternative

During a hackathon, you need to be really harsh in your cost-benefit analysis.

This time around, we wanted to try out Prisma for our backend. There was a fairly steep learning curve but the time we spent figuring out Prisma was saved by not writing CRUD (create, read, update, & delete endpoints for every model), due to the GraphQL resolvers you get out of the box. This cost-benefit ratio was totally worth it (and we’re definitely using Prisma again).

An example of what didn’t work was our persistence in creating a robust deployment flow for the native apps, during the hackathon itself. It cost us several days to get up and running, but the benefit just never materialised, because the alternative here was just to deploy manually (even though that puts strain on a single developer). As mentioned in my first tip, this would have been so much better to solve ahead of the hackathon.

The takeaway here is to find alternatives where you can if things don’t go to plan. Be aware of the pace the team is working at and if something stalls, react quickly. It’s no use banging your head against a wall if there’s something speedier and just as effective.

So, to sum up:

• Have your idea, wireframes, feature list and DevOps planned and ready to go before you start
• Decide on a leader ahead of time. They are your product owner and floating resource
• It’s ok to hack things together, a hackathon isn’t the time to be a perfectionist
• Refocus every morning with stand-ups and stand-downs
• Be realistic about the time cost of implementing each feature - and find alternatives if it’s not worth doing
• React fast when things slow down

 

Still want more? Check out our daily hackathon Project Journal.