Posted
by
samzenpus
on Monday September 16, 2013 @10:11AM
from the cheaters-never-win dept.

theodp writes "The fist rule of Hackathon Club is don't talk about Hackathon Club cheating. But ever-increasing stakes — the MHacks Hackathon at the Univ. of Michigan is offering over $30,000 in prizes — prompts Kevin Conley to broach the subject, suggesting it's time for some common-sense measures — including showing one's code or reducing prize money — to discourage Hackathon ruses, which can include pre-coding, faked live demos/videos, and the use of remote teammates."

Complaining people are hacking the rules of a hackathon is a supreme irony. You're taking people who thrive on the idea of bending and breaking rules and trying to shove them in boxes and demand they follow your rules. That's rich. You clearly haven't met many hackers.

Rather than bitching about "cheating", why not just issue the challenge and leave it at that. First one in wins, the end. No rules, no restrictions... and may the best person win. Or group. Or sentient AI. This is how hacking truly works -- it's all about finding novel solutions. It's about seeing how fast you can do it, how much skill you can bring to the table, how elegant the solution is... but at the end of the day, the only real judge is whether you passed the goal post. Few people anymore care about why or how... that's something to talk about after, as you bask in the glory of having done the impossible.

Actually, it is the art of deducing how a computer system *actually* works as opposed to how it is intended to work.

Yes, but authorities view anyone who makes the computer work in a way they didn't expect it to work as a terrorist, criminal, or dirt bag. They view your intellectual achievement with suspicion; You have managed to do something they didn't expect or anticipate. That must mean you're up to no good. You must have been smart enough to know they didn't expect it, therefore you were intentionally subverting their authority, therefore you're a threat, therefore they are authorized to call you whatever they need t

Hacking isn't cheating. Hacking used to be a respected method where you used various tools to create something interesting as a proof of concept. If you wanted to take the idea further, you then make a proper spec and rewrote the project using best practices and proper architecture (assuming you didn't the first time. Some people do take pride in their work instead if slopping shitty code together). Hackers had reputable reputations.

Hacking has nothing to do with cheating. Cheating is screwing over oth

It's slashdot so I can't complain that you didn't read the whole summary since the relevant bits were in the 2nd half. Had you bothered to get all the way to the end you'd see that in some cases people are submitting faked results which means they didn't pass the goal post at all, they 3d rendered the goal post and then pretended they passed it.

That's not hacking the rules. Hacking the rules would be using a team of 3 people and 18 dogs when the rules state a 3 person limit for a team.

Rather than bitching about "cheating", why not just issue the challenge and leave it at that. First one in wins, the end. No rules, no restrictions... and may the best person win. Or group. Or sentient AI.

Because you get code that looks like this: http://xkcd.com/221/

A "no rules" competition will always devolve to just bribing the judges. That's not particularly innovative.

unless the thing that they're supposed to create is revealed at the beginning of the event I don't see how they could bitch about bringing in code - but in that case, if they predicted the code beforehand more power to them. they're sure aren't writing the compilers at the event so everyone there is going to be leveraging someone elses code.

another note, what? they're doing contests?! how about just NOT CARING ABOUT ANY RULES and creating USEFUL SOFTWARE with the time you have to spare(seriously, that's wha

Reminds me of a scene from Naruto, an anime about ninjas (don't judge me, we're all nerds here!). There's a test to become a ninja, part of it is a written test. Cheating is expected and allowed, but only so long as you don't get caught. After all, they're ninjas.

The fun in cheating in such an event is that you can be caught. Break the rules and you lose. No ill will should be held against a person/team who cheats but it should be seen more as a failure to institute your hack properly. Except this time you are hacking the game.

After further reading ignore what I said I thought we were talking about hackathons like it was some of the games at def con where you hack into systems and play games. Not coding or building hackathons.

F1 has a pit lane speed limit, so that's a pretty bad example. Especially since not only do they have a speed limit but they have speed limiters in the cars so to try and stop the drivers from breaking them.

The speed limiters in the cars are so the driver doesn't fuck up, not because the rules says they are supposed to use speed limiters. Its an aid so the driver, pumped up from driving 160mph doesn't screw up when he slows down to 45-60mph and feels like he could get out and walk faster.

The pit lane speed limit is one rule. Actually Formula One has 121 pages of rules [espnf1.com].

A sport don't just "have" rules, it is created by a set of rules. Without the rules the sport does not exist. ("Eat or be eaten" is not a sport). The idea of a hackathon without rules isn't even good or bad, it's just nonsensical. "I mean, who is The Man to tell us this hackathon has to be about using computers to do stuff?"

