Rails Hackathon – Lessons from the Rails Rumble

Let’s Get Ready to Rumble

The Rails Rumble is a 48 hour long programming contest, a rails hackathon, for teams of one to four people to see who can make the best Rails-based web app in the allotted time. You’re not allowed to have any digital assets beforehand (so no coding, and no designing layout, icons, etc). You can plan, brainstorm, graph, chart, mindmap, diagram, etc. as long as it’s all on hardcopy.

This is my 3rd Rumble, and probably my 10th hackathon in general. These events rarely produce fully functional websites, much less applications with long-term monetization potential. So why would anyone waste an entire weekend programming on something that may never be useful?

Because it’s fun! It’s a challenge to see what you can do if you just sit down and code for two days straight. Do you ever have ideas and say, “If only I had time to work on them?” Well, hackathons are great for that.

A few different apps I’ve done for hackathons include PlanitShareit (a collaborative vacation planning site, which then converts into a social media trip-photo sharing site when your vacation starts), ConSearch (like Pandora for upcoming live shows – tell it what bands you like and it tells you which upcoming concerts you might enjoy), DomeWait (part of the SuperBowl hackathon, which would let people submit how long lines are at various bathrooms in the SuperDome so others could plan bathroom trips during the game more efficiently), and KaleFinder (a tongue-in-cheek “authenticity finder” for a tourism hackathon inspired by this article about “authentic New Orleans” lamenting the lack of Kale in the city by recent transplants). I’ve won some hackathons, and bombed in some others, and none of the apps ever became anything. But each one has been an entertaining experience and a challenge to my own personal skills, and that has made each of them worth it.

Here are some tips I’ve learned to help with hackathons like the Rails Rumble, as well as some lessons you can learn from hackathons:

Plan ahead (duh)

You need a good plan going into a hackathon. You should at least have your database models and interactions diagrammed out, maybe even doing some light UML diagramming. You want to have as much time as possible for doing actual development, instead of getting bogged down on whether something should be a one-to-many relationship or abstracted out into a polymorphic association.

Likewise, if you’re going to use any new gems or APIs that you’re not familiar with, fire up an IRB console and play around the week before the contest. Maybe build some simple Sinatra apps that just dump out some data. Dont get stuck spending hours digging through documentation during the event. Just because you can’t bring code into the competition doesn’t mean you can’t learn the tools you’re going to be using.

One of the gems I wanted to use for this Rumble was a wrapper for the BoardgameGeek API. It’s a good thing I actually tried using it, because it turns out that the documentation on github is for the current master branch, while the version you get from gem install bgg is completely different. Being able to figure out why certain API calls were failing without a stressful 48 hour deadline looming helped me figure out what was going on faster than had I just assumed the documentation was correct and waited until the competition.

It should go without saying how this lesson applies to real life, but failures in planning become much more apparent much more quickly when you have a hard deadline. If you have milestones set up for hour 36, hour 42, etc, and something pops up at hour 41, it can put the whole project at risk as you scramble to find a solution in time. This appies to any project with a deadline, whether it’s 48 hours, or 4 weeks.

Think small

The first Rails Rumble I did was with 3 other friends, and we had the idea for PlanitShareit. The app had two phases: 1) Plan your vacation, and 2) Share your vacation.

In phase 1, you put in a trip length, location, budget, etc. On each day you added Trip Stops to your itinerary by entering in landmarks, addresses, etc. You could add notes, costs, and length of stop. You could re-arrange the order of the stops, and each time you did, you would get updated driving directions from stop to stop.

Phase 2 began when you started your vacation. You could upload photos or add notes to each Trip Stop. This was a way of instantly categorizing and ordering all of your photos and thoughts by day and location, the idea being to create an instant Vacation Scrapbook that you could share with other people. It would be more than just a Facebook Photo Album dump of everything into one album with no context.

So this all sounds great, right? Finish Phase 1 in the first 24 hours, and finish Phase 2 in the second 24 hours. We had four people. We could do it. Except that by hour 36 we were nowhere near done with Phase 1. By the end of the contest, “PlanitShareit” was really only “SortOfPlanitMaybe?”. We just had way too many features and too big of a vision for our timeframe.

In any hackathon, you need to pare down an idea into its most basic, fundamental core. We should have scrapped the budget planning, driving directions, and ideas about Facebook integration and focused on an app that let you add Trip Stops to a Trip Itinerary, then upload photos and notes to those stops to a publicly viewable “Trip Scrapbook” page, without all of the bells and whistles. We shouldn’t have even worried about making the app have two distinct phases for the user. Better to simplify and have the user do everything in one place.

Any project shoud begin this way. Save all the things that would be nice to have for later. Dont even begin to worry about them or factor them in to your project planning or app design. What is the most basic thing your app should do? How can you achieve that? Too often projects fall victim to some Steve Martin-esque trap of continuously adding on new things just because you want them.

Don’t be such a loner

I did this year’s Rumble as a solo team. The first hour I spent setting up my environment, deleting it, and redoing it. I had planned on how I wanted to build my app, then immediately began second-guessing myself. It’s not a great way to kick off a time-sensitive event by wasting it on mundane details like “Do I use Rails Composer or Thoughtbot’s Suspenders to quickly build up the framework for my app?” Having teammates to discuss this with beforehand would have led to a firm, thought-out decision less likely to be scrapped. Also, it would have allowed one person to set that up while everyone else started on other tasks.

Another problem: 7 hours into hacking, at 1am, I was pretty much done. Sleep seemed like a way better idea than worrying about finishing my app. It was one of the only times I’ve done a hackathon as a solo team, and it was rough. With a team productivity doesnt grind to a halt when someone drops out for a nap, and there’s always enouragement from each other to keep going.

Teams have a benefit in real life development, too (I feel like all my hackathon lessons are glaringly obvious, and yet most developers have probably seen these issues at work at least once). Besides allowing team members to take over if someone has to drop out for a given time, working on a team can also prevent rabbit holing, that is, focusing so narrowly on one mundane detail that you waste a lot of time instead of focusing on the broader picture and getting work done. I think I spent about 2 hours just trying to get Facebook and Github OAuth sign-in working. Did I need it? Maybe. Could I have just done a simple guest-user auth in less than half the time? Probably. If I had been on a team, I could’ve asked for help or ideas once I felt myself going down the rabbit hole. When you’re by yourself, though, it’s hard to keep from going down one.

Hack the planet

So there it is. Hackathons can teach you a lot about yourself and your skill as a developer. How quickly can you pick up new technologies? How good are you at project planning? How good are you at executing a project plan? How good are you at handling unexpected issues quickly? How do you perform under pressure? They’re also a great way to finally work on that project you’ve always had kicking around in your head but never had time for. Make the time – quit making excuses and just get hacking!

I would definitely recommend everyone tries a hackathon at least once. Even if you’re not a developer and just have an idea, there are hackathons that are focused around entrepreneurial events where someone pitches an idea, and then developers and designers can choose one to work on for 48 hours for the contest. For example, this weekend is the Global Startup Battle. Find a local event, hear some pitches, join a team, and get hacking!

More Posts by Brad Huber: