The blog of , a Ruby on Rails development team
Known from Rails LTS, makandropedia and Nanomize

Plat_Forms 2011 post mortem

In January we spent some days in Nuremburg at the 2011 Plat_Forms competition. The event pitched 16 teams of programmers in different web technologies against each other in order to provide insight into the pros and cons of each platform.

The work actually began a week before the competition started. We had to figure out logistics, configure a staging server and decide what pre-baked code we were going to bring. The rules permitted to reuse anything that existed before January 17th. Since we're doing a lot of blank-sheet Rails projects at makandra, software reuse is something we think about a lot. The tricky part was that the requirements wouldn't be revealed before the competition, so what sort of code do you box in a situation like this? We eventually decided to ditch anything too high-level and only package a few essentials:

  • Sign up, sign in, sign out
  • Role-based permissions
  • CRUD on users for admins
  • A pretty application layout
  • CSS and form controls for things like control groups, buttons bars, tag pickers, etc.

The event took place at the Nuremberg conference center where the 16 teams were channelled into two different rooms with desks and chairs. We picked a place in the smaller of the two rooms, which hosted only four teams, hoping that we would have some more quiet there. We installed a lot of hardware on the small desks, including three big-ass screens and a coffee maker :) After we had set up our working environment Monday night, we went for drinks and then to bed.

Tuesday morning we were back at the conference center and received the requirements we were expected to implement over the next two days. The task was to implement an application called "Conferences and Participants" (or "CaP"), where users could sign up, post conferences, sign up for those conferences, befriend other users, invite them to a conference, etc. The specs were 29 pages long and (in my opinion) a lot more than what can be implemented by three developers in three days. The point of the event was to find out how you would deal with that. The features where divided into MUST, SHOULD and MAY categories, so we fed all MUST requirements into Pivotal Tracker and went to work.

My memory of the next two days is something of a blur, but a few things stand out:

  • It's amazing how productive you can be when you dedicate yourself to a single job for two days. Another interesting experience was to work on requirements that don't change while you are processing them, albeit this is one of the major points where the Plat_Forms event failed to simulate reality.

  • I liked how we were able to reuse existing code for the CaP application. We have a fetish for packaging solutions to everything into reusable bits. Most parts of the Rails project we brought along mapped to a MUST requirement and we could use more than one pre-baked Modularity trait to implement functionality like the search query grammar.

  • We definitely could have spent a little less time on making stuff look shiny, but we're so used to combining programming and UI design that didn't want to change the way we operate for a two-days competition.

  • We didn’t like that a large part of the requirements was to basically implement the application a second time as a REST web service. The API was specified in a level of detail where no pre-baked API solution could be used. It was rather boring to spend hours mapping data from our model to the one specified, and no one can see the results.

  • A topic we had debated fiercely was whether or not two days would be enough time to amortise the expense of writing tests. We eventually decided to mostly write Cucumber features (high-level integration tests) and skip the lower-level RSpec examples except for cases where Cucumber felt awkward. Looking back I'd probably say that having tests didn't save or cost us a lot of time one way or the other. What I can say is that they allowed us to plow through the requirements at a constant pace rather than irregular burts. Tests also gave us the peace of mind to work on new features until minutes before the competition ended, without the fear of regression bugs. I'm curious whether test coverage will be part of the jury evaluation, since the organizers wrote that modifiability would be an aspect they are interested in.

The final moments of the contest were exciting in all the wrong ways. We had to package a preinstalled application server in a VMWare Server image and hand it over to the organizers before the deadline. And we almost missed that deadline because VMWare Server for Linux is a piece of shit and needs to die. We wasted hours before the contest to getting it to run and then it quit working an hour before the contest ended, complaining about unrecognized kernel modules (WTF!). Arne was able to save the day with some arcane Linux sorcery, but I’m never touching a VMWare product again.

In the end, we managed to complete all the must requirements and some should requirements. At least one other team seems to have completed significantly more of the optional requirements. I hope we will get the chance to look at their code, as we felt some of the requirements come with some tricky details.

After the event the teams and organizers met up at the Indabahn, which is nice mix of restaurant, lounge and dance club. There we had the chance to talk to the other participants after there had been literally zero time during the compo.

So was it worth it? Seeing that three people spent three days not earning money, plus preparation time and travel expenses, an event like Plat_Forms is quite an expensive undertaking for a small development shop like us. Nevertheless it was quite an experience and we’re looking forward to reading the results this fall. Our hope is that the Ruby teams will come out on top. If the results bring more attention to a rising technology like Rails, it was well worth the time and effort.

You can see some of our work at You will need to sign in to see most of the screens:

Screenshot of our CaP application

There are also a number of admin screens and the API, both of which you won’t see unless you are clever.

Growing Rails Applications in Practice
Check out our e-book:
Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Recent posts

Our address:
makandra GmbH
Werner-von-Siemens-Str. 6
86159 Augsburg
Contact us:
+49 821 58866 180
Commercial register court:
Augsburg Municipal Court
Register number:
HRB 24202
Sales tax identification number:
Chief executive officers:
Henning Koch
Thomas Eisenbarth