DHH18: The Week-Long Hackathon
Perspectives on Hackathon Design
Hackathons as a Design Problem
The past academic year coinciding with Suomi 100 was filled with energy and momentum and an abundance of hackathons, company visits, gatherings, workshops, parties… then there was also Slush — the whole experience felt like one continuous startup festival.
Along the way, I’ve been thinking about the concept of hackathon itself as a designed object. The world has many real problems, what can be solved by yet another frenzied weekend, cramped at dimly lit desks with a horse-dose of energy drinks, and scant sleep and hygiene? What should be the goals of a hackathon? What are we hoping to get out of it?
Practical, career-capital related motivations:
- Winning prizes (indeed I saw hardcore veterans hauling full workstations in IKEA bags at the Junction hackathon)
- Showcasing one’s skills (also connecting with companies, the hackathon is partly an industry expo)
- Opportunity to work on a project, and being credited with having put something into practice, with teamwork simulation
Aspirational goals:
- Festivity has become a major element of hackathons. To some extent we have bought into the infectious hype of the startup scene, we want to be active and be part of it.
- There’s the hope of being social, meeting interesting people, learning about new ideas and gaining insights.
- In the best case scenario, it sows the seed for a wildly successful startup, as epitomised by the example of Smartly.
- Or, we may come up with novel ideas — particularly with a design hackathon (e.g. Dash) — even solve some real-world problems.
Speaking of the power of facilitation, and events or institutions as designed objects, I’m getting back to writing this article at a Shut Up and Write meeting, which takes a dependency-recovery approach to academic writing.
Hackathon Syndrome
Dash was a unique example, it’s a design hackathon aimed at producing conceptual solutions — that’s what makes it interesting — hackathons as a problem-solver for the real world through design-thinking methodologies.
For me that represented elements of an ideal: beyond the festivities and prizes and hectic frenzy, it would lead to something useful and worthwhile.
The opposite of this ideal is the “hackathon syndrome”: a shiny, trendy big topic (e.g. “Digital Health”), a lot of clueless running around, and the haste to present something trivial (e.g. a catalogue page of clinics) and unoriginal.
You see these very impressive headline keywords: “Urban Mobility”, “Intelligent Infrastructure”, “Smart Cities”, but what concepts do students end up presenting? A half-ass wannabe clone of one feature in Google Maps.
In fact, not just hackathons, it’s now very popular in entrepreneurship education to get students to form groups and try to come up with a “pitch” in a few days. In longer business courses, or even courses on design, students try to develop concepts and present them in iterations — the question still applies — how to make the exercises meaningful.
The Origin Story of Hackathons
The original impetus of a hackathon was more or less a facilitating device for programmers — you’ve had an idea for a while that you always wanted to experiment with — now there is an opportunity to overcome inertia and sit down over a weekend to implement an MVP of the idea.
That comes back to the question of “what is a hackathon good for?” Great things have to start somewhere, “hackers are free people like artists”, and like artists they generate lots of ideas then leave those on a shelf indefinitely—in the spirit of a commitment device, hackathons are a good kick to get the creative process kick-started. It’s also productive for engineers to become familiar with a prototyping stack and to be able to build a demo quickly, because many products starts with a proof-of-concept.
Double-Edged Double-Diamond
Then there’s the dream of solving some of society’s biggest problems with the design process: a new category of hackathons. Imagine a month-long or year-long design hackathon dedicated to “reinvent the university”, from designing the architectural environment, to organising courses as gatherings around public learning space (theatres, cafeterias, museums), the whole idea of “School as a Service” and no longer as fixed buildings, to designing the teaching activities in new forms (informal seminars, conferences)…
Can a hackathon like Dash live up to this dream? I was chatting with some Dash organisers about the last event, a main limiting factor seems to be the double-diamond process of design. By the time most participants arrive at the event, the problem-space, even to some extent the solution-space, has already been defined and constricted. If it has been decided the solution must have four buttons, the most you can do it tweaking and restyling those buttons.
Solving real problems needs a bit more patience. What if we had several pre-hackathon events, from months before, to go through in-depth discussions? We can re-design the “exploratory phase” to bring out all the latent creativity, and to have a well-considered picture of the topic’s landscape.
Structured Patience
Recently there was a workshop course on sound spatialisation at the Media Lab. We were a small group, the subject itself was highly technical, but we were in the Art department. It was the month before the Media building was being shut down and vacated, there were artists’ artefacts everywhere, books, posters, electronic parts, decade-old Macs, random materials, and a humorous “the-end-is-coming” cheerful chaos around the scene.
At the end we were having some reflections about the course structure, pedagogy, etc. and noted a few things:
- The Media department has dedicated blocks for workshops spanning a week or sometimes three weeks. Students can choose between the topics based on their own interest — but there’s always the whole week reserved for the workshop, which resolves some scheduling issues.
- Students from other department don’t have these dedicated weeks — instead they have lectures or other activities from different courses interlaced and scattered throughout the week — which does create scheduling issues. When you have K number of students in L number of tracks or courses to fit into M time slots and N teaching spaces — the “integer programming” problem becomes very complex…
- The course was assessed by completing a personal project. Also in the design of the course schedule, we found it really helpful to have had a hiatus between the workshops and the final presentation, about a week of off-time to work on the project and let it develop — in contrast to the haste and hurriedness of most hackathon projects, where participants are rushed to pump something out and present the next day.
- Then we thought, what if the hiatus were even longer, about a year? Say, the projects are to be presented as installations at some fancy event planned a year later. What if we had this longer development period, with monthly check-ins with the instructor, with multiple concurrent tracks of experimentation on ideas? Would it foster more cross-disciplinary collaboration where people can help each other explore technical and creative possibilities?
The “Unhackathon”
When asked about how the Junction hackathon can be improved, I wrote:
How about an “unhackathon”, a healthier pattern in place of hackathons? … A week-long event at some hotel, everyone gets to go upstairs and sleep properly. More time to gather around topical interests and form working teams. Ideas would be explored more in-depth, and thoroughly developed. The end results could be working products, even to be worked on further afterwards. You get to meet more people and actually get to know them, maybe find new life-long friends… more meaningful interactions and productive work could take place.
Careful what you wish for, just then I saw a poster for Digital Humanities Hackathon 2018. The first thing I noticed was that it’s a week long, in fact, this year it’s even longer, striding a weekend.
The event has gone through multiple iterations (one each year), and now has many features that are very different from typical hackathons:
- The focus was on “digital humanities”, using quantitative and computational methods (that is, analysing data at scale) to answer research questions in the humanities (e.g. History).
- No competition or prizes.
- No sponsored topics.
- It spanned over more than a week, starting from the week before with introducing the topics and forming teams. Then there’s a weekend in between to let ideas ferment before diving into specifics.
- Each workday went from 9am to 5pm, like a working day, people then got to go home and rest. The “hackathon frenzy” was notably missing.
- Each topic was brought in by academics who had been working with it for a while — they also served as group leaders, who form a team together with hackathon participants interested in that topic.
- The group leaders were familiar with the research topic and had been working with the data and had a repertoire of knowledge and techniques— I was impressed by the readiness and speed with which they were able to supply immediately useful data to enable features.
- This level of guidance and preparation was quite an advantage, in contrast to frantically trying to form an idea in most hackathons.
Productive Socialising
When we all lived at the student village at Aalto, one friend’s place really had the “founder lab” feel to it. The room is 5–10°C warmer than outside from a crypto-mining operation. There’s a suitcase full of experimental VR devices, there’s HTC camera towers in the corners, there’s a rigged laptop screen with buttons and wires dangling on the outside as a secondary monitor. He also sleeps on a couch like Fox Mulder.
This “lab scene” had always been something I found admirable. It’s the engine of innovation. Yet these days with the great tidal waves of tech and business, it may not be enough to “lock oneself in a garage”. You must be active, you must be out there to be in touch with the development in the field.
Well, the overshoot would be frivolous schmoozing and aimless running around and the hackathon syndrome… How can these activities be aligned towards a productive end? A recipe for success stories needs several components:
- There has to be some basis of skill: familiarity with a stack or toolkit to allow experimentation
- Platforms for discussions (perennial forums, satellite events) to explore and discover the topics
- Events for direction-setting (defining the problems), brainstorming, gallery wall of ideas, and team forming
- Hackathon sessions to kick things into motion and build a prototype
- Connecting with the cutting edge of industry; also excursion events etc.
- Elements of fun and festivity to make it enjoyable
- Built-in mechanisms for follow-ups, leading to jobs, projects, teams, and companies
The Good Life
On the note of festivity and social events, cosmopolitan Finns are masters of the art of living (sometimes too much so)… There’s a pub called Thirsty Scholar with a beer garden inside a compound of the university, it’s nicely hidden away right next to the most touristy city centre. The “main building” of the university is on one side of the Senate Square, we were walking through the many levels to get to the morphological archive where the social event happened to be hosted. The whole building was like a large, mysterious museum with classical style and many function spaces, on the day there was also some celebration scenes and pervasive scent of prosecco from the entrance, giving the impression there’s always some parties going on…
I had often thought of academic life as going to the monastery, doing a PhD is like putting your life on hold for a few years, or living in austerity, for some unstated sense of purpose…Well, the way these academics do it looks rather like a festive experience during which living is not suspended but expanded.
That’s another note about the circumstances of life. Certainly it’s beneficial to be able to quickly prototype and work with a “hackathon starter”, to build the next Smartly — yet we see all around us people no less intelligent and hard-working than those at Supercell, and wild success is attributed to a few. Hackathons may be far from the necessary let alone sufficient ingredients for getting to the promised land. In the meanwhile it’s good to not forget living.
