With this being my fourth year participating in the Rails Rumble I’d like to share tips for successfully completing a Rails Rumble project.

The Idea

While the most obvious item to not skimp on, the idea can often be overlooked. In 2009 my teammate and I neglected to settle on an idea until the first hour of the competition. While fun, the entry was hands down the worst we made in the three years of competing together.

Thinking of an interesting or original idea is undoubtedly the hardest part of the competition, but make sure it is a site you would actually use. Building for yourself is nothing new, but can really help your execution.

Preparation

Once you have an idea (hopefully a week or two before the competition) you should immediately start sketching, with your team if you have one. This helps with design, but is also great for deciding the priority of must-have features and what the nice-to-have features are.

Seriously, plan the order of features and tasks. It makes the weekend easier to manage, especially the last six hours.

The First Hour

The first year I participated in the Rumble we had no idea on how to setup our Linode VPS. It ended up costing us close to eight hours, which is a lot of lost development time.

If you’re serious about it, you could buy a Linode VPS and practice. Fortunately I realized, while a great part of the competition, it’s really not worth spending more than an hour on. The result is sprinkle-linode, a collection of Sprinkle scripts for setting up a Debian 5.0 server for Rails development on Linode. It provides a base to get up and running quickly.

Teammates? While one of you are setting up the server the others should start setting up the repository and getting to work.

Additionally you should deploy as soon as you have the server setup and an application generated. You don’t want to be down to the wire and trying to get your application deployed.

The First Eight Hours, or The Sleep Schedule

Living in the US means the competition usually starts in the evening. It’s tempting to work through the night, but I have to recommend against it. You probably just worked a full week at your day job and can end up burnt out early on.

The first year we thought it would be a good idea to alternate taking one to two hour naps. This resulted in lots of caffeine and near exhaustion by the end, which did not help our speed or code quality.

The second year I believe we executed the perfect schedule, resulting in winning the most complete category. The first night go to sleep around the normal time you would on a Friday night and wake up the next day at a reasonable time. By that night you will have close to 3 business days of progress done. Now here’s the secret: Start showing it to people! If your idea is semi-interesting people will start complementing you and it boosts your confidence a ton. It boosted ours so much that we worked through the night to the end of the competition, thanks to our prior full night of sleep.

The Final Countdown

Once you have the majority of must-have features implemented you can move on to the fun items. This is where having development planned out ahead of time helps even more. Put all the remaining and nice-to-have items on a whiteboard, or on sticky notes. Each teammate takes one, works on it, erases it, and repeats. It’s amazing how fast you can tear through these and seeing the progress gives you the boost of energy you need to power through the last few hours.

Finally, be sure to reserve two to four hours at the end for testing and cleanup. The last thing you want is a stray console.log, invalid link path, or weird CSS issue in a certain browser to cost you votes. And it happens more often than you would imagine.

Conclusion

Like all software development, good planning, a sustainable pace, prioritization, testing, and just staying focused can really help the final product. And don’t forget to have fun!