Rails Rumble: 245,000 Lines of Code in 48 Hours

How do you generate nearly a quarter million lines of code in 48 hours? Simple: take about 500 coders, lock them in rooms all over the world, and challenge them to create complete web applications in 2 days. That, in a nutshell, is the Rails Rumble, a 48 hour programming competition held each year that gathers Ruby on Rails fanatics to create web apps in a single weekend.

Last weekend marked the second year that the Rumble was held, and a total of 529 participants across 231, one, two, three, and four person teams competed. That’s a huge jump from last year when under 350 people participated in the competition. Of the 231 teams that signed up, about 57% were up to the task of actually finishing an application in the allotted 48 hours. 90 teams got the deed done last year.

The Rails Rumble, which partnered with Linode, to provide a uniform hosting environment for competitors, and GitHub, to provider source control, tracked a total of 14,355 commits the private GitHub repositories over the weekend. Over 12,000 files were produced, and 245,257 lines of code.

The numbers are just mind boggling, but it doesn’t really explain why Rails Rumble exists and what makes it such a success for participants.

Organizer Nick Plante, who is the co-author of the book Practical Rails Plugins, told me that he drew inspiration for the Rumble from his own experiences participating in the 48 Hour Film Project, a virtual film festival in which participants attempt to write, shoot, and edit a complete film in two days. Plante also wanted to fill the void from an earlier Rails programming competition, Rails Day, that ran in 2005 and 2006, but fizzled out.

He got together with a team of buddies including Brian Turnbull, Darcy Laycock — who was a competitor last year, and Erin Shine to hash out the details, find sponsors, and figure out how to develop the infrastructure to run a contest like this. This year, the team has been generalizing the code base as much as possible and rewriting much of it from scratch. “The master plan of sorts is to open source it at some point and make running a competition like this as turnkey as possible,” Plante told me.

On a very core level, the Rails Rumble is about a basic tenet of design laid out by the creators of the Ruby on Rails framework: constraints are a good thing that foster innovation. “One of the best things about the Rumble is it forces you to embrace constraints — team size, resources, technology choices (Ruby, Rails, Git, Linux), and of course a strict time frame,” Plante told me. “Teams come up with a base idea, and an implementation, that they can get a first version of out within a weekend.”

For participants, embracing those constraints can be nerve wracking, but liberating as well. Second year participant Kelli Shaver, whose project took third place last year, told me that she looks forward to the Rumble every year. “It’s really exciting and rewarding to see an app come together so fully in such a short period of time. It’s a great motivator,” she told me.

She and her partner, Ryan Bates, worked together virtually, using a Campfire chatroom to communicate with one another while they created their entry, MyIdeaDrawer. Chat was one of the main ways that teams — many of which were virtual — communicated with one another. Over 11,000 messages were sent through the official Rails Rumble IRC room over the weekend from over 170 of the competitors.

Echoing what she told me after participating last year, Shaver treats the Rails Rumble as a learning experience. “I learned a lot. It was great to continue to hone my Rails skills alongside someone as talented as Ryan,” she told me. “Most of the learning came after the Rumble weekend ended, though, when I was able to sit down and really start picking apart the pieces of the app that I hadn’t worked on and hadn’t had time to go over during the competition.”

Forcing yourself to learn more about Rails is one of the clear motivators for participation in the competition. Plante told me he was happy to see how often people on competing teams would take precious time away from their own apps to help lesser experienced coders work through problems they were having via the IRC channel. “The Rails community, as you know, is great like that,” he told me.

Another Rails Rumble team consisting of four members, Matt Gillooly, Alex Taylor, Steve Babigian, and TJ Sondermann got together to create Twalala. Twalala is a web based Twitter client that comes with a “mute” button allowing you to temporarily pause the Twitter stream from particularly noisy friends. Sondermann told me he has been asking Twitter for this feature for months and telling everyone who would listen that it is a potentially killer feature for a third party app. The team came together around the idea by accident at a local networking event about a month ago.

