Note: This article is part of the How to win a Hackathon series.

Don’t wait to deploy until the end

I’ve seen so many teams get burned by waiting until the last minute to get the server and deploy set up. I know working on the app is why you are in the hackathon and I know that’s the most exciting, but don’t take the risk that all your hard work will count for nothing because you failed to get it deployed. Getting the server set up and working should be the very first thing you do. Make sure you have deployed, through git, to the server and see a basic Rails home page deployed and running.

Use Google Analytics and Woopra

More than anything this is for curiosity, but you’ll be thankful you did it when the judging starts. Google Analytics is great for historic reports, but nothing beats Woopra for live tracking of your users. We watched every judge come in and look around our app. We could see which ones really spent the time reviewing or apps and which ones barely looked around.

Have a link from the site back to voting

We failed to do this the first time and I think it hurt us. Many visitors may find your site directly via a share from a friend, and they may not be aware that you need votes. Having a prominent link on the home page asking for their vote with a link to the hackathon page helps communicate your situation and will get you more votes. You could consider implementing the Hello bar to accomplish this quickly.

Create a blog off-site

When the hackathon ends you can’t make any further changes to your app. This includes communicating valuable information to your potential users. I’ve seen apps that had a major bug that was preventing everyone from trying it. Though there was a way around the bug, there was no way to communicate to the users how to do it.

If you set up an offsite blog (Tumblr for example) and link to that from your site, you can publish updates and news there during the judging time without having to make modifications to your app.

The same suggestion applies to having a Facebook page and Twitter account. If you link to those from your site, you can then use all of these options to continue communicating with the users and the judges after you hit that code freeze.

Follow up with immediate bug fixes

You won’t be able to fix any problems found after the code freeze until the judging and voting is over, but that doesn’t mean you can’t have the fixes ready to go.

We fixed everything as it came up, and the minute we were cleared to update we did.

This way if your app gets any press post-hackathon, the visitors will see a more improved and bug-free version.

Note: This article is part of the How to win a Hackathon series.

The experience of hacking for 48 hours can be quite a thrill, but don’t let that excitement get the better of you. It’s still important to take care of your health while hacking away, and failing to do so could leave you at less than your best.

Several studies have shown that going without sleep, even 24 hours without it, can leave you impaired in the same manor as being legally drunk. To make it worse, the first part of your brain to degrade is in the part of your brain that is most crucial to thinking. You can read more about that online, for example here.

Be sure to get some sleep during the hackathon. I recommend 6 hours each night. Doing so will help you be far more efficient during the other 36 hours you are hacking. Better to lose 12 hours to sleep, than operating at half capacity for the last 36 hours.

If you need energy during the hackathon, don’t eat sugar. Sugar will sap you of all your energy once its quickly burned in your bloodstream. Since you’ll be sitting most of the time, you won’t need many carbs at all. Be sure to eat a high protein diet and drink enough water. If you need a special lift, I recommend the sugar free Monster drinks. I drink the Lo-carb and the Tea+Lemonade several times a week. Both give me a noticeable lift in energy but never result in the lethargic “crash” typically associated with spikes in energy because they contain little to no sugar.

If you need to take a break, do so. A focused mind at 100% is better than one at 70%. During our last Rumble I reached a point where my brain was in a state that simply could not continue processing anything. Thankfully I was able to take a break with my teammate to the nearby mall (where we had strategically positioned ourselves in a hotel room we rented for the Rumble) and simply walk around the mall to get out, and get clear. By the time I returned I was refocused and ready to go.

If you want your brain to function on all cylinders like a finely tuned race car, proper care and fuel is required!

Note: This article is part of the How to win a Hackathon series.

When it comes to planning out a hackathon, I plan it almost exactly as I do any app (when I work in a situation where I’m allowed to that is).

What does it need to do?

I start by summarizing into a sentence or two, what the goal of the app is. This is your ‘elevator pitch’ and will help you stay focused as you transition from big picture to planning out the details.

Next, make a list of what the app needs to do, sometimes in terms of use cases, stories, or simply a list of features. However you like to word it, the concept is the same: describe what the user will both need to do and want to do upon visiting your application’s home page.

Here are some sample use cases, the first three should probably be on everyone’s list:

• The visitor should immediately understand the goal of the site.
• The visitor should immediately get the impression that [example: the app’s goal is to help children reach their goals, or whatever your app’s goal is].
• The visitor should have one clear and immediate call to action they can take without thought.
• The visitor should be able to register.
• The visitor should be able to login.

Know your priorities

Once I have a list of what it will do, I put those in order from most important to least. In both a hackathon and in real life development, odds are you are going to run out of time with reaching the deadline. This priority list will probably change for a real life app, but for a hackathon and the shortened time frame, its a great recipe to stick to so you don’t have to stop and re-strategize mid-sprint to the finish. An important part of succeeding in a hackathon is the willingness to cut a feature. So many submitted apps have half-done features, or ones that were not well thought through and look hurried. Better to cut it all together and ship less, than to ship poor quality work. When it doubt, cut it, and knowing your priorities before hand can help you do this during a time crunch.

Detail the pages

