Disrupt Hackathons!!!

Last update: Friday 4/10/15 

This article is a substantial revision of my first note about hackathons  (November, 2014). The revision was triggered by (a) my increased awareness that employers are using hackathons as fertile on-site recruiting grounds for new employees, (b) my growing dissatisfaction as a remote "fan" of hackathons with the tweets of hackathon on-site observers, the selective summaries of hackathons subsequently produced by hackathon sponsors, and the limited effectiveness of Storify, Eventify, and other event curation tools, e.g, the DLL's Archives, and, finally (c) the creation of multiple live hackathon streaming channels on Twitch by Major League Hacking (@MLHacks). 

In other words, hackathons as currently organized are incredibly exciting events for participating hackathon teams, organizers, and sponsors ... but far less interesting to remote observers, e.g., prospective employers who can't send on-site recruitment teams to the hackathons, and educators who would like to gain insights as to how to improve the effectiveness of hackathons as learning experiences for students at their own colleges and universities

• A Hackathon is not a traditional chess match. 
  In a traditional chess match, observers only know which moves were made. They don't know the players' intentions. By contrast, the ideas in the heads of hackathon teams are at the core of a hackathon, and what viewers really want to watch is how hackathon teams transform their ideas into running code. 

• Getting inside their heads
  Some (hopefully most) of a team's app development process will be captured by wire frames and other documentation ... But unlike chess moves, the frames don't speak for themselves. So remote observers also need a team's verbal and written explanations of frames and/or other design documents. 

IMHO, the good news is that we now have all of the technology required to implement hackathons that will immerse remote observers into a team's problem solving processes. Therefore I suggest that we disrupt current hackathon procedures in two overlapping phases:

Phase 1 -- Blogs and Twitter accounts for each hackathon team

1a) As a hackathon begins, team blogs will only contain rosters listing team members and brief bios of each member. Team members should tweet brief introductions of themselves with linked photos. A group photo of each team would also be useful. As the hackathon proceeds, descriptions of the problems each team intends to address and the team's initial solution strategies should be added to the blogs. Wire frames and other code documents should be added as they are produced. Teams should tweet brief explanations of these additions

1b) From time to time throughout the hackathon, e.g., every 90 minutes, teams should be required to post updates to their documentation and tweet brief explanations of what the updates mean. 

1c) When the hackathon is over, the judges should post their assessments of each team's efforts on the team blogs and tweet brief explanations of their assessments.

We can do all of these procedures right now -- no live streaming required ... But when live streaming becomes available, we can make things a lot more exciting for remote observers by adding the following procedures to the ones described in Phase 1.

Phase 2 -- Live streams and videos

2a) Live stream each team's initial presentation and the judges' initial questions & comments, but also post videos of the presentations and the judges' inputs to each team's blog for subsequent replay on-demand

2b) Live stream each team's comments about updates to code documents and link replay videos of these comments to the updates on the team's blogs

2c) When the hackathon ends, the judges' decisions should be live streamed (and videoed), and posted on each team's blog. Presentations of trophies and other awards should be live streamed (and videoed) -- including handshakes, acceptance speeches by the winners, etc, etc, etc

Buggy apps-in-process should be streamed from time to time where possible, but live streams of the winning apps, i.e., demos, should be mandatory components of every hackathon. How can remote observers appreciate apps they never saw run on any screen??? ... :-(

P.S. This note only identified two kinds of remote stakeholders who could benefit from more accessible hackathons -- prospective employers and educators. But if  millions of game players and wannabe players watch game channels on Twitch, IMHO we could reasonably we anticipate that remotely accessible hackathons might attract thousands, perhaps hundreds of thousands of hackers and wannabe hackers. Viewerships this large would attract support from the kinds of sponsors who would pay substantial fees to place their brands in front of thousands of educated, young hackers ... and far more for hundreds of thousands ... :-)