Why Hackathon?

CPS Renewal asserts: "Hackathons produce apps, not solutions to wicked problems"

I think this is a mis-framing. There are two separate issues:

1. what are hackathons for and how to make them better
2. how do we create events (and in general, processes) that help solve wicked problems

A hackathon is supposed to be a simple thing

an event in which computer programmers and others involved in software development, ... collaborate intensively on software projects

Wikipedia - Hackathon

The basic idea is you create time for people who are experts in coding to work on coding problems.  What has happened is this idea has collided with the open data and open government movement, and been loaded with expectations about public outreach and systematic transformation.  Now (to exaggerate somewhat) hackathons are expected to:

• produce commercial-quality smartphone apps in 48 hours
• stimulate billions of dollars in economic activity
• convince millions of schoolchildren to choose computer programming as a career

This is a lot to ask for out of an event structure that was originally a dozen people with laptops trying to fix a few bugs or to make a prototype of a web service that brokenly half-does something maybe interesting.

What are Hackathons For?

For a general public hackathon, they are mostly for fun, networking and awareness.  They're not actually about coding.  They're definitely not about making smartphone apps.

To pick Ottawa Aquahacking as an example, some reasonable goals are:

• to raise awareness of the Ottawa River ecosystem, water quality and related issues
• to connect e.g. the river science experts, river data experts, and coders, to make a few small things that may illuminate a few aspects of the river
• to expose people to a different way of working together
• to have fun

This is not the place to:

• get free resources for the complicated app or website you've always wanted to build
• solve river ecosystem issues

Basically, we have some new tools: data, code, the web.  This is a way to bring those new tools to an existing problem and see if anything interesting emerges.  For people who aren't familiar with the possibilities of these tools, the experience may change their perceptions of how we can use technology.  For people who aren't used to open collaborative work, the experience may help them to reimagine some of their problem-solving.

Apps Contests

Apps contests are a good way to reward people for coding.

They're particularly good at rewarding coding if they connect to mentoring, internships, and investment opportunities.

Apps contests are not a good way to get apps.  If you want apps, you should procure apps.  If you use an apps contest you will get a one-off app that won't be updated and will probably eventually disappear.

Apps contest are an ok way to show the possibilities of bringing new technology to bear on a particular problem space.  But they should be considered illustrative examples, not solutions.

Hour of Code

D5 Charter (PDF)

The Participants have decided to commit to working towards the following principles of digital
development, acknowledging that they will not be able to meet all of the criteria on joining:

3.7. Teach children to code - commitment to offer children the opportunity to learn to code and build the next generation of skills

Everyone wants children to code.  People want some hackathon / apps contest / Hour of Code / Elsa-skating website to make this happen.

Motivating people to code is kind of an odd thing.  In a list of just the 15 top tech billionaires, the poorest has eight billion dollars.  This would seem fairly motivational. 

All of which to say, there are many pieces that determine people's choices of career.  Events that give a tiny sense of what coding is can maybe help a tiny bit, if they're well-structured enough that they aren't intimidating, exclusionary, and confusing.

But if you actually want people to code you need to build it into the curriculum, as both a separate track and an integrated tool.  That is to say, you need to have both computer science courses and actually use the computer science skills in the other classes.  And reward and recognize all along the way, not just wait for the students to emerge out of highschool with a few coding classes and expect them to want to continue clawing their way up to work at Google or become startup billionaires.

And it's way more than "coding" (which means everything and nothing, from writing a line of HTML to making some JavaScript to building an entire iPhone app).  It's computational thinking, logic, problem-solving using technology.  While it is WAY better to have kids come out of school with JavaScript skills than "teaching them computers" by training them in Microsoft Office, it's guaranteed that whatever language and approach the schools will codify will be obsolete by the time the students emerge.  So it has to be both fundamentals and practical application.

It has to be education that prepares people to solve wicked problems.

Wicked Problems

Hackathons are not supposed to solve wicked problems.  They're supposed to do very small things, with technology.

The good news is we have all kinds of other emerging approaches, some of them perhaps inspired by the hackathon ethos.

So in this space, we have things like:

• @PolicyLabUK
• @18F
• Presidential Innovation Fellows
• US Digital Service (see e.g. White House announcement, Playbook)
• UK Government Digital Service

These are organisations made up of people who use innovative approaches to solve problems.  Sometimes these approaches will include bringing new technologies to bear, sometimes not.

People solve problems, not events or technology.

Eventually, these organisations should demonstrate enough successful approaches that the overall system can be improved, with a combination of better education in school and better training on the job. 

We don't want a world where all forms are fixed by a special Form Innovation Service.  We want a world where everytime a form is created, the employee knows how to design it properly.

Wicked Problem Events

That being said, the way you construct an event is to first choose the right people, and then choose a variety of approaches.  You might unconference, you might do ideas generation, you might do sticky notes and then all leave for several days (as suggested in Hearing Every Voice in the Room).  We have lots of approaches that we can use now.

One of the underlying challenges is that hard problems are hard.

I see lots of events about e.g. IT infrastructure for science where you hear the same big problems over, and over, and over again.

Wicked Problem Spacetime

Ultimately, what you need is not one-off events, but trust, networks of collaborators and time.

The fact is that even to build a simple thing, you need lots of people working together.  You can see this from the building of ORCid.  Assigning a unique number to every researcher is not a conceptually or technically complicated thing.  But making it happen took deep thinking about trust, governance and sustainability. 

As another example, getting people in general and scientists specifically to use version control isn't a conceptually or technically difficult problem.  But almost no one uses version control, even though it is foundational for many other layers of advanced things we can imagine.  (And there is a related issue of whether people should need to "use" version control at all, or it should just happen automatically for them in their tools.)

We need to get better on the strategic side, to make sure we're solving the right problems, but the notion that we're particularly focused or "good" at doing tactical technical pieces I think is off-track.  We're actually terrible at tactical technology. 

So in response to

I think the focus on apps (to the detriment of research) is a by-product of our shortened shadow of the future, our culture of immediacy and the omnipresence of attention economy...

from An Alternative to the Hackathon

I would say yes, a focus on apps is misguided.  But don't confuse delivering apps with delivering tactical technology.  We could benefit from being a lot better at quickly delivering usable technology, in support of an overall strategy that addresses wicked problems.  We need both a better short game and a better game plan.

Comments

[Nick]

Thanks for the thoughts Richard. Like I said in the post I wanted to avoid the value-proposition of the hackathon debate; my interest was mainly in making the point that I think that we'd get more out by investing further upstream. In many ways it was little more than an ounce of prevention is worth a pound of cure reasoning. As a caveat, I was also trying to make it in a way that didn't throw current efforts (and announcements from the political class) under the bus. As usual, thanks for taking the time. Cheers