Saving the Hackathon
tokbox.com
Saving the Hackathon
1–10 of 19 posts
Re: Saving the Hackathon
#2I 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
Re: Saving the Hackathon
#3I 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.
Re: Saving the Hackathon
#4I 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.
Re: Saving the Hackathon
#5I 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.
Re: Saving the Hackathon
#6The 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.
Re: Saving the Hackathon
#7I 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.
Re: Saving the Hackathon
#8When 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...
Re: Saving the Hackathon
#9I 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.
Re: Saving the Hackathon
#10The #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.