Unlike Shaver and Bates, the Twalala team actually got together, since they all hail from the same city. Babigian told me that the team met in person at the start of the competition to hash out the details of who would do what and how the app would look, then went back to their respective houses to actually code and communicated mostly via instant messenger.

Embracing constraints was a theme for the Twalala guys as well. “The spectre of a hard deadline got a fire lit under us,” Sondermann told me. “Then at some point on Sunday morning, when it started to take shape — and work really well! — I think adrenaline/excitement kicked in.”

Would they do it again? Babigian says they’ll definitely participate in 2009, and Sondermann tells me that each of them is better off for the experience. “We’ve each learned a lot and we all have a client that we were happy to use,” he said.

That 131 teams were able to meet the challenge of creating a completed app in just a weekend is mostly a testament to the skill of the participants. “I’m always amazed at exactly how much you can get done in a time frame like this. This year a large number of the entries are absolutely incredible, polished products,” said Plante, who told me that he hopes that the Rumble will inspire other people to “get off their asses and get their ideas out there.”

Both Sondermann and Shaver told me that continuing work on their ideas once the Rumble judging is complete was in the cards.

Though the actual competition is over, the Rumble isn’t. Right now, all 131 qualified applications are up for voting at railsrumble.com. Anyone can head over to the site, register, and start voting. Many of the entries are truly impressive pieces of work — even before you know that they were created in just a single weekend.

Full disclosure: My site Rails Forum and SitePoint’s 99designs were both sponsors of the Rails Rumble this year.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Anonymous

    Headline = “245,000 Lines of Code in 48 Hours”
    First Line = “How do you generate nearly half a million lines of code in 48 hours?”

    245,000 is approx 1/4 million NOT half a million. You’re crediting them for cutting double the amount of code they actually wrote.

    I’d be curious in knowing how much of those lines of code were generated vs written. If you take the code generated by the scaffolding out of the way, the number may be a lot smaller

  • http://www.mockriot.com/ Josh Catone

    @Anonymous: You’re right! That was my mistake, and now fixed. Not sure how I missed that.

    Anyway, the 245,000 LoC number doesn’t include plugin, library, and vendor code… just stuff in the app/, spec/, and test/ directories of the Rails apps. Your point it certainly still valid, though. I am nonetheless impressed.

  • BJ Upton

    You know, what’s really impressive is not how many lines of code, but how few.

    245000 lines/529 programmers is only ~463 lines per person.

    Even if we just divide that among the 131 completed projects, that’s only 1870 lines per site. That’s awesome.

    Really shows just how powerful it is.

  • lamans

    Rock On, the the future of coding will be most interesting… Human interaction changing daily, coding altering to herd the crowds.

  • Darcy Laycock

    BJ Upton: that 245,000 LOC figure is actually slightly off and only restricted to the 131 teams who qualified (so, not those we removed for not completing / making something). That comes out to appx. 650 lines per person (As there are 375 people) but in truth I’d expect the number to be a bit higher than that for those who coded – it seems many more teams this year had one person dedicated to the design etc. Also, there is a slight error in the figure (my fault) – It only includes 128 of the 131 teams which puts it off a little but not much.

  • Anonymous

    Is there a similar contest for PHP?

  • http://www.tenmiles.com Shalin

    @BJ Upton: And how much of the code actually generated by Rails? :)

  • http://www.magain.com/ mattymcg

    @Anonymous There is FullCodePress, which isn’t specific to PHP, but both teams did build their sites in PHP when it was run. A little different in concept, but just as much fun!

  • madpilot

    @Shalin – very little, Rails doesn’t really use boiler plate code, and when it does it is pretty skinny. Our entry http://kwyjibo.r08.railsrumble.com/ had 1877 LOC – 919 of which were test cases – yup 452 LOC for that :)

  • madpilot

    Edit: That is WITHOUT HTML views, but never the less…

  • madpilot

    Another correction: Cut an pasted the wrong state – LOC: 1371 (Total lines with comments was 1877