I think the academy and academic conferences would do well to incorporate more of the hackathon ethos and norms into its stodgy and plodding culture. So I like hackathons, I really do. But I wrote much of the following response to an email discussion about how to make an hackathon successful and I would also like to get other folks’ thoughts since my experience with hackathons is both limited to a few cases and biased towards cases that are more academic-focused. This is my read on the cultural norms and best practices and are almost certainly internally inconsistent. However with those disclaimers, here are some of my thoughts on why I’ve seen hackathons falter. This is mostly a list of chipping away everything that doesn’t look like a successful hackathon, rather than an affirmative list of how to make a hackathon successful.

1. Thematically underconstrained. While a strawman, “Let’s get together and scrape some Twitter data!” is the surest way to have a hackathon crash and burn. There needs to be some combination of the following: a documented dictionary, cleaned data, or a clear method, and always some defined site, question, or outcome. Taking each of those in turn, a hackathon might do any one of the following: go explore a canonical dataset like GSS, ACS, or AddHealth for geospatial data; take messy Reddit data and have folks clean and code it up using some extant framework; allow people to learn some SNA concepts using Wikipedia data. The point is there are clear boundaries about where the hackathon starts and stops to prevent people from being paralyzed at the outset by questions of scope, but people are free to pursue a variety of agendas, methods, and questions within those constraints.

2. Mis-distribution of technical expertise. This can arise from either having not enough people with the requisite skills or permitting technical people to self-select into working with other technical people. The result is the people who know how to scrape, process, and build are either overworked or not pushed out of their comfort zone. Hackathons absolutely demand a willingness to learn new methods and techniques — people who rejected out of hand the possibility of learning to program, design, or do basic statistical tests obviously should not be invited. However, it’s also unrealistic to think that people are going to pick up Python scripting in a few hours so there should be repertoires of activities that allow non-technical folks to clean data, code data, search for related work and documentation, do UEX and wireframing, etc.

3. Regression to the academy. Like any other profession, academics want to revert back to comfortable paradigms. However, a hackathon should not become a lecture with technical folks teaching others to do basic scripting, a troubleshooting session around a single person’s bug, or airing of concerns and quibbles over a method or approach. The overriding focus should be on getting something done (even poorly) rather than talking abstractly about how things might be done better. The format should be radically participatory and resist a focus on deliverables, authority, or schedule.

4. Over-ambition. To the extent the evocativeness of the portmanteau needs construction, hackathons are not meant to be quick or lightweight. It’s not something that happens in a 90 minute session, it should not be a filler between other activities, and it should not have to compete with alternatives that require less commitment. The hackathon will have no expectations of “success” and people shouldn’t be expected to continue the work outside of it. There’s both a floor (~3 hours) and a ceiling (~10 hours) on how long people should be able to work in a day and these hours should be clearly communicated.

5. Lack of respect for participants and their time. As an organizer, a hackathon is not an opportunity to get a bunch of people together to do your coding work for free. You do not let a bunch of folks sign up under the auspices of one theme, then switch it at the last minute to another. You do not forget to have enough space, power, beverages and food, or other support for the people who are volunteering their time and expertise. You do not fail to have the authority to protect the space from ideologues, influence peddlers, or people with toxic personalities by intervening or ejecting people if necessary.

6. Unclear rules. This is probably best done as a group, but there are basic procedural questions. What are the norms about people tweeting, taking photos, or emailing colleagues about what they’re doing in the hackathon? Will people be able to continue to use this data or code afterwards and under what conditions? If individuals have non-public access to data or other resources, how obligated are they to contribute that to the hackathon? Who is responsible for cleaning up afterwards? Does anyone need to be compensated for space, food, etc.? Are people allowed to work on or access each others machines? What kinds of services will we use for collaboration and how can we accommodate others who don’t or refuse to use those services (e.g., gDocs, Dropbox, etc.)?

What are others’ thoughts? Have I missed something basic here about the culture and ethos of hackathon culture? Does anyone have good affirmative or positive advice on how to make a hackathon successful?