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:

  • What app are you going to produce?
  • What technologies/plugins are you going to use?
  • How’s the user interface going to look like? Create Sketches!
  • How are your users going to interact with the site? What’s the workflow?
  • What is your database model going to look like?
  • What name do you give your product?

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

  • Working in two very different time zones (GMT+1 and GMT+13) is awesome. You can work around the clock.
  • Janrain Engage authentication worked beautifully. It saved us lots of time.
  • I used Basecamp for the first time. Loved it. There was no learning curve and it’s very intuitive.
  • We kept in touch via Skype’s group chat and conference calls.
  • Splitting the project into two sprints worked very well.

Notes

  1. adesatca reblogged this from danielpietzsch
  2. danielpietzsch posted this