To further understand the requirements of the app, I now list out every page that will be on the application, title it, describe it, and list out all the elements that will be on the page. This is great for not only ensuring you didn’t miss any tasks, but also for communicating design needs to your designer and front-end developer. I include what type of content needs to go on each page, though remember not to write any of the actual content until the hackathon begins. Also, note how the user gets to each page, and where they can go from each page. You can do this on the page notes, or even create a visual flowchart, that illustrates this.

Define tasks, roles, and milestones

Now that you know what has to be done, it’s time to break each feature or use case down into a list of what tasks are needed to create that feature, including creating the model, controller, database changes, views, design elements, etc. Then, I assign each one of these tasks to someone on the team, and note target milestones (deadlines) for each to be completed. This then helps you see if you have any chance of accomplishing your plan before the hackathon starts.

I like to group the tasks into “mini-sprints”. I find it much easier to focus on smaller groups of tasks, and its rewarding for the team when you reach each one and can hoot, holler, and high five in celebration to keep yourself on an emotional high throughout the long couple of days.

For both of our Rumbles, our first mini-sprint was the most important. We started at 9pm and the first sprint was to be completed by midnight. It was so important that I made up a music playlist just for that first sprint. Our goal for this time was to have the following completed by midnight:

• Linode server setup
• Git repo setup
• Deploy script created and tested
• Rails framework created, checked in and deployed
• Gems installed and deployed
• All models, controllers and views stubbed, checked in and deployed.

With this completed after the first 3 hours, we knew there would be no infrastructure surprises to haunt us in the end and we could focus on making the app awesome right up until the last minute.

For PeepNote, we had 11 development milestones and 6 designer milestones. We completed all 17. There was an optional list in case we had extra time, but we didn’t get to much on that list.

Plan to Fail

Another important part of the plan is to plan your failure points. Make a list of all the failure points and risks, both with building your app (the biggest challenges) and within the app (exception handling).

Some of your tasks may be technological “risks” and if you aren’t prepared they could derail the entire plan. For example, pulling a list of friends from Twitter, if you haven’t done it before, and working with the Twitter API would be a risk.

Poorly handled exceptions within the app could jeopardize your impression with the judges and voters, so itemizing these and planning ahead on how to handle them will save you time and ensure you are prepared.

Quality and Completeness

It’s more important to have a good quality app and one that is complete in what it promises than a bunch of almost finished features.

Cut features mercilessly as you near the final stretch, opting for quality over depth. If you promise it on the home page, it should be there and work completely. Otherwise, don’t mention it.

Conclusion

With a detailed plan in hand, and understood across the team (again, this is part of the communication I discussed earlier), your team will be prepared to hit the ground running and won’t need to spend valuable building time with planning and strategizing, which can be particularly challenging when you are tired and emotionally drained.

Note: This article is part of the How to win a Hackathon series.

When competing in a hackathon there are some sacrifices you make compared to when you are creating a product under normal conditions. One major difference is that the product must appeal to the judges and the target audience (if there is public voting). It’s important in a judge-driven situation to understand what the judges will be looking for specifically. Are there categories that you will be evaluated on? What are they looking for in each category?

If the rules of the hackathon don’t explicitly define what you will be judged on, contact the organizers and ask for further explanation. You may also want to ask if they would share that same detailed direction with the judges so you are all on the same page. If the competition is judging you on “completeness” for example, what does completeness mean to them? Does it mean everything that you says works indeed does, or, does it mean the judge can’t think of anything else you could have made the app do? It’s very important in a hackathon to be so explicit with the judging rules that there is no room for personal interpretation. If you as a participant aren’t confident that the rules have made it clear, contact the organizers and work with them to ensure everything is laid out as clearly as possible.

While it’s important to create a great service according to your team’s vision, you may want to focus on elements and deliverables that particularly address the items the judges will be looking for since you’ve chosen to compete in the hackathon. I suggest, that as part of your written plan, you describe what you will do to address each category you’ll be judged against and spend time as a team addressing those challenges.

Note: This article is part of the How to win a Hackathon series.

As important as choosing your teammates is, communicating with them is just as crucial. Some of you may all be in the same location, but for both my hackathons we were spread out. The designer was in Portland both years, and the second year the additional designer was in Michigan. We never had more than two members in the same room.

With Josh, the lead designer both years, I never even spoke to him on the phone until a year after the first Rumble (in preparation for the second). All our communication was done online, without audio or video.

We mostly used Campfire for all our discussions the first time around, including both pre-hackathon planning and during hackathon communication. Campfire allowed us to share images with each other inline very nicely, go back and see notes from past conversations, and collaborate in both real-time and delayed time.

The second time around we used Skype chat (I can’t remember why over campfire) and had some phone calls, but regardless of the technology used, we stayed in constant contact throughout the Rumble, and even prior to it as we formed the plan.

You can also use tools such as dropbox to share files and I highly recommend getting all teammates using github, not just the developers. It will save you a lot of time.

The key to effective communication and collaboration is very simply: committing to the necessity of it. All members must understand how crucial it is; then, stay calm and patient in communication, and stay committed to the goal of effective collaboration.