Daniel Pietzsch

Personal blog. Mostly photos.

Rails Rumble Recap

During the weekend of October 16th and 18th, I participated in the Rails Rumble 2010 coding competition. The exercise was to build a web app from scratch in 48 hours using Ruby and Rails.
Our team consisted of 3 people: Tim, Falk and myself.
The app we produced: Pianrra - An online keyboard with recording and playback functionality.

It was a rather spontaneous decision to participate. Falk and I joined Tim - who had registered ealier - only one week before the competition started. Then the planning and prototyping started.
The main reason we participated was to have fun, build something interesting and get smarter (although a little fame and a prize wouldn’t have bothered us, either). That’s also the reason why we chose to implement this particular idea of an online keyboard. It was the most unusual, risky, and exciting idea of all the ones we discussed in the week before the Rumble.

The Rails Rumble is a great exercise in collaboration - especially when you work with a team as distributed as ours. Tim and Falk were working from two different cities in Germany while I was hacking away in New Zealand.
Here are some of my insights.

Plan ahead

You can plan a lot of your project beforehand. This is crucial. When all of the planning is done before the competion, you can fully concentrate on the implementation during the 48 hours.
You aren’t allowed to produce any production ready code or graphics, but there is still plenty you can do. Here are some suggestions of what to think about:

Everything you can plan in advance, should be. Unfortunately we didn’t have the time to do so and decided a lot of things during the competition. So there is definitely much room for improvement next time.

Write it down

When you plan all this stuff, write it down! Use a tool of your choice where your team can collaborate easily. This is especially important if you’re not sitting in the same room during the competition.
We used Basecamp to do so and I think it helped a lot. Writing it down helped to clarify the vision for the project (‘What exactly are we going to build?’) and helped to agree on the technologies we are going to use. It definitely eliminated most (if not all) of the existing misunderstandings among the team members.

Additionally, create a list of to-dos and assign each of them to a specific person. It helped us to stay focused, agree on features and - this might seem obvious, but really isn’t - everybody knows what everybody else is doing. (Again, this is especially important if you only collaborate online).

For me, in order for a project to be successful, good communication is essential. And writing down goals, tools, features, to-dos etc. was and is an important part.

UI is important

Rails Rumble confirmed to me again, that the UI is the most important part of the software. What are all your amazing features worth when almost nobody can figure out how to use them? Right. Not much.
I won’t say that it was that bad in our case, but we certainly had quite a number of confused users. We made quite a few quick decisions during the competition (especially towards the end) and these obviously weren’t the best. We also struggled with finishing on time and so certain features and improvements didn’t make it. Additionally we also had to deal with more or less unexpected browser and OS incompatibilities. If we had planned beforehand, this would have been less of on issue.

So: get your UI, workflow and copywriting right!
There’s a lot of competition during Rails Rumble and people simply don’t have the time and/or energy to figure stuff out for every app. I know this from myself: I looked at every of the other 179 apps, and when something wasn’t clear to me, didn’t work etc. I just moved on to the next one.

Conclusion

Altogether it was great fun. Sometimes stressful and exhausting, but still fun. We learned a lot and successfully delivered a working application. I am really looking forward to next year’s edition.

Check out our app Pianrra. (You might need these instructions.)

Miscellaneous Notes