Preventing Cheating at Hackathons (opens in new tab)

To me there is an inherent contradiction between the concept o a hackathon and any actual effective effort produced during one. The idea is that you only work on your project during that day. However in the current era just about any worthwhile programming effort will draw heavily upon years if not decades of previous work. I would even guess that the most interesting efforts at hackathons are the ones most directly related to an individuals current area of expertise.

Many good programmers today are quite adept at modularization or other related efforts like framework building. By utilizing existing frameworks and modules one can leverage an enormous amount of existing code. I think though that many of the most worthy efforts at hackathons actually leverage existing modules or frameworks that were actually built or co ntributed to by the particular hackathon participant who is using them.

I think because of this contradiction and because it is difficult to distinguish between a completely new project and one that is a continuation of existing work that we need to alter the concept somewhat.

Getting together to hack on existing projects and describe them is probably a more honest and generally applicable idea. If you really want to limit people to work done on that day you are going to need to be very specific about what types of existing modules and frameworks can be used and whether the individuals participating may have created those. I'm not sure I really see a great point to that sort of exercise though unless it is just for developers to demonstrate how many interesting techniques and algorithms they can carry with them in their mind. That seems kind of a primitive thing to test for when we have so many great ways of reusing code.

Hi: I valued this post. I participated (lightly) at a Hackathon a month ago where the were some monetary prizes offered by sponsors at the end of the event. There were two entries that seemed to have a lot of substance for a single day event, so the question tickled in my brain a bit as to whether there was a way to validate the efforts of the team from start to finish.

We have been wondering about the value of using a cloud IDE (disclaimer, I am CEO of Codenvy) as a type of quarantined project workspace that is managed by a 3rd party for the duration of an event, like a hackathon. The workspace would be structured & owned by the organizer and not the hackers. And this way the organizers could place assets like keys into the workspace, and also monitor what code is authored and / or imported into it throughout the duration.

We'd value the community feedback to see if there is value in such an offering. We may want to hack one up ourselves :)

Great article! I would like to add something to the source code solution:

* Create private repos for all the participants well in advanced, and ask them to commit their changes to their designated repo.

* At the time of the deadline, all pushes will be blocked, and/or the current version will be pulled down to a "demo" machine.

* Participants must provide a make file (or something similar) to automate the building on all projects.

* When their time for demo comes, they will only get to demo whatever that has been compiled on the "demo" machine.

* The "demo" machine would be hooked up to the projector, and will be the only machine used for demo-ing purposes. This also saves the time spent in hooking up their laptops to the projector.

That's all. Sounds academical, but it's a really good way of monitoring cheating (provided you have an audit team as well).

Great writeup. I totally agree with a lot of the things you're saying.

I think the simplest fix is to start shifting the focus away from the negative competitive aspects. Large cash prizes are a great example of one that we could do away with. As you suggested, focusing on non-monetary or community incentives would be a great alternative and the whole hackathon scene could benefit from that.

You should check out this talk I gave about hackathons a few months back. We definitely seem to be singing a similar tune. http://www.youtube.com/watch?v=ocY70UORNsk

Also, thanks for the Major League Hacking shout out!

I have another take on this - we should try our best to pick the hackathons we choose to join - https://medium.com/p/593688fa7c09

You don't have to go to every hackathon that comes along, especially ones that "feels" like you'll be pissed at in the end

I've never been to a hackathon. Could someone explain the fresh code requirement to me? I assume you can use open source packages and open source snippets. What if you're one of, or the only, author of the code? What about snippets of code that you wrote that aren't open source that you often use in projects?

I give up on hackathons. The last one I went to -- the winners presented a power point slide and won. They didn't even make anything. They were just there for marketing their startup, and even brought like 10 team members on stage. And this was a really big hackathon too. 200+ competitors. Such a shame.

I've been to a few hackathons but I've never really enjoyed any of them so I decided to run my own a few months ago.

Some things I didn't like:

* Big prizes encourage sucking up to sponsors

* Crappy work environments (plastic tables and folding chairs)

* No camaraderie between participants and teams

So I decided to run my own. My idea of a good hackathon was just a bunch of geeks in a room building cool stuff for a day. I didn't care about commercial viability or any business concerns, I just wanted to see people have fun building something neat.

* 8 hours on a Saturday, not overnight. This does lead to smaller projects but also brings in more people who don't want to spend the night.

* Have everyone introduce themselves at the start and talk a bit about what they want to work on. I only had 24 participants, this wouldn't scale to larger events.

* Keep everyone in one room so everyone knows what everyone else is working on.

* Keep the prizes small. While I had a sponsor, I capped the prizes at $50.

* Don't allow the sponsors to run the event. I let them give a five minute pitch about their product and put their logos on the website but I didn't give them control over prize categories or let them bother the participants during the event.

* Keep prize categories vague so that participants don't build for the prize. This is easier when the prizes aren't worth much anyways.

* Since the prizes were so small, I didn't mind if people worked on something they'd already started on prior to the event.

Overall, I think my event went pretty well. I charged $10 to get in which barely covered the T-Shirts, my venue was a coworking space I use so I didn't have to pay for that (and they paid for the pizza) and my sole sponsor (thanks BazaarVoice!) paid for the prizes and a keg. The dev evangelist they sent did a pretty good job and even worked on some code himself.

None of what was built was commercially viable in any way but that wasn't the point: people had fun building cool projects and that was my only goal for the day.

Some of the projects:

* A Lego Mindstorm robot that played the drums (one of the participants brought his son, this was their project) * A MakeyMakey project that used pizza crust and a keychain as input devices (seriously) * A Raspberry Pi based SNES emulator complete with HDMI output * Voice-controlled lighting * An Arduino-based step sequencer * A virtual world simulator * A naive chess AI in Scala

Personally, I thought it went really well. No, it didn't make any money (in fact I lost money since the shirts cost more than I expected) and no one was able to pitch their startup but that wasn't the point. People had fun. If you're hackathon is oriented towards anything else, don't expect the participants to have a good time.

shameless plug: If you're near San Antonio and this sounds like an event you want to go to, we're holding another one sometime soon, probably December. Email is in my profile if you want to get on the mailing list.