Uncategorized
The month of November was a busy month for hackathons in Boston with the Startup Weekend, Music Hack Day and AngelHack. This past weekend I participated in the Boston Angelhack, and wanted to share a few thoughts about the experience.
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
There’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 Ourmy, we decided to use the unified APIs provided by Singly, rather than building all that code from scratch. 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. The Singly guys (Kristjan and Justin) were really helpful and we wouldn’t have been able to develop Ourmy as fast as we did without them by our side. We also took advantage of the Singly chat room to get questions answered by Singly engineers who weren’t even at the hackathon.
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.
The AngelHack rules state that you can’t write any code beforehand, but you can leverage existing open source libraries. 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
When I participated in Techstars Cloud, one of the hackstars, Alex Baldwin told me that the best way to prepare for demo day was 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.
The official Angelhack how to make a hack video page recommends using Screencast-o-matic.com. I haven’t used this software before, so I can’t vouch for it, but if you have a Mac, I can’t recommend Screenflow enough. At $99, it’s not cheap but it’s the best. If you do Hackathons regularly, or you need to make a video of a new app that you’ve built and post to Hacker News, this software is worth it.
If you don’t want to spend $99 for Screenflow, you can use the built-in Quicktime player to make a screen recording. And if you to record the audio from your computer, visit this post.
There are other screen casting tools out there such as Camtasia (Mac/Win), Snapz Pro ($69 Mac only), iShowU ($20 Mac only) and Screenflick ($29 Mac only).
9. Use an HTML/CSS framework
The AngelHack rules state that you 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.
The other advantage of using Twitter Bootstrap is that there are Omnigraffle Stencils available that you can use when you’re wireframing, which can translate directly into HTML/CSS without losing time in translation. In other words, there’s a one-to-one match between what is shown in the wireframe and the corresponding HTML/CSS element, so the wireframes will exactly match the HTML/CSS.
Like Screenflow, Omnigraffle is not cheap ($99) but it’s the best wireframing tool for Mac, so if you do a lot of wireframing/diagramming, it’s totally worth it. If you’re not ready to pay $99, you can get a two-week trial.
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.
Other resources
Kinvey’s downloadable PDF How to have a great hackathon was an inspiration for this post, and my Techstars Cloud buddies (or cloudies as we like to refer to each other) at Keen.io recently wrote a post Hackathons are a Terrible Way to Get New Users and Why.
Lastly, Rob Spectre, my friend at Twilio wrote a post about how to tell a story with code, that is very relevant as you’re giving a presentation about your app, especially if it’s very developer-focused.
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.
Martin Fowler wrote about such a hackathon called CharityCodeJames that started out at a single event hackathon in New York to write software for charitable causes and now meets every week. Along those lines, my friend Dan Choi has a similar idea for “barnraising” to help local Boston non-profits build websites and web applications. The idea needs more fleshing out, but feel free to leave comments below if you’re interested in this idea tool.
Happy hacking!
(A little known fact: Appsembler was born as NodeRabbit at a Startup Weekend in 2010, so you never know where an idea conceived in a weekend might take you.)
