Readying for the rumble

Rails rumble has come round again: if you’ve not registered yet it’s probably too late, but there are still people out there looking for teams to join. I did it last year, came 39 out of about 120 as a single person team and made something I’m still using. If you’ve not rumbled before, here are some tips (some of these I did last time, others I didn’t). These tips are also predicated on the fact that you want to place as high as you can, not just take part. The basic theme is: do as much as you possibly can (and are allowed by the rules to do) before the 48 hours starts.

• Pick your idea carefully. Some ideas place better than others. Games and sites driven by user content don’t seem to do so well (mainly because they look so empty). There will be about 10 other teams doing variations on todo lists. Developer tools did better than I expected last year.
• Read the rules. Unlike last year you can’t use design services like 99designs. On the plus side, this year you can use any rack-based framework, not just rails.
• Figure out exactly who uses your app. Not just a woolly “everyone” or “ruby developers” but nail down exactly what it is they would want from your application. Last year I didn’t do this - I just had a vague impression of “people who use amazon like I do”, but pricepounce would have benefited from doing more of a detailed user breakdown.
• Know your audience. This year you have at least three audiences - those people you would want to use your app (see above), the judging panel and the public judges. Judging rumble apps is a bit like using the internet on fast forward - people need to able to grasp exactly what your app does in a couple of seconds and try it out, otherwise your scores will be low. Everyone judging your app will have an openid, so use that as your authentication mechanism, even if it wouldn’t be appropriate for your target user base. Better yet, don’t require any signup at all to try out your app, or provide a dummy account for judges to look around. Your idea doesn’t have to be applicable to everyone - last year riverdex (aimed at kayakers) did really well - but it does need to be immediately obvious what your idea is.
• Register a domain name. It looks so much better than the subdomain the rumble team give you, and will be useful after the competition if you decide to keep your app going.
• Register any support accounts. You’ll probably want some accounts with other services: hoptoad, google apps (for mail), uservoice, twitter, rubyforge, web service accounts are some examples.
• Sketch out all your screens. In detail, possibly more detail than you would do normally. Remember, every decision you make now is one that doesn’t need to be made over the weekend.
• Write all your copy. Quite a few teams seemed to have skipped this step last year, so you had quite a few blank pages with “TODO” or similar. Writing good copy may take as long as writing code, and blank pages make your app feel really unfinished.
• Find all your design collateral. Icons, stock photography, fonts, background patterns - anything that you think will be used in your final design.
• Learn your libraries. Do a simple play project that exercises the functionality of each gem/plugin you are going to use.
• Learn linux and git, if you don’t know them. You don’t want to be dealing with sysadmin problems half an hour before the deadline.
• Create a rails template and other provisioning scripts. You don’t want to spend hours setting up your linode or installing gems. Creating base application templates is allowed, as long as they are open source.
• Don’t do your own mail. I tried this last year, and discovered at 10pm on Sunday that hotmail thought my messages were spam. Use google apps instead, it solves these problems.
• Don’t forget details, like 404/500 error pages. Again, your app looks unfinished when people hit them.
• Setup the server first, and deploy as soon as possible. Then you’ll never be in a position of missing the deadlines, and it gets you to “done” faster.
• Test, but don’t over-zealously test. Two of the biggest benefits testing gives you are ensuring long-term stability and improving your technical design - neither of these matter for an app built in 48 hours. You do want to have some test coverage though, because manual testing is slow. Strike a balance - if you’d normally do all of integration/view/controller/model tests, you can probably afford to drop some of them.
• Plan out your time over the weekend in detail. I did this to half-hour granularity last time, and it worked very well. It forces you to not be over-ambitious and keeps you aware of exactly how much you’ll be able to get done. Focus on executing a small part of an idea really well.
• Get a full team of four, or go it alone. If you’re in it for the prizes. A single person team isn’t likely to win, but can pick up the “best solo effort” prize.
• The rumble is about shipping. It isn’t the time to go off the beaten track and use mongoDB or Waves or whatever is the new hotness this week. Use the tools that you’re most familiar with - you can’t afford to lose 3 hours figuring out some unexpected problem and you can do that sort of thing on the other 51 weekends of the year. The rumble is about building a product, and not really about the technology.
• Have fun, and sleep. Simple!