10 tips for hackathon success

If you’ve never been to a hackathon, they are typically a 24-48 hour event during which time your team needs to build a working prototype for a product, usually a web or mobile app, but some teams build actual hardware devices. I’ve been to a lot of these hackathons, and have observed some patterns for what makes for a successful hackathon experience. So without further ado, here are 10 tips for hackathon success:

1. Set realistic expectations

einstein-quoteThere’s the temptation to go into a hackathon thinking that you’re going to build a 1.0 version of a product. The reality is that with only 24 hrs, you’ll be lucky to build something that actually works and is demoable. Make sure it’s something you can build in 24 hrs. Otherwise, you’ll spend the majority of the time postulating on all the different things you could build and trying to prioritize the features, and you’ll be left with a bunch of diagrams on the back of a napkin, but no actual thing that you can demo.

You need to think big, but start small. What is the simplest thing you can build that provides value? Err on the side of subtracting functionality rather than adding functionality. In lean startup terminology, this is called a minimum viable product (MVP).

2. Attract talent to your team

If you are a business guy and can’t write code, you’re going to need to convince a developer to join your team. Likewise, if you’re a developer but can’t design, you’re team is going to be much stronger if you can attract designer talent. Without the right people on your team, you’re going to be handicapped and have a hard time getting to a working prototype.

How do you attract talent to your team? Most hackathons provide an opportunity to pitch your idea before the hackathon starts. Write down a concise description of what you want to build, who it’s for, and why they would want to use it (what’s the problem that you’re trying to solve). And then practice your pitch so that it comes off naturally when you stand up to present it. State very clearly who you are looking for, and if you have a particular technology in mind, mention that too. If you’re planning to develop in Django, you just might attract other developers who want to code in Django too.

3. Get to know the vendors/sponsors

For our project Amazon, you can use open source projects to your product. Singly allowed us to authenticated users using their Facebook or Twitter accounts, and post status updates on behalf of those users to their Facebook and Twitter accounts.

4. Do your homework

One thing that we didn’t do was to study the APIs before the hackathon. I highly recommend going through the examples and understanding how the various libraries you’re going to use are put together. That way you don’t spend precious time reading docs, and trying to figure out how to use a library or 3rd party API, but can focus 100% on building the functionality that is unique to your app. We spun our wheels trying out django-bitly, only to discover that it was broken, and so we reverted to using the Python library recommended by bit.ly.

Using existing code can drastically speed up your development time, but beware of code that is buggy or not well-documented. You could spend as much time debugging someone else’s code or scratching your head because of non-existent docs, than if you were to just build the functionality from scratch.

Where do you find trusted packages? Again, do your homework beforehand and select packages that are actively being developed (so you know they’ll work with current versions of your web or mobile framework), have good documentation and preferably you’ve already installed them and run the tests, so you know they work. For example, if you’re working in Python, look for an existing package at PyPi and DjangoPackages lets you compare similar Django packages. Crate.io is an alternative to PyPi that provides some additional information about the packages so you don’t have to go digging for it.

5. Use Github for version control

This seems like a no-brainer but I’m constantly amazed at how many developers are not familiar with DVCS such as Git. You can save yourself a lot of pain and frustration by setting up a repository on Github at the very start, and remembering to commit early and often. It’s much easier to roll back an atomic change, than trying to roll back a bug that was also committed with a bunch of new features.

Even better, use feature branches or have each person on the team work on their own branch. Rather than merging into master and potentially breaking the application for everyone else on the team, merge the master branch into your branch, and only after you’ve ensured that everything is working properly, merge it back into master.

We got a little bit lazy and on made the mistake of merging to master before testing things fully. Inevitably, this broke things badly an hour before we were supposed to submit our hack and we ended up having to make a new ‘predemo’ branch and cherry-pick commits into that branch to get the needed functionality for our demo. This was painful and could have been avoided had we been more careful with our git merging process.

6. Use a PaaS for deployment and hosting

This also seems like a no-brainer, but old habits die hard. Once you get used to doing something a certain way, even if evidence suggests there is an easier and faster way of doing it, we hold onto that which is familiar. Unless you’re using some obscure language that is not supported by the PaaS providers, you’ll be able to deploy faster and spend more time writing code and less time with tedious sysadmin tasks if you use a PaaS. Some that I like are Heroku, Dotcloud, OpenShift and Stackato, and if you’re a Django developer, read my post comparing various PaaS providers for Django deployment.

As with the vendor APIs, spend some time before the Hackathon to try out these PaaS providers to get familiar with the deployment process, and make sure that the PaaS supports all the features you need for the app you’re planning to build.

7. Take frequent breaks

When you’re under time pressure, and when the whole team is counting on you to build feature XYZ, it’s tempting to sit in one spot and plow through until you’re fingers are numb from all the typing. But this is a sure-fire way to burn out and even worse, hurt yourself with RSI. I always bring my Kinesis Ergonomic keyboard with me to hackathons, and my wrists thank me for it.

Remember to get up from the desk, stretch your shoulders and wrists, and go get a drink of water. Sometimes walking away from the code and coming back to it after taking a break makes all the difference in breaking through a tough problem.

8. Envision your perfect demo and work backwards

The best way to prepare for demo day is to think about what you wanted to show in your demo, and then work backwards. In other words, build the functionality and UI screens that you need to show the audience what is unique about your app. A 24 hour hackathon is not the time to build a full-featured product, so focus on the parts that you want to show in the demo, and only work on those. If you decide to continue working on it, you can always come back and fill in the missing pieces.

It’s important to spend time making a decent video, and not wait until the last minute to do it. As with the APIs and PaaS, learn how to use a Screen recording software package before the Hackathon, so that you’re not wasting time trying to figure out how to get the audio drivers working to record the sound.

9. Use an HTML/CSS framework

ourmy_mockup_300pxYou can come to the Hackathon with pre-made wireframes or mockups, so you should definitely do this in advance, so you’re not spending valuable time doing this at the Hackathon. But what about the HTML/CSS? I’d highly recommend using Twitter Bootstrap or Zerb to build a nice-looking prototype without having to write hardly any CSS yourself.

If you’re worried that your Twitter Bootstrap site is going to look like every other bootstrap site, head over to Bootswatch to get a free bootstrap theme, or Wrapbootstrap and buy a theme for a few bucks. The advantage of using something like Twitter Bootstrap is that you can assign someone in your team who is less technical but who has good design sense, to create the templates using Jetstrap, a completely web-based drag-n-drop tool for building Twitter Bootstrap templates.

10. Have fun!

Remember that you’re at the Hackathon to have fun. Yes, it’s a competition but it’s also a place to experiment, meet interesting people, learn something new and build something from scratch. Don’t stress yourself out too much if you don’t accomplish what you set out to do, or if you don’t win. Just have a good time and put your best effort forward.

Continuous hackathons

Despite enjoying my time at hackathons, it always irks me that at the end of the hackathon, people say their goodbyes, go home, and then the project quietly dies. That app that you were singularly focused on for 24 hrs and sweated bullets to complete on time, is now not much more than an unmaintained landing page. The app’s Github repo is a ghost town and Heroku has decommissioned your app because it doesn’t get enough page visits.

But it doesn’t have to be this way! Imagine a hackathon that was not a single event, but a continuous bi-weekly or monthly gathering in which participants meet to work on their hacks?  I think that meeting consistently would help build momentum for a project, and make it more likely to reach some level of maturity.

Happy hacking!

HackUB 2017 © All Rights Reserved