This past weekend I participated in the hacksummit.org hackathon hosted on the Koding platform. The hackathon started on Saturday February 20th 0:00hrs to Sunday 23:59hrs Pacific Time. We started with a simple idea, find an interesting data set, like emails, to send to IBM’s Watson personality insights or tone analysis engine. In the end, we made an app that worked but not how we thought we would – here’s what I learnt *.
#1 Ask for help
I recruited my team by posting messages and getting in touch with other coders on the #hackathon channel. I ended up with a team of 6 and had to turn down a few others as we were too close to the start of the hackathon to bring them up to speed. I also had to get in touch with the Koding team to clarify some of the competition rules and they responded quickly.
#2 Adapt
“No plan survives contact with the enemy” – Helmet von Multke.
We had 48 hours to complete the hackathon and after the first day we were still struggling to get data out of Gmail and the agreed mode of working was failing. We tried to keep track of commits and issues on Github but we couldn’t close them fast enough. In addition, two team members were not able to fully participate due to personal and other issues.
#3 Start with the deal breakers
Interestingly I had read this about the Google[X]’s approach to projects last week:
Ask cheerfully, “How are we going to try to kill our project today!”
But I had not yet internalised this lesson.
Our app idea involved connecting with IBM Watson Personality Insights and Gmail but we only prototyped the IBM Watson service and no one in the team had experience with getting data out of Gmail. We assumed that the Google+ login API would give us a token that would work for all Google services as long as we enabled the service in the Google Developer Console. In retrospect this was a critical assumption which should have been verified first and if false, we should have changed our plans before the hackathon started.
#4 Communication overheads slow down team velocity
We had a team of 6, including myself, and communicated mostly on Slack and once on Skype. Our main concern was agreeing on the app idea and not creating code conflicts. As new members joined it took longer to reach a consensus because our team was distributed (London, Switzerland, India and Romania) and it took more time to explain and go through everyone’s contributions. The ideal number might be less than 4. This reminds me of analogy of the tower of Babel in the Mythical Man Month by Brooks.
#5 Use what you have
By Sunday night (GMT) it was clear that we had to move away from Gmail as a data source because we hadn’t figured it out well enough. So with only about 10 hours left I stood at my desk at about 22:30hrs and started coding until 05:30hrs non-stop. I imagined that the entertainment industry would be an interesting subject but it was difficult to find accessible APIs on such short notice. Last.fm’s API worked and so did Lyrics N Music so I combined the two to create artist profiles based on their lyrics.
#6 Be gracious
There was a little voice in my head wanting to give myself all the credit for the final app since I contributed most of the working code in the final submission. Maybe I could split credit according to the Github repo commits. Primarily our team was participating in the hackathon as a learning exercise and we all contributed time, ideas, suggestions and feedback – if not code. And if code is the expression of ideas, where do those ideas come from? As a developer I value working code highly but everything and everyone starts from somewhere. I would also like to give credit to my wife for her encouragement during my emotional roller coaster with doubt, ambition and sleep deprivation.
Check out our app – Song Intelligence
* British past tense of learn although often confused with “learned” by my American cousins. 