I mostly agree, but there is another aspect to hacking which is not being reflected: limited resources. Hacking is about using your intellect to over come the limitations. Now, you could use your hacking ability to leverage more resources (because they are needed) and that would still be hacking. But it's not hacking if you develop your high-altitude rocket module by hiring Boeing to do it for you. It's not hacking if you gain access to the telecom switchboards by asking your best buddy the CEO to give

Complaining people are hacking the rules of a hackathon is a supreme irony. You're taking people who thrive on the idea of bending and breaking rules and trying to shove them in boxes and demand they follow your rules. That's rich.

If you cheat and get caught, you should not have cheated. Rules are rules, and you must not get caught breaking them. Adding extra checks to catch incompetent wannabe-hackers is perfectly ok.

Some colleagues of mine recently participated in the NYC BigApps series of hackathons this spring. We went into our first one thinking you had to hack something together from nothing in 2-3 days after pitching your idea and attracting collaborators. In fact the CollabFinder site they set up to facilitate putting together a team "from scratch," and all the window dressing suggests that. But when you get to the "competition" it's mainly established teams that already have products that they're tweaking or putting some kind of new, minimal gloss on it. Plus all the palaver and marketing suggest that they're hoping to spur innovation that uses Open Data to make life better for New Yorkers. But at the final awards ceremony the game became clear--the judges were all Venture Capital guys, and the only apps that won were mobile apps that were Yelp/Facebook/Instagram clones, that could be capitalized by the VCs and flipped on unsuspecting 2nd round investors for some multiple, or a clone of something else that was already successful in the market. The app that took top prize in the Education category was a blatant rip-off of Scratch, the MIT-developed, open-source program that teaches kids how to program by treating code blocks like legos, and which is freely available on the Raspberry Pi that my kids play with.

So, it's a bit silly to talk about cheating at Hackathons when the entire essence of these events is really "Pitch-a-thons" so VCs can find new crap to pass off on suckers.

Call us when the judges are tech-savvy people who really know what they're talking about and what real innovation looks like. Then we can talk productively about cheating.

If you allow video submissions as some kind of proof then your "hackathon" is broken and they "hacked" it.

"2. The hack is real, but the coding was done or started by the team before the start of the hackathon."

There is no such thing as code that doesn't really on previously developed code. You used printf! You're out!

"3. The hack is real, but the coding was done by a larger team than allowed due to unauthorized remote teammates."

Somebody needs to read The Mythical Man Month. Adding more hackers to a late hacking project just makes it later. If they can stay organized and succeed in a larger group in a limited time frame then they have truly accomplished something even most software engineers cannot do.

Somebody needs to read The Mythical Man Month. Adding more hackers to a late hacking project just makes it later. If they can stay organized and succeed in a larger group in a limited time frame then they have truly accomplished something even most software engineers cannot do.

I really hate it when someone takes that book to be an absolute when there are no such things. No, you can't produce a baby in one month with nine women, but at the same time you will find it incredibly difficult to produce nine babies in nine months with one woman - asking one person to build Twitter is an insane demand, adding extra people will only ever help even when the project is terribly late...

There are loads of scenarios where adding additional resource will do absolutely no harm at all and the worst that you can come out with is no gain at all.

Asking one person to build Twitter is an insane demand? Are you aware of just how basic Twitter is? A database to store tweets, users, and their following relations could be knocked up in a three tables. A few services, to post tweets, poll for tweets and user info, to follow/unfollow peeps. I'd be stunned if any halfway decent coder -couldn't- produce a Twitter clone over a weekend.

Somebody needs to read The Mythical Man Month. Adding more hackers to a late hacking project just makes it later. If they can stay organized and succeed in a larger group in a limited time frame then they have truly accomplished something even most software engineers cannot do.

I really hate it when someone takes that book to be an absolute when there are no such things.

In my 20+ years of doing engineering at varying places, I can tell you that the concepts presented in The Mythical Man Month (by Frederick P. Brooks) were always right in every situation I've seen so far. Designers, Engineers, software developers and those who manage them should be required to read this book every few years. There is no silver bullet, adding manpower to a late project usually makes it later, and all the rest need to be understood by all involved or you will be reading "Death March" by Edwar

No, because the underlying issue is that getting new people up to speed kills the productivity of the current people, plus communication overhead goes up.

If you have a competition task, having 20 people available to work on it better than having 2. You can have 10 groups of two work independently and use the thing that ends up worming. You could pick the best 2 at the specific area the previously unknown task is in the domain of. Maybe there ends up being a sub task that is independent enough that a couple

