Lowdown - our Rails Rumble '09 Application

The Walkthrough

The Problem and the Pitch

In April (2009), Paul and I started working very intensely with Cucumber. Our immediate reaction to the process was that it became clearer how to communicate features between each other and our clients, while still having something that directly relates to the code in the application; that is, your feature stories become living functional specifications. The downside was, it was hard initially to get the client to:

1. See the value of writing feature stories
2. Get involved in writing feature stories
3. Understand the cost of implementing a story

While our app Lowdown doesn’t help with #1 directly, it does help with #2 and #3. It also puts the stories directly in front of the client, which is hard when they’re in plain text files in your source control. With Lowdown you can collaborate on the feature stories and discuss costs per-feature and per-milestone. We feel that prominently displaying the cost of each feature encourages the client to focus on the ones that are most important to them and deliver the best value, while sidelining “nice-to-have” or “personal-mission” features of lesser value.

Rails Rumble reflections

It was really exciting to do the Rails Rumble for the first time. These are some things that I feel contributed to our relative success:

• We had two people working on design/UI. When the competition is based on how your app works, looks, and feels (rather than the code itself), you can’t skimp on the visuals.
• We had a pretty clear vision for the project and desire to actually use it ourselves. This kept us from going down too many tangents and also made us appreciate when things were broken or looked badly.
• We had a nice division of labor and a broad range of skills. Three of us have done a significant number of Rails apps so we were well prepared on that front, but we quickly decided that Wes would be responsible for the sysadmin, Paul would be working on the CSS and primary look and feel, Scotty would be our UI expert, and I would be responsible for the model and controller design. We were able to fluidly switch between roles but we had one person responsible for each.
• We (mostly) chose tools we knew well. The Rumble is not the best time to be trying to learn a new framework or using libraries that are brand new. Instead, we went with our tried-and-true combos:
  • Rails 2.3
  • Haml & Sass
  • Compass
  • ActiveRecord
• We communicated constantly. Being a mostly-remote team, this was essential – we were on Campfire and Skype at almost all times. We gave each other encouragement, discussed conceptual, design, and code issues, kept updated on progress, and notified the group of away times and breaks. Having a task list in Basecamp was also essential for the final push on Sunday – it nearly eliminated the “What should I be doing?” questions.
• We got along well – all of us have worked with at least one other team member on paid projects before. Paul and I have worked together so much that we almost have a sixth-sense about what the other wants. This made things a little challenging for Wes and Scotty at times, but the team dynamic was still really nice. I heard rumors of some teams that couldn’t deal with the stress and lashed out at each other, obliterating their ability to complete their apps.
• We planned a lot beforehand. Paul and I had been discussing this app off-and-on since May but we (the team) also spoke a lot over Skype before the competition and passed scanned mockups and database diagrams to each other via Basecamp.
• We tossed out anything that wasn’t going to be completed in the timeframe – including some things that might be considered necessary. It’s all about prioritizing. You can see a list below of things we wanted to implement but didn’t make it.
• We tried to finish the major features long before the end of the competition so we could tweak, bugfix, and explore the application. At around 6pm EDT Sunday, we were totally in quick-commit-bugfix mode.
• We slept. All-nighters just increase burnout and reduce productivity. Even if you’re only sleeping a few hours, rest is essential for brain health! My best code was written early in the morning after I had slept on the issues that plagued me late at night.
• Ironically – especially considering the purpose of our application – we didn’t test, spec, or write features. There were times we could have benefitted from TDD, but many other times it would have just slowed us down. We considered the app to be a prototype/proof-of-concept anyway, not a polished and hardened work of craftsmanship. That said, we (I) tried to write the code the way it would be written had we done BDD.

Things that didn’t make it

These are a list of things that didn’t make it into the competition-ready app that we would have liked:

• Support for scenario outlines, tables, and long strings (py_string) in features. With how challenging the feature UI was to design and implement, this just had to be postponed. The model layer has support for this, however, simply because I had to.
• Autocomplete for steps. One of the best things about Cucumber is being able to reuse steps you’ve already written, building toward a “common domain language”. With all of the other challenges we had building the UI, this feature was just too much.
• Export/import/syncing. My original concept of the tool was that it would be more oriented toward continuous integration, but we realized the primary value should be in engaging the client, not helping the developer. There’s some plumbing in the app to support this, so it should be an easy feature to add.
• Screencast/tour/help/etc. We barely had enough time to do the front-page of the app. That said, I think it turned out very well, thanks to Paul and Scotty’s hard work.
• Scalability/performance tuning. Beyond setting some sensible database indexes, the time constraints were just too tight. Luckily Linode’s VPS is pretty snappy by itself, even at the smallest size.
• Replacing the default error/not found pages. We talked about this, but other features won.
• Validations, permissions, roles, etc. Beyond validations we got for free via authlogic, and tracking who created/updated records, we just didn’t care for the most part.

Going forward

The most interesting thing, besides the advance praise for our app despite its most glaring warts, is that this will likely become a small business. Most of the team intends to keep using and working on Lowdown in the future, and we want others to find it useful as well.

Here’s to new ventures and successful collaborations. Cheers!