

Saving the Hackathon - janineyoong
http://www.tokbox.com/blog/saving-the-hackathon/

======
dmor
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.

~~~
theyCallMeSwift
I tend to agree that large cash prizes and thinking that hacks == startups is
a recipe for trouble. That said, I sit on the more cynical side of the fence
and I'm still not comfortable ruling out prizes all together. I'd like to see
an event where people were rewarded for embracing the hacker spirit though
(most helpful, best use of new tech, most common problem solved, etc).

------
codeonfire
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.

------
rwanghacker
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.

~~~
thelarry
I've experienced that at other hackathons too. Fake click throughs using
photoshop drawn screenshots beat out actual mobile applications with backends.
I stopped going to hackathons after a powerpoint beat out my hack. It was a
cool idea but the only execution was drawing some pictures. 24 hours to draw
pictures. Yup.

------
richardjordan
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.

------
untog
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.

------
didgeoridoo
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.

------
wallflower
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...](http://techcrunch.com/2012/05/11/from-disrupt-ny-
to-a-43-million-skype-acquisition-groupme-tells-all/)

------
theyCallMeSwift
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>

------
veneratio
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.

------
lycidas
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.

------
affiliate777
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

------
tylermauthe
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.

------
spin
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."

------
jensnockert
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…