No more off topic than you bringing it up in the first place, and since Im *replying* to the content of your post, it most fucking certainly is on topic - you cannot kill discussion that easily.

The cry of "off topic" is starting to become the Slashdot equivalent of calling someone antisemitic if they dare to criticise Israel...

Right. Because it won't take time to consider findings or debate if they matter. There is no chance that the person will come up with an idea that sounds great, but turns out to be a boondoggle.

So are you saying there are absolutely no situations in which adding people in as a resource produces results? You seem to be taking my comment as an "every situation" one, when I specifically said "There are loads of scenarios where..." and not "In every scenario...".

Are you *that* tied to the doctrines of a fucking book you cannot begin to see that it doesn't hold true for every single scenario out there?

asking one person to build Twitter is an insane demand, adding extra people will only ever help even when the project is terribly late...

No it won't, for $deity's sake. The effort of bringing them up to speed and the coordination/communication overhead can outweigh any useful work the newbies can perform, making it even later. Perhaps you've never been on a project long enough for a horde of developers to swarm in, asking questions every ten minutes and spending most of the nine between breaking stuf

Somebody needs to read The Mythical Man Month. Adding more hackers to a late hacking project just makes it later.

This is not the same situation as described in MMM. They are not adding more random programmers to a team. The outside programmers are already part of the team, and already know their roles, and how to coordinate and communicate with their teammates.

I agree that it isn't the exact same situation. That doesn't mean there isn't a serious productivity hit when you try to coordinate the efforts of more and more people to solve a problem in a short time frame.

Since you just added the "late" part, that last argument is simply bullshit.

It should be pretty damn obvious that when you are to be given a task you don't know much about before hand that a bigger team is going to better. Instead of your team of 3 coders, you have a team of 15 and you just pick the 3 who are best at the domain the task ends up being about. The other 12 go and play video games - how exactly do you think that is going to make things worse?

"Since you just added the "late" part, that last argument is simply bullshit."

You are thinking of your own post. I didn't write The Mythical Man Month, but I assure you the word late is used in the original. That is actually what late means in the book. You have no time to waste because it is already late. When you are in a time crunch you start out late from the get go. The two scenarios are identical.

"It should be pretty damn obvious that when you are to be given a task you don't know much about befo

By that logic, every project, no matter the size and scope, would be fastest to implement by 1 person team. Adding more would just slow things down... Not to mention, a competition project is not late when the extra teammates are added, they are added before the project even starts...

The optimal team size of competent hackers to minimize "wall clock time" while maximizing creativity and quality is almost certainly more than allowed team siz

Assumption: Adding more programmers to a late project always makes it more late.P = Project that is not late with 1 developerQ = P with deadline arbitrarily changed to the pastQprime = Q with another developer added

By the assumption Qprime will be later than Q. Changing a deadline does not change the amount of work to be done, so the time completion of Q is approx the same as P. Therefore GP conclusion that "By that [assumption], every project, no matter the

Lets start by assuming anyone who really believes that " every project, no matter the size and scope, would be fastest to implement by 1 person team" is a moron. It is a 100% safe assumption, and it cuts through all the rest of the bullshit.

You fail a point of logic that most humans do. I wouldn't normally mention it, except that you brought up "ridiculous non sequitur".

Consider an implication A -> B, such as "if it is Tuesday, then I should buy milk". There are actually 3 propositions present:1) it is Tuesday, called the implicant2) I should buy milk, called the implicand3) if it is Tuesday, then I should buy milk, called the implication

Most humans cannot actually distinguish between the 3. If you find a regular person, they won't reali

GP stated that the implicand is false due to the fact that the implicant and the implication is true.

I should have said more clearly "the original poster was saying that the assumption is false due to the fact that the conclusion is false and the implication is true." Would be nice to be able to edit posts.

The idea that you give your labour for free on the off-chance you might get paid is called "working on spec" in the design industry.

Taking part in a hackathon for a good reason that you want to support is one thing, but 30 grand prize money is a bit different - it sounds like someone is using this as a way to crowd source innovative ideas - the ideas that they choose get paid, everyone else gives their time and effort for free. Surely we can think up a better and fairer model than this.

Most of the critical comments on the article do not understand the issue. Typical hackathorn is meant to build and demo a solution for a problem in a short time (folks comment about 'hacking', seriously do you know what hackathorn is about?). The problem is that the 'idea' is self identified - you pick your problem. If it is more run like a programming contest where participants do not know what the problem is ahead of time, and presented then it'll be more meaningful.