Saving the Hackathon

The #1 way to save hackathons is to stop offering cash prizes to winners. That way people who are coming to the events to make money will stop showing up, and people who show up won't worry too much about winning, and the people who are there for fun/exploration/friendship/camaraderie will be able to build and enjoy whatever they came for. Compare the quality of hackathons with massive prizes in cash or funding (i.e. AngelHack) to those without (i.e. StartupWeekend) and you'll see a dramatic difference.

GroupMe is an outlier, it was a great story for Twilio but it was a huge surprise. We never ever ever sponsored or organized hackathons with outcomes like that as a goal, even after it happened.

People alway asked me why Twilio has always supported building "toys" in our hackathons, contests, etc. - and it is simple. Often in their free developers want to build toys, play, explore, be free to make a mess - and we want to make them happy, and associate being happy with using Twilio. And maybe they'll go back to their day jobs and think of us when a problem we can solve crops up. Sponsors should focus less on getting PR hits and shiny hacks, and more on giving what hackathon attendees want, and the events will be good. Organizers should seriously consider whether sponsors are adding value, and whether the prizes they offer are worth the trade-off.

The general public, including most hackathon organizers and corporate types, have no clue about how long it takes to make software. No one has a build a car in a weekend contest. Even if someone could build a car in a weekend, they find the parts, find suppliers, and plan the design out long before the weekend and have a dozen people on standby to do the work. What you end up with a hackathon is the equivalent of a soap box racer. It looks feasible because it can take you from the top of the hill to the bottom of the hill. But it's not a car.

The entire concept of productivity out of a hackathon is born out of a perpetual misunderstanding and lack of knowledge about software development because the people that organize them usually have always A) found someone else to solve their problems. They have no concept of how long a problem should take to solve. and B) payed money to resolve their problem immediately. Again, they have no basis for how long a problem should take to solve. If someone suggests a hackathon and expects actual results, which lots of people do, those people have not come to terms with the idea that engineering is where the "find someone else to solve it" chain comes to an end.

I attended this hackathon.

The biggest problem in these hackathons is that it's more about the pitching than the product.

At this particular one, they even told us, worry about the UI and the pitch, don't worry about the backend.

I've been to 5 hackthons total, including 2 Techcrunch disrupts, 2 angelhacks, 1 startup weekends. What I realize is that the winners aren't the best hacks, they are the best pitches, some people only demo their hacks for 2-3 seconds and it's questionable that it even works.

If the business person pitches well, and you have a good designer, you probably win.

I guess I'm different to the target audience for this article. I go to hackathon for fun and a change of scenery. I don't expect my hackathon project to turn into a new startup. I use them to test out new ideas. With the bigger better organized ones like TechCrunch Disrupt I get to meet useful people in companies with APIs I may want to use in the future. I usually go with buddies and we stick it out and produce something at the end.

I've learned lots under the pressure of hacking fast and loose to get a product built and will continue to go for that reason. I'd love to hit a big idea just right and have something sustainable to follow up on of course but I'm okay with just having fun, meeting interesting people and learning.

I was at the hackathon too, and had a good time. It certainly felt a lot more like a Startup Weekend than a traditional hackathon- there were people there that had ideas they'd clearly thought about for a very long time, and wanted to continue to work on after the event. That's awesome. But I suspect I wasn't the only developer there that wasn't willing to make that kind of a commitment to a project, and was just there to work on some interesting ideas.

So, I suspect the key here is communication, and setting people's expectations before they walk into the room. As it happens in this case, I don't think the judges on Sunday participated in the panel on the first day, so they weren't judging based on 'real world' merit- I know of at least one "boring, back-end" solution that didn't even get the chance to present.

I participated in an "extended hackathon" last spring called the Boston Innovation Challenge. In addition to the unusual format (2 weeks from kickoff to demos, with mentor office hours offered in the intervening weekend), the best part was the fact that several community representatives showed up with real, specific problems they needed solving. A musician talked about the difficulty of having people serendipitously discover local live shows. The American Red Cross of Eastern MA brought up their problems in connecting with younger, more itinerant citizens to spread disaster prep awareness. Both of these representatives had several teams form around their problems, and a few useful applications actually came out of the challenge. Were they "start-ups"? No. But real problems got solved, and everyone had a blast.

When I think about Hackathons, I always think about GroupMe (reportedly acquired for north of $50M). It seems like an example of right place, right time, right technology, right audience. Lightning striking.

"We were at the first Disrupt Hackathon in New York. We had group SMS working on Twilio’s API. You could add people to the group using commands on SMS, or you can use an HTML5 webapp. The only problem was that you had to know numbers and type them in. I mean, it kind of sucked. But we added in an offers tab, and in the demo we were talking about the LOST series finale. In the top corner, when you clicked on the offers tab, it took you straight to an actual ad for half-price if you check out the LOST series finale event at Brooklyn Bowl. We basically demoed that we had a working group chat with a functional business model...

We had the idea a couple days before, and after we decided to go in we found it was a massive springboard for acceleration and growth."

http://techcrunch.com/2012/05/11/from-disrupt-ny-to-a-43-mil...

I actually gave a talk with a very similar title back in December at API Days and I'll be giving a second iteration at the API Strategy Summit at the end of the month in NYC (http://www.apistrategyconference.com/).

My thesis is that the problem lies in the disconnect between the goals that we think hackers have and the goals that they actually have. If you want to know more about that, watch the video below. But the point where I think we intersect is about direction and the benefits that it can have. Great hacks solve real problems. There's no doubt about it. You should do everything in your power to to put real, visible problems into the hands of developers because they will solve them.

Anyway, good writeup.

-

"Saving Hackathons": http://www.youtube.com/watch?v=ocY70UORNsk

What I like best about this post is the underlying message you can almost miss. Yeah the hackathons are important; we should save them; software engineers need a place to get collaborative together; and making "simply pretty" apps isn't all that awesome. The message getting to me, however, is that software engineers may not be all that great at requirements gathering. We work out improvements to almost every part of our workflow all of the time (e.g. new languages, ides, postures, etc.), but when was the last innovation for requirements gathering?

If there's a major bottleneck in the process, it's probably the disconnect between client and developer. Not that I'm saying this is an easy problem. It certainly isn't. Perhaps we need a bit more focus on this issue than how to create nicer interfaces, though.

I found that having problem statements does energize hackers. As a participant, I've seen a lot of people not having "cool" ideas to work on and instead ending up smashing together a bunch of API's or building another social share app.

To relate to your point of organizing purpose-based hackathons, I've helped organize a hackathon last year, in which we brought in NGO's and had them issue problem statements about specific problems in the third world. Then hackers were encouraged to try to solve these problems using tech. I was amazed at the results -- people had actually built something useful to the world outside the narrow 48-hour time window! And in the end, the programmers seemed happy that they were solving a real problem, of course doing it in their own "cool" way.

I agree that it may be unrealistic to expect fully functioning products out of a three day hackathon, but I am continually impressed by the amount that people accomplish in such a short period of time. Extreme time constraints can often be a useful tool to break conventional thinking and prompt disruptive solutions.

Here's two suggestions that might produce a more focused outcome and reduce wasted effort:

1) Engage key stakeholders throughout the hackathon - so that a deeper understanding of their problems is reflected in the hacked solutions

2) Offer an "overtime" session for those who are interested in working with the stakeholder over an extended period (a few weeks or possibly months) to refine the solution

I participated in a Hackathon this past weekend where the organizers had formed a panel of technology experts to interface with the charitable organizations that we were hacking for.

This was really excellent, because they met with 12 different charities many times over a period of time. By meeting so many times, the tech panel was able to tease out some really specific ideas and the hackathon ended up being pretty great.

It was my first hackathon and I learned a lot about what not to do. C'est la vie.

For the past few years, I've had this idea of creating some kind of hackerspace. The number one rule(s) would be: You must build something original. Or you must be learning how to build things. Software, hardware... whatever. If you don't make then you are not welcome.

I've never been to a hackathon, but I wonder if this is the problem when the author says "They exploit developers."

Music Hack Day and similar events are great way to meet people, no one expects a product (maybe sometimes there are?) but only a nice weekend to meet similar minded developers.

I am quite convinced that the companies who sponsor are more likely to be looking for recruitment opportunities than hacks that they can monetize. Don't underestimate a good party…