Ramblings on RailsRumble – Josh Software
Gautam Rege 2012-10-29 06:03:31
Just when you think you are “too old for this shit” (ref. Lethal Weapon), there comes an opportunity that gets you back in action. In my case, it was Rails Rumble!!
When I told my folks at home – “I’m going to be a 19 year old again and do a 48 hour coding stint” – the retort I got was “The only thing did for 48 hours when you were 19, was a drinking binge!”
When RailsRumble was announced this year – it was a ‘recharge’ for us at Josh! We had floated this idea at our weekly Open Source Friday meetup and we got a great response. We had 3 teams from Josh that participated in Rails Rumble and 1 team that was a combination of developers from the meetup.
We started at 5.30am India time on Saturday, 13th Oct. and closed for the first day at 1am in the next morning. We were all back at 8am and stuck around till 5am on Monday morning. We clocked the entire 48 hours in-and-out of office and it was great that all 4 teams managed to complete their work.
These were the 4 entries that were in full swing at Josh office!
So, what did we learn from all this?
- Its never to late for this shit 🙂
- 48 hours is a VERY VERY long time.
- Given the right combination of designers and developers, it can indeed be a lethal weapon!
- Planning is everything. If you have your mock layouts (in Balsamiq or even as crude as a scanned paper layout) it helps. In case you are wondering, I did have a crude layout on paper – which we scanned for reference!
- Beer helps focus when you are going for a long haul – not too much of course 😉
OK – here is also some “Technical Learning”
- Do not ignore deployments. When we started our work, one person from each team was doing just the deployment setup – using mina or capistrano etc. RailsRumble team was kind enough to provide different stacks for auto-install and configure but you sill need to deploy your code! The last thing you want is a working application on your local machines but the linode was not setup!
- Plan the tests and Test the Plan. We first set out a plan for the scope of the work and one of the team members was entrusted with writing tests – even if they were pending or failing. That helped us keep our focus in what we have to build – enthusiastic developers sometimes deviate from the plan. Since the time is short, you cannot do any ‘project management’ — so the tests keep the focus!
- Work together in pairs or all sitting together. Programming in pairs (not Pair programming) helps tremendously on such short burst work. Not only do you have someone sitting around checking intermittently at what is being done – it ensures no rework and focus on the project.
- Choose your team wisely. Ensure you have a designer on your team and ensure you are comfortable with all your team members.
- Plan for contingency. Always keep a Plan B in mind. There could be someone falling ill, emergencies coming in etc. scope your project.
- Read the competition Rules! You would be surprised how often we miss out on the little things. There were specific instructions on tagging your code and completing the project from the RailsRumble dashboard. I wonder how many teams completed their work and forgot to finish!
Well, this was an extremely refreshing experience for all of us – and we were really proud of the work we did. The great part is that these projects are not dying out — they were just the beginning kick-starts for cool ideas. These are being implemented and the work on them will continue!