Hackdays - How Much Preparation is Acceptable?
cadbury cadburyhack hackathon hackday hacking NaBloPoMo · 9 comments · 700 words · read ~362 times.
I don't watch much TV. During the last episode of The Apprentice, my Twitter-feed was suddenly flooded with people talking about Nick Holzherr's app "Whisk".
Apparently it was some kind of recipe / shopping / mash up thing called Whisk. Sounded good. Sounded familiar. Then I remembered this from CadburyHack
Best use of APIs at #CadburyHack - Whisk team for their recipes mashup pic.x.com/e9ztkuy3
Now, I didn't see either the TV show or the final presentation at the Hack Day. For all I know, they're two completely separate apps. Indeed, quoth The Hodge
That last link points at http://www.foodient.com/ - a site co-founded by Nick Holzherr.
So, at the very least, the app was built off a back end that the team were intimately familiar with having created it.
I asked Nick, about it, and he cleared things up.
Now, the CadburyHack event had a top prize of £10,000. That's a hell of an incentive.
I wouldn't have been surprised if people had pre-built components, or even developed entire apps - I did some prep for my app.
But it just doesn't feel... sporting. Building a hack on top of your own product seems to me to be against the spirit of a hackday. But perhaps I'm just bitter that I didn't win!
How Much Is Too Much?
I suppose that the Platonic Ideal of a hackday is that one attends as a blank slate, sees the technology on offer, form a team with people you've never met, hack all through the night, and produce something groundbreaking.
That never happens. Most people have at least half an idea of what they want to build, they team up with their friends, re-use components they've build previously, and hack with an eye on the prize categories. "Doesn't seem to be much competition for best use of Erlang!"
Take, for example. my Android Theremin. I can honestly say that I didn't write a single line of code - or do any research on the Android sound APIs - until the second morning of the hackday. I didn't reuse any code that I'd previously written either. However, the idea had been buzzing around in my head for a month or so. I'd watch Theremin videos, and looked at the science behind them just to keep the idea percolating.
Is that too much prep?
My CadburyHack was a different affair:
The Twitter and FourSquare code were originally written by me for other projects - so I reused them (Yay for Object Oriented Programming!). I'd used XPath before to scrape a site - so adapting it for Cadbury's wasn't hard. The barcode scanning integration was ripped out of an existing project. Even the template from the page and the font embedding code was recycled.
Is there a difference between code you've previously written and code you've plundered from some Open Source project? Is there a difference between your prior knowledge of coding, and what you pick up on the day? Is there a difference between building on an API you've used a hundred times, and one you've only just seen?
Hackdays are fun. The prizes are a nice bonus. But, ultimately it's about showing off and proving yourself within a limited time in front of a crowd. If you "cheat" you're really only cheating yourself out of the pride of hacking something original.
Still, whether the prize is a new phone, or ten grand, then incentive to bend the spirit of a hackday is strong.
Or am I just making a fuss over nothing?
Introducing Corkr at #NHTG14
You're not making a fuss about anything. I think I mostly agree with the sentiment that it's weird. I think the mayor thing to recognise here is that there are different format events running as HackDays. Depending on the format, and the intentions of the participants, different levels of preparations are acceptable.
My big question actually is: if a HackDay is about presenting a product with a potential business model to a jury, then why bother with the 24hour overnight period? Why not just have people work on it for months and present it on a Sunday?
Weird, right?
Very true. I feel like some hackdays are really an "audition" whereby a company can see if it likes you / your team.
I just realised an interesting way to think about this. I think the difference between those 2 kinds of Hack Days is between "technology inovation" and "business inovation". I'm thinking that in the latter one the "business inovation" might still constitute a hack from a business perspective, given that not everything has been thought out yet and formalised.
I have been considering blogging about this subject from a different angle for a while.
The humble HackDay was about creating something quickly by, well, hacking code together and then showing it off. Sometimes the product went live, sometimes it went further, mostly it died, but we got to create something, test something, try new things, share knowledge, and learn.
I am not against having some judging and prizes are nice, and even if the prize is a bar of chocolate as recognition from my equals that I have done something good or clever. Such appreciation feels so good to me. What saddens me is that some, mostly management or marketing types, try to big up an event by turning it is to a big competition. This is not what HackDays are about. When at university I did enjoy programming competitions as well but they do not mix well with HackDays in my opinion. It destroys the sharing at the event and turns friends in to enemies. Not to mention that if people are concentrating on winning they will not be focusing on making the best thing they can, but instead what will make them more likely to win.
Personally I don't have a problem with people preparing for a hack day or re-using code. I have used past hacks as a base for new hacks myself, but I always make it clear what I started from and what is new.
I think the solution is to wind back the prizes a little. Have more prizes so you can award them to all who deserve them, but don't think you need a big headline prize.
There is still scope for a programming competition, but let's not call them a hack day as this is bending the definition.
That's a good point. I think that hackdays can work when they're based around a narrowly defined technology or problem space - but when it's a free for all (especially if there are big prizes involved) then it becomes less fun.
For me, there are two types of hackdays...
Competitive and Cooperative -
CharityHack for instance - Big prize, big turnout and big competition, some people (myself included) go to win, we've been accused of cheating at that event and it puts a sour taste on it. Competitive hackdays are different as theres less talking, less fun, a lot more stress and more of a purpose to get the hack finished and presentable,I also find them to be a lot more based on the end presentation, the amount of hackdays I've seen where the people could have built nothing but produced a pretty slide deck is astounding and sort of feels like a wasted weekend to me, We work hard on our presentations but we make sure they at least demo what we've built!
Cooperative hackdays are much more fun, they are there for you to try something new, work with different people and learn something, anyone who has been to LeedsHack knows that there isn't really a massive prize for the weekend (We might have a Nexus 7 or two) but everyone who enters gets a poundshop prize and everyone leaves with a good feeling, our next hackday (http://pibakeoff.leedshack.com) is much of the same, less about the prizes and more about people just getting today and playing with a cool bit of technology.
I don't mind there being two types of hackday, I enjoy them both.. but maybe the competitive hackday needs to be called something different?
In regards to people cheating, We always make sure to have at least two technical judges on hand to look at if things are actually possible in the 24 hours and to do some simple checks to check for pre work, it doesn't always work but it cuts down on the blatant (we added this feature so are submitting the whole app as a hack)
Very good points. I find the "PowerPoint Warriors" an odd concept. I think we've both been at hackdays where a demo turned out to be "we built this org structure, put these policies in place, wrote this mission statement - but produced no code!"
I think of days that promotes those kind of outcomes as innervation days and not hack days.