The Contest
Railsrumble 09 is an annual 48 hour programming contest that aims to show off what small teams of developers can accomplish in this extremely short timeline using the remarkable web development framework Ruby on Rails.
The Setting
On a hot humid afternoon in a western mountain city of North Carolina we gathered a scant 2 and a half hours before the contest started. The office was warm and our data models had not been completely fleshed out. Our chosen location was the shared work space Locomotivity owned by teammate Lance Ball. It is interesting to note that this very space used house the old costume shop. But I couldn't find any left over costumes. Lance obviously kept them all for himself.
Bright light poured in the windows. We moved desks, chairs and a huge 4x8 makeshift whiteboard into our working area. I pulled out some paper some pens and passed them out while monitors were being plugged in.
Anticipation hung in the room. We had no idea ...
The Team
There was a hard limit on the team size. Only 4 contestants per team. Well, we had 5. It didn't occur to me to count Jack until now. So we may be disqualified for having a dog on our team. Jack can't program at all, and that was annoying at first. But she would periodically come over and provide needed encouragement. She would look at you right in the eye as if to say: "Dude you're stuck. Chill for a sec. Pet my head." I really appreciated that feedback from Jack. She had another look which clearly said "Is what you doing really worth sitting down for hours with bad posture? Pet my head." That wasn't as helpful. She didn't have to minimize what we were doing. Ya know?
Just in case you were wondering: Jack is a she.
Besides Jack there was Lance Ball, Zach Hale, Tobias Crawley and me. Of the four humans only Toby and I were accustomed to programming together. For Toby, Zach and I it was our first time working in a team of 4 people on a new project. That lack of familiarity was not a strength at the beginning. But we did have combined experience base going for us. We all had similar values when it comes to coding and I guess that's why we all use Rails now.
However we were all coders. Not a real designer among us. Crap.
The App
The intention was to build
dailydid.com a simple web app that helps you track whether or not you are doing a certain task on a daily basis. The idea was that we would listen to tweets that contained the hash tag #dailydid or tweets that were addressed to @dailydid. When tweet like this occurred we would aggregate that data and display it in a way to show the user what they did. So now all you need is a cell phone and you can track these daily goals. Say for instance you want to run every day. You would tweet: @dailydid #ran . Dailydid would then tick that off for you as done today. Simple idea right?
The First Night
Friday afternoon at 5:30 we had a very rough sketch of what was ahead of us literally. I had scribbled down 4 pages of wire frames in a notebook on Tuesday morning. And Toby and I set talked about models Tuesday night for an hour. The specs were scant to say the least.
So at 6pm we looked to the white board and tried together to flesh out some models and their fields. As the start time neared the realization that we weren't well prepared really hit. We roughly divided the initial tasks just before start time.
Toby server login and setup.
Lance generate the initial app and push it to the contest code repository.
Zach look at generating the initial models and data generation.
I was going to do an initial design mockup in Gimp.
That was the plan and it was a rough start. I started drawing circles in Gimp. Lance fought github for a few and Toby probably got the worst of it setting up gems and the environment on the server.
I quickly abandoned the idea of mocking up in gimp and started setting up twroute to listen to Twitter and route the right tweets and post them to our app because it was something that I could do and get done.
Lance got the app up and started working on the update model and tests for it.
Zach started working on creating fake data.
It seemed like nothing flowed we had a hard time getting organized and delegating tasks. Nothing but bumps in the road. We worked till we were too tired and had very little in the way of an application to show for it.
I went home and couldn't sleep so I got up and flipped open the computer. I concentrated on making sure all the models were working and tested. I explored the idea of using Unicode symbols as major graphic elements because I knew that would save a bunch of time. Before I crashed into bed at 3:45am I had the header/logo created and the models all tested. This felt like a good foundation to hit the next day with. Hopefully we could hit the ground running.
Saturday Aug 22 - Second Day of the Rumble
Well I woke up Sat morning early and started coding right from bed. I had thought of a quick way to get sample data into our app and wanted to have it working before we started our day.
I got to Locomotivity at 10:00am ready to go. We really got going. Tasks were delegated and we started all intent on getting things done.
The biggest problem (time sink) was that the Yajl library that Twroute depends on had changed. It now apparently buffered tweets and did not push them through right away. So Twroute behaved significantly differently on the server than it did on local machines. This was very confusing. It looked like our tweets we falling into a black hole. Without tweets our app didn't function. So this was a priority and a 2.5 hour time sink. Uhhhhhhhg!!!
Progress was being made at a fairly constant rate. We really clicked and got going. By the end of the day we had a solid app. With only some styling and Time Zone issues to address. We learned from our experience on the first day and were determined to have something real that worked by the end of the day. And we did it! This let the pressure off and we all went home and slept.
Sunday Aug 23 - Last Day of the Rumble
So we had a real app as a foundation by now. We could now prioritize the secondary refinements. We had a bunch of great refinements on a list. Even after 30 plus hours of development we were overly optimistic about what we could accomplish in the final hours of the contest.
We decide to make a scrum list and do hourly scrums to control time waste and rabbit holes. We had what looked like a simple list to accomplish.
- get Time Zone Support going
- display some basic statistics on the user page
- inline twitpic and yfrog images in the displayed tweet updates
- look at the app in IE to see if anything was insanely egregious
- get a profanity filter going
- style the day show page
- style tweets on the hompage
- finish the about page
We really thought we could get all that done in an hour or at the very most an hour and a half and then move onto the next list. Well ... that didn't happen.
The biggest time sink was trying to calculate streaks of days in a row. This was problem caused by contest pressure combined with fatigue. It took 3.5 hours to give up on it. Uhhhhhhhg.
The second biggest time sink was time zones and the collecting and reporting of data. Our primary data unit a Twitter Update was not coming from the users browser. It was coming from a local tweet collecting daemon so we had to figure out where the tweet was coming from and correct for it. Less fun than you might imagine.
Inlining images from twitpic and yfrog took about 2 hours.
Styling took about 2.5 hours.
The profanity filter fu-fu interacted strangely with our tests resulting in developer confusion.
When the first scrum ended and we still had a bunch of stuff on the scrum list. After the second scrum we saw only some of the things come off the list. And then it was lunch time.
After lunch, I remember still being overly optimistic an noted to the team that we could reuse the current views to display activity from the community as a whole. I don't know what I was thinking. In the next hour it became very clear that no new features could be added as we were still plowing through things on the first scrum list.
I was really becoming paranoid about developing anything that needed to be styled. Styling was just taking more and more time as we refined things. I was becoming a 'no' man. No new views! No new features!
We were walking in quicksand but things were still getting done. We now had a grip on reality. We were getting tired but we knew we would have a complete project that would be fairly bug free by the end of the rumble. I think that is was that security that let us plow through and finish some of the harder tasks.
We were really a team now and worked faithfully toward the goal of having a good clean finished app. Everyone chipped in wherever they could. The deadline was bearing down on us and it made everything very real. It was really amazing to be a part of that.
We finally made it to a second scrum list which was more of a punch list.
- Style hashtag combining links
- make a link to the about us page
- fix the cross browser Unicode dot rendering problems
- Remove the text shadow from a certain screen element
- add the rumble tag to github
- style the inline images
- default user page if they have no tweets
And that was it. We envisioned having 4 or 5 lists we ended up with 2!
But we finished confidently. And happily. We shared an overwhelming feeling of accomplishment and celebration afterwards. Smiles were big and we couldn't stop patting ourselves on the back. We were all in love with our dailydid. Our child of a 48 hour labor.
We all went out afterwards to Nine Mile and we all ordered the same exact meal. One last symbolic act that showed that we were all on the same page. Well except for Toby who didn't drink any of the beer.
Reflections
A good time was had by the whole team. I had a lot more fun than I ever expected to. I am grateful to Toby for taking the initiative and signing us up. I am grateful to the Railsrumble organizers for putting the event on. I am very grateful for having such am awesome team. I will definitely do it again next year.
Next Time
- Next year I believe a better description of the app is called for. Handwritten wire frames, model descriptions and algorithmic problems identified and pseudo coded.
- Algorithms that are tougher should be talked about and we shouldn't ever make the assumption that any algorithm is easy.
- Understand clearly that problems that we don't think of will come up at the least opportune times and will eat most of our time.
- Come up with a mitigation strategy for time sinks. Scrum hourly from the beginning so that time sinks can be identified. Upon identification of a problem move immediately to pair programming, simply swap the the task out with a teammate, just consider dropping the problem completely.
- Know our server environment and daemons better ahead of time.
- Have a better approach to the site design. If there is no designer on the team it is a little silly to invest too much time into display its just inefficient. Pick a project with fewer design elements. Go simple. Go Zen white and black. Put hard time limits on designing individual elements. Have a ten to twenty minute granularity for design tasks. Just because I have a sexy design idea doesn't mean I need to implement it.
I believe doing these things would have saved us 60 man/hours of development easily. I am looking forward to giving it a try again.
