This does not sound like an easy exercise, so maybe it's a good idea to share some thoughts on why we decided to participate in the contest, and how we worked together to complete the challenge.
All of us are working on Ruby on Rails projects on a daily basis (and for sure we love Rails and like to use all of the great new web technologies). We’re sure, every developer has some ideas about applications they want to build, but never had the time to do so. The Rails Rumble was the chance for us to implement some of these ideas, together with people we like, our colleagues. Besides that, a contest like this is always a good chance to try out new things, to extend your knowledge regarding whatever project and development-related task you can imagine, to learn from each other and to compete with the rest of the community. Backed with these arguments, it was easy for us to find some people at Infopark who were interested in taking part in the contest.
The planning phase
After a brainstorming lunch where we discussed what to build, we focused on three particular ideas, and after a quick survey our teams had been formed. In total we started with three teams and eight participants.
But how should you build a feature-complete application in 48 hours? As in nearly all situations in life, preparation is everything. Our teams made fundamental decisions about which database to use and looked for ready-to-use services that might be helpful. To avoid long discussions during the contest, we chose designs, formed user stories, prepared wireframes and even built the database schema in advance of the contest. We also made a rough time schedule about who will do what and when, just to not lose our orientation during these two days.
We also decided to sit side by side most of the time, although it would have been easy to work at different places. Sitting in the same room or office makes direct communication clearer and easier. And if you have just 48 hours, you certainly don't want to waste any time waiting for responses.
Don’t re-invent the wheel
All the services we used, e.g. Mandrill for sending e-mails, or Honeybadger to track errors, had especially one thing in common, they were easy to configure and easy to use. For every potential issue or bigger todo that sprung up during our planning sessions, we looked for a service or a gem that was able to solve the problem for us. This resulted in a list of over 40 gems for some applications. We also made intense use of all the great stuff like the Rails-Composer, Twitter Bootstrap, git-deploy, or figaro (to name only a few) that made it almost a no-brainer to get started quickly. Concerning the database, our teams used MongoDB or PostgreSQL. Deployment was done with git-deploy and Capistrano, together with the provided Linode StackScript.
To constantly test the current state, we deployed often, used rspec in combination with capybara and guard. We made a lot of small and quick reviews and plannings throughout the project. When we saw that the time/value relation for a planned feature was not good enough we simply ditched it or changed its scope. To manage, prioritize our stories and track our progress, we used Pivotal Tracker. We only used little of its huge feature set because we had no real sprints and we also did not estimate every single story. But it was great to categorize and sort our open todos, bugs, and stories.
Now you may think: "Give me a second, haven't I read this somewhere else before?" We think you have, probably because you’ve already heard of agile software development. This is what we do every day at work in our projects, and the Rails Rumble contest made it clear to us that it also works in really short-lived projects. If you don't do agile software development by now, you should at least give it a try in the near future - maybe for a small time-boxed project.
To summarize our way to get the application finished:
- Plan and prepare everything you can and what the rules permit.
- Build a team of people whose skills you know, and always assign tasks to those with the highest skill level for the respective task.
- Use existing services and software whenever you can.
- Present your progress internally and externally as early and as often as possible.
- Group your todos and user stories in three categories: essentials, basics, and nice-to-have features.
- Keep the basic feature list small, but have a well-sorted and huge nice-to-have list.
- Even in a 48 hour project, establish a management and development process (as one example, we used a pragmatic variant of git flow).
We hope you've got an idea now of how we worked to complete the challenge. Please feel free to contact us and to exchange experiences (we are also always interested in more community events). To take a look at our applications, visit Rails Rumble and scroll through the list of 200+ completed entries (out of 500 registrations), or just use the following links: