Fast, Cheap, and Good: My Rails Rumble Experience

Patrick Reagan, Former Development Director

Article Category: #Code

Posted on

There was a palpable excitement in the air when I arrived at the office yesterday – voting for the Rails Rumble competition had started and 2 of the Viget teams at HQ were tracking progress as our applications bounced around at the top of the leaderboard. Ben posted the list of the competing Viget teams and the the lessons learned, so I thought I'd expand on some of lessons we learned as a team while building the Qflip application:

  • Constraints are liberating – Everyone in the Rails community loves to beat this drum, but there's truth to the statement. Having a specific timeframe in which to build an application shapes your feature list and functionality.
  • Quality takes time – One of the things that dropped off after day 2 of the event were our automated tests. I'm not proud of this, but in order to crank out the features we needed to just write lots of code to get things working. Yes, testing up front takes more time (a luxury we didn't have), but it is very much a "pay now" or "pay later" kind of thing. We opted to pay later. We are.
  • Elegance is underrated – We wrote some good code and we wrote some pretty bad code as well. Not surprisingly, the good code we wrote was early on when we were still focused on developing in standard TDD fashion (using Shoulda / Test::Unit / Factory Girl). There's something to be said for good application design and a well-thought out domain model - readability and maintainability suffer when these goals are not met.
  • Simple is difficult – The constraints of the competition basically required us to build something that was immediately useable, easy to understand, and hopefully useful. Having this focus whenever we discussed application features shaped the outcome of what we built.
  • Perfection is secondary to shipping – Our codes were far from perfect, but we realized that the real value was in getting a product out there that could be used in the way it was intended by a real audience. As a result we now have real feedback and focused ideas on how to make the application even better.
  • Decision-making is key – Time was definitely not on our side, so we needed to make key decisions quickly while staying focused on our goals of creating a simple, yet functional, application. Understanding what was important at each stage of the game helped us to focus on those features that we needed to work on.
  • Your design is worthless... – A good visual design is key to creating a great application, but if the application doesn't function as intended all that work put into that design was wasted. This is definitely something I had in the back of my mind as we struggled with the NetFlix API during the second day of the competition – if we couldn't deploy a functional application by the end of the contest, all of Doug's hard work could have been wasted.

There are definitely a few things that need a bit more attention which we plan to address after the end of the competition. The benefit is clear though, by having a working concept out there we're able to collect valuable feedback and then react to it in an incremental way. After we get "back on the horse" and make the codebase more solid, we'll be adding those minor missing features.

Overall, the competition was a fun experience and I'm already planning to use some of the lessons to how we run projects here at Viget. Thanks again to Doug, Rob, and Nic for all their hard work – I'm looking forward to splitting that bottle of Whisky when we take 1st place.

Related Articles