Lessons from a Hackathon

If you’re a developer and have never been to a Hackathon, you need to experience one.   I went to my second Hackathon recently, and really enjoyed the experience.  When the usual 9-to-5 routine gets a little too routine, with the need to balance innovation with “business needs” (read: take it slow, play it safe, and color between the lines),  the hackathon is a brief vacation in the wild-wild west, where for a short time you get to stretch and sprint. 

This was a “civic hackathon”, meaning about 100 or so tech professionals and students come together with civic organizers and activists to discuss needs of the city and community, and how technology can solve them.  We are given 10 or so “challenge problems” by the organizers, organize into teams, and each team decides on one problem to solve.  We then spend the evening planning a solution, and the next day implementing as much of it as possible, using software, communications, and web technology.   On the one hand, it’s fun to dig deep and fast into new technology, and on the other, it feels good to use your strengths to help solve problems for the community.    It’s a little taste of what it must feel like to be a hero.

This year’s event was a good experience, and we got to stretch and learn more, but it did not seem like the final product pulled together as well as it should have.  As I reflected on how it could have been better, the following points came to mind:

1. Be willing to stretch.  You know the conventional wisdom of getting a good night’s rest?  Well, that was my first mistake.  That’s missing the point of the hackathon.  The entire event is less than 24 hours, so a couple more hours of work would have made a difference. In our business, we have to occasionally stretch, and a hackathon is one of those times.
2. Prepare ahead.  Cloud services like Azure are a great resource for such short-term projects (without resources), but it takes time to stand up a new environment in the cloud (e.g. creating virtual machines, installing components).  As much as possible, do that work BEFORE the hackathon.  Once you arrive, time becomes your tightest commodity.
3. Bring a white-board.  You can find these at Walmart, just 2’x3′, cheap & easy.  This may be the simplest AND most powerful tool you use all weekend.  It is a must-have for brainstorming.
4. Pace yourself, with the end goal in mind.  If you have a final presentation to make in three hours, then decide what really needs to happen in the final three hours.  The final hour should be focused on making the app presention-worthy.
5. Externals must trump internals.  This time I invested too much time trying to get some deep plumbing working (database, API, plumbing), when only a few people in the room would have understood or appreciated the details of that.  Well placed mock data can do just as well.
6. Use mock-ups (even wire-frames) to fill gaps.  The final presentation should show a smooth sequence of steps in the application process, without huge gaps leaving others to guess what you meant. Drawing up a wire-frame mock-up can compress hours of unnecessary work into 15 minutes, which makes all the difference in a time-based challenge like this.
7. Dedicate someone to the presentation.   Particularly if you have a team-member who is more of an “idea” or non-technical person, it may be smart to have them spend the bulk of their time just working on the presentation.
8. Help everyone to be productive and find their place.  The team needs leadership to make sure everyone has a “place” that contributes, even if that means drawing up the wire-frames mockups or working on the presentation.
9. Pull rogues into the flock.  Admit it, we all come to these hackathons with our own special “silver pistols” that we want to show off, hoping to be the hero.  The problem is with a team of 4-8 developers from disparate backgrounds, there’s no way everyone can use their own special technology, especially if they don’t fit together.  Once a platform is chosen, work to make sure everyone is contributing in a way that will fit into that platform.   Mock-ups may be necessary for transitions, but the transitions need to be realistic/believable.
10. Keep tabs on what people are doing.  It’s hard for someone to admit they are lost/over-their-head, and better to find that out early, than learn at the last minute that a critical piece wasn’t done.

It was a good experience, but next time I go to one of one, I’ll be keeping these thoughts in mind.  Winning isn’t everything, but it does make a difference to have a final presentation that one can be proud of, and that just takes a little attention and focus along the way.