The Truth about Hackathons

07 May 2017

Unlike leaking gas or a hand twisting a doorknob, one of the most threatening objects we see in movies is the mirror. The way it reveals information to the viewer, when harnessed properly, can carve deeply into our minds. It’s not necessarily the imagery that remains, but the notion that can strike the heart. A keen example of this is in 1984’s Neverending Story, when our hero confronts himself in a mirror. Another character comments, “Kind people find that they are cruel, brave men discover that they are really cowards. Confronted with their true selves most men run away screaming.”¹

This is how I see hackathons.

I believe hackathons are outlets for the deepest desires of the participants. I honestly enjoy reading about proposed projects more than I do seeing the demos. I love to participate of course, but that’s only because I have desires that I keep bottled, myself.

A hackathon is the ultimate risk/reward, or perhaps the ultimate proof-of-concept. It’s meant to be throwaway work. The byproduct is not supposed to be something that is shipping to production; it is enlightenment.

In his analysis of hackathons put together through a wing of the National Science Foundation, Arlin Stoltzfus, summarizes hackathons the best²:

Typically, when the hackathon ends, and team members disperse and return to their day jobs, the team’s code repository and other tangible outcomes become inactive: no further work is done and there is apparently no direct productive use of the hackathon products.

In terms of tangible outcomes and their impacts, the value of hackathons lies in the exceptions to this general rule.

He points out though, how much value is obtained from the intangibles:

[T]he direct impact of tangible outcomes does not tell the entire story…[T]angible outcomes may have intangible impacts…Hackathons often provided a venue for participants to take risks, foregoing ordinary demands of productivity to experiment with a new approach that might not pay off.

In other words, the true power of hackathons is in the intangibles. The greatest intangible, to me, is The Truth. That truth will be different depending on who is looking in the mirror.

The Truth

Let me put it to you this way. In the past several years, I’ve participated in many hackathons, and have seen patterns that point to the inner-most desires in the given organization.

One company’s most successful array of projects was upgrading a framework version. Think about this. When they were given the freedom to do whatever they wanted, they upgraded a framework. There was something telling about this. In some ways it was television-poetic, how the band of engineers from different teams came together for this upgrade. This hackathon project actually conjured itself multiple times over a year’s worth of hackathons. Each time, a new team got code merged that set the stage for the next hackathon where the work could continue. The implications though are fascinating. Was this simply the one item that was just off of the backlog? Or perhaps there was a disconnect between organization sleeves? Whatever the cause, this is the thing that engineers were spending their time between tasks thinking about.

Other examples:

• I was in a hackathon that featured 4 projects tackling the same problem of system writes on centralized configuration. It had spawned numerous bugs and was a hassle to work with as an engineer. That hackathon was an obvious statement on the breadth of this problem.
• Once I saw a plethora of hackathon “ideas” which were already bugs in JIRA. They were customer-facing, were small, and had been open for a long time. To me, this meant that the customer-facing teams were hearing streams of complaints from users, and somewhere between hearing the complaints and fixing the problem, priorities got messed up, ownership got lost, process didn’t do its job.
• Yet another hackathon series I participated in, kept asking for front-end engineers. “We’d love some help from a FED!” was almost a mantra. This was at a community hackathon, whose engineers vary from week to week, but the theme of needing FED developers was consistent. Perhaps they needed to draw more front-end developers, or perhaps the originators of these applications should have chosen a framework they were more comfortable with.

Indeed to me, hackathons are special times. Maybe this is a strange comparison, but as a descendent in a line of alcoholics, I’ve attended some AA meetings, and they are special in a similar way. When an average-looking person in an average-looking outfit stands up and tells you extraordinary things about him or herself, unleashing tempests of regret, fear, anger, and on, I not only learn about the person, but I learn about myself. In both of these forums, safety wraps around the participants, who can openly cry out because they will be heard without being judged.

Hackathons, to me, are best when we listen.

_{1.: Quotation and photograph ultimately are the property of Warner Brothers and Neue Constantin Film, 1984. Hat-tip to Finding Faeries for a great pic that is well-optimized for the web.}

_{2.: “Community and code: Lessons from NESCent hackathons” by Arlin Stoltzfus Google Doc. Grabbed from Hackathon Workshop}