While some people think "building the software" is the goal, I don't think it is.
In my opinion, the real underlying goal is to get people out of their normal environment for a day or weekend, make everyone think differently, prioritize everything, and build connections within the local community. There are very few non-purely-social events that cross programming languages, tech communities, and geographies. Hackathons serve that purpose nicely.
When I close out a Hackathon, I always ask "who lives in this city or within 10 miles of here?" Nearly everyone raises their hand. Then I tell them:
"Regardless of how these demos go, you met a bunch of people who live, work, and make things happen right here in your area. While we'll see what you did today, I'm more interested in what you do going forward. There's no reason these relationships have to die tonight."
Disclosure:
* I'm a Developer Evangelist at Twilio and run, assist, etc Hackathons, Hackdays, etc all over the place.. the most recent was an API Hackday here in Austin yesterday. And I basically said the above.
* My coworking space - HubAustin - launched from Startup Weekend a year ago and after four months of operation, we're 2/3 of the way to being profitable.
I disagree. Hackathons are sprints, and just like have the occasional sprint workout can be a great way to augment your distance running routine, hackathons can be great for augmenting your software development routine.
Here are some reasons why I like taking part in a hackathon event (assuming the goal is to produce some sort of web application):
- Tradeoffs are easy. You have no time for bells or whistles. You consider a basic feature list and start working. If a feature starts to take too long to implement it, you just axe it. You probably end up with something that doesn't have many bells and whistles, but the key distinction is you end up with something. I can't tell you had some many side projects I've worked on had some painfully implemented bell that was pretty cool, but was pointless because I never got any core functionality working.
- All you can do is use what you know. In one hackathon group I was in, I was the guy who ended up knowing the most sysadmin/web server stuff, and the guy who knew the most HTML/CSS/JS. So I basically did my best to manage through installing/configuring everything at the server software level, and then mucked around with some CSS templates trying to shoehorn it around my team's application code. I spent the whole time out of my comfort zone, on two very disparate pieces, and it was great. Here was an environment that required me to do nothing else but pick up those technical skills, in a very focused time period, with tangible results if I did. Much more effective than all those times I'd think, "hmm maybe I'll play around with jQuery more" and never did.
To go back to the running analogy, good software development is like running a marathon. It takes time and discipline, not preparing effectively usually means you'll end up going slower or being injured, and it's all about a steady incremental process that builds up into something great. But sometimes it just feels good to toss out your planned 20 mile run for the day, and just run out your front door and sprint around the block as hard as you can for 10 minutes, pushing yourself in a different way and learning something about your skills or capabilities that you never would otherwise.
Ok, Hackathons are good for engineer development. They still suck for software development.
And Hackathons are very distinct from software sprints. The later being the business end of a lot of design, architecting and planning with clear goals.
as a regular long run runner and coder, I totally agree with you. For training, not only building base is important, if you wanna achieve a good pace during marathon, running fast like a blast is part of it. More detailed, we basically have 4 phases for training.
1)acclimatizing phase,
2)building-up phase,
3)overall preparation phase, and
4)special preparation phase.
Hacktons are more like phase 4, not so accurate analogy,but the spirit is the same. Digging deep, changing the routine, a big improvement is coming.
Hackathons are the opposite of "how marketing people think software is made". They are the essence of the process of development with the decoration removed.
Dave must not have been to a good hackathon. I've personally been involved in hackatons where we created what went on to become a commercial product in under a day. The code written during the hackathon may not have been part of the final product, but the creation of the product (what it is, what it does, even much of how it looks) was the result of the hackathon.
I have the diametrically opposite view of Dave in this case - hackathons are exactly the tool needed to obviate the need for months of wrangling with "marketing people". Instead you can go directly to a tangible product that can be touched, tested, and discussed in a meaningful instead of abstract way.
I completely agree with this perspective, and think it goes beyond putting marketers in their place to also building pretty deep trust with your future market. The idea I took to NYC EDU Startup Weekend (not exactly a hackathon but often similar outputs) sounded attractive for lots of teachers I pitched it to, but ultimately they were skeptical it could be done.
By using Startup Weekend to create a MVP, we were able to switch the discussion from "What if we could..." to "We've built the product. What do you think?" Before we had even incorporated, teachers and administrators who saw the before and after could rest assured we could implement on our vision and continue to iterate on it.
The point of hackathons is also the reason why this quote:
there will never be a Julia Child of software
rings false. Julia Child would cook stuff in front of you on TV so that you could watch how a real cook uses her tools, and hear the cook talk a bit about how she approaches her work.
Obviously the point isn't to taste the food - it's on TV. And obviously the TV show barely scratches the surface of Julia's work: It took her years of practice, apprenticeship with knowledgeable teachers, hundreds of tests of recipes, and so forth. But just because watching Julia can never be the same as being a chef doesn't mean her shows aren't useful.
The point of a hackathon is to get an up-close look at other people in your craft using their most familiar industrial-strength tools and techniques to build something a bit bigger than an academic example. Just shoulder-surfing a programmer using their tools well can be inspiring: Look at what DHH did for Textmate.
Starting in 2007 we started holding Haskell hackathons twice a year.
They have been absolutely vital for building team cohesion in the sprawling open source efforts, and consistently produce good plans for the work that happens after we leave the event. Project launches also happen at these gatherings.
You just have to make sure everyone is engaged, knows each other, and what they're working on. Plan ahead, and arrive with code.
I've been to an OpenBSD hackathon (which has been doing them since 1999) and I think those and the Haskell hackathons differ from many of these new events that people are calling hackathons.
For OpenBSD, the developers are all working as a team on a central project, but usually have sub-projects or tasks related to OpenBSD that they've been working on independently prior to the event. They bring their code to work on or debug, they meet new developers that are normally scattered around the world, test code on different machines, discuss new projects, and socialize (which usually brings out more ideas). Most of the time, those ideas aren't finished at the end of the event, but they've been given some direction and help or have been inspired to start on something new.
The hackathons that Winer is writing about are basically just competitions to see who can throw something together in 24 hours or however long the event is. The ones I've seen put on by Facebook and Twilio seem like nothing more than marketing for their own products, and the developers get some marketing for themselves by winning the competitions.
Although I've never participated in a hackathon, and it's not something I'm particularly interested in, I can completely see the value in them.
It's like a jam session for musicians. It's a way to immerse yourself in the art of creating. 99% of all jam sessions are probably crap, but maybe, just maybe, you'll get that one killer riff that will be the basis of your next hit song.
In the same way, yes, I'm pretty sure that there won't be any Angry Bird 2.0's coming out of a hackathon, but maybe the beginnings of an idea that could lead to the next great app will be born from one.
Hackathons are not the nonsense in this piece, the author's assumption that hackathon projects are expected to be actual business-ready products, that's the nonsense. The author is really shooting himself in the foot and missing the point of hackathons: they are about experimentation and practice.
> However, to make good software, requires lots of thought, trial and error, evaluation, iteration, trying the ideas out on other users, learning, thinking, more trial and error, and on and on.
The whole point of a hackathon is practicing and experimenting with some of those or other aspects of software development in an environment where the quality of the product isn't that important. The product doesn't have "to be any good" for it to be a successful hackathon project!
One could easily say this support's the author's argument, but it doesn't really evidence that hackathons are nonsense, just that hackathon projects are often not viable business-wise. It's great if they are, but that shouldn't be the point.
Way to set up a ridiculous straw man and then tear it down angrily.
Dave obviously saw something or experienced something that rubbed him the wrong way and then indirected a few too many times to post this nonsense rant. In general hackathons are mostly about programmers and builders having fun. Can marketing people abuse hackathons? Yes. Can marketing people abuse anything? Yes. So just tell us what's really bothering you.
I've done numerous hackathons, and more often than not, I'm disappointed. Yesterday, I participated in the Hacker Olympics "hackathon" in Manhattan. It was absolutely awesome, and somewhat of a unique event. We did silly things like have timed contests on who can assemble a computer the fastest, who gets the most kills in N64 golden eye ... oh ... and some coding too! Most of the programming challenges were easy but with tight timelines. This is certainly different from the regular build-an-app-over-a-weekend.
Hackathons aren't meant to be an end-all. It's hard to find a good block of time to do a side project, and I see hackathons as ways of forcing yourself to commit to a project for a short burst of time.
Once you have the groundwork down, you can spend off-hours iteratively improving the products
If you think of hackathons as "making software", then yes, they are nonsense. However, the point of a hackaton is not to build a solid space shuttle control system. It is to quickly churn out a rough sketch of an idea to see if it floats.
If you think of hackatons as idea generation + prototyping events, then all of a sudden they begin to make sense. To stick with the "marketing guys" metaphor, it is Don Draper sparring with Peggy; throwing slogans against the wall and seeing if it sticks and sketching out a plan.
Marketing also has the equivalent of the artful "software making" that the author refers to. It's the labour-heavy generation of artwork, copy, campaigns and so on. But it all starts with the idea.
Hackathons aren't necessarily about shipping. To me, they're about having fun with smart people and maybe (or maybe not) producing a seed for a future shipping software product. In the very worst case scenario, maybe you learn something.
Correct me if I'm wrong, but I haven't seen anyone carrying the "Hackathons are how we build software" banner.
This makes an assumption of the purpose for a hackathon.
Frankly, I've always felt they were a great way for engineers to play product people, get the juices flowing and just try to get something created in a very short amount of time. It can be the equivalent of chicken soup for the engineering soul.
I feel iffy about the film comparison. Because I have studied film formally in a limited context, I can say that there's a lot of planning, communication and collaboration that goes into creating a film, from storyboarding to script writing and doctoring to photography and lighting. And, for someone familiar with the technical details of composing scenes, it is possible to get an understanding of why directors make certain decisions in keeping with a particular style.
I liken programming to that process. There's a fair amount of intention and consideration that goes into composition. With activities, such as pair programming, I argue that is possible to see inside a creator's head.
The benefit of participating in a hackathon is fluidity. There are monolithic projects for which the hackathon was not designed to address. But, at the end of the day, you're a better problem solver by working under the constraints of that kind of environment.
Every person has a different reason to like them or not. I can speak of my case: I work making software in one of the supposed "right ways" on a daily basis. I also like getting together with buddies or new people, and code something exciting that keeps you up until the wee hours with some good food and drinks.
I don't go with the expectations of having a full blown product ready for market release in 24 hours. I certainly know I might learn something new from experimenting or from others, come out with a good prototype, and simply be back on sunday very happy after doing something really fun.
Also don't underestimate some engineers abilities. I've seen guys crank out things in days that would take months to others.
There's a pretty wide range of hackathons, I think. Focused ones where you go start-to-end on a project in 24 or 48 hours are one specific kind. Others are looser, more like dev parties, sort of like gaming LAN parties but not focused on gaming. Some people at an event like SuperHappyDevHouse (http://superhappydevhouse.org) treat it like a coding sprint, but others work more leisurely on long-term side projects, observe what other people are doing, chat about new technologies, find a few people with similar interests and work their way through a tutorial, etc. Lots of ways to approach it as a concept and social setting.
Hackathons are not meant to make production ready code, or even "elegant" code. It is meant to be a hack - a project where decisions are made in favor of speed or elegance.
Hackathons don't generate code ready to ship, but that does not make it nonsense. They are meant to create "sketches" of programs. Sketches are created to convey an idea, and solidify the imagination. They are not the end product themselves or are they the basis for the end product. They are instead an aid. Similarly, whenever I hack and decide that I actually want to pursue the project, I start from scratch. The hack helps refine the design and architecture of the project much more than simply thinking about the project.
disclosure:
I'm an officer of the Hackers@Berkeley club in UC Berkeley. From what I've seen, hackathons are when students really step out of their comfort zones and learn new skills to create innovative projects. Great things have come out of them. Once in a while, those hacks even become the sketches for new startups.
Let me ask you guys a questions, the people who say that Hackathons are great.
Why 24 hours? I find that I need to clear my mind after four or five hours of technical work. If I do that, I get a lot more done.
And my projects come in 4-5 hour chunks of code writing and debugging and everything else that goes into the development process. A bit, but actually very little, requires or even benefits from face to face talking with people. The level of concentration required is blown by just one conversation.
Why not other structures for collaborative development?
I like taking one-hour walks with people I'm working with. Lots reason this works really well.
Demos are good too -- for sure. I could see a meetup where people got together to do one-on-one demos of projects they're currently working on.
I suspect that's what people are really doing btw at hackathons. :-)
If you go back and look at my piece and read the first sentence, you might get an idea of how I approached this.
Dave - I like hackathons. In particular I like the 24 hour constraint. Having to build something in 24 hours (really probably 18 hours), forces me to make decisions, to get to the heart of the problem. Similarly, building something that I know I will only have 2 minutes to demo makes me really focus on what is important. I think the constraints lead to more creativity, just like the Haiku with 17 verses and 3 lines opens the door for whole libraries of verse.
I will say that I, as a physics student, mentally crunched the numbers in my head when I saw a recent Wired article. It said:
Consider the action around Apple’s iOS alone: Since its 2007 debut, 500,000 applications have generated $3 billion for developers. (Android’s 400,000 apps have earned around $100 million.) ... It costs $5,000 to throw an event for 100 participants—a tiny investment considering the payoff if a participant creates a blockbuster app that the company can market... At one hackathon hosted by an upstart open source platform, I watched the winning team hoist an oversize novelty check for $10,000.
If your mental math is good, you'll see those first numbers as 2 x 3000 and 1000 / 4, or $6000 and $250 respectively, in average revenues per app. So, I'd anticipate that Android can't really motivate a hackathon. Also there is some level of bias because really bad ideas might get filtered by the hackathon system, so that perhaps you are automatically in the top 10% of apps and your expected value is instead much higher, $60,000 or so. I doubt that it's quite this high, though.
Do they keep all of the submissions, or just the one that wins the prize? Because it sounded like they had 5-person app teams in this contest, and 100 people could potentially create 20 successful apps. If you got to keep all of them, then that's 20 * $6,000 - $5,000 = $115,000 expected profit before paying the programmers. Giving $10,000 to a single winning team is actually pretty absurdly conservative -- "you do all of the work, we'll keep over 90% of the profits." They can maybe get away with it because we think of ourselves as winners and splitting it up among 5, $2,000 is not bad for two days lost. Then again, assuming that everyone else is as good an app designer as you are, your expected value is only $2,000 / 20, and $100 is actually a pretty pathetic salary for that sort of competition. I mean, I know that you're "doing it for the love" or summat, but still, it sounds like these hackathon hosts have found a way to make programmers work for peanuts.
Unless when they said that the team hoisted "an oversize check", they mean that each member of the team hoisted an oversize check for that same amount. Then the profits are a little closer to 50/50 split (which is still a bit crazy) and the expected profits of your 48 hours of work are $500. Is your overtime rate $10/hour? ;-)
I've never actually been to any hackday where they kept the submissions. The only one I've been to that was really organised by a particular tech company, they obviously tried to get you to use their platform but said you didn't have to (some didn't and it was fine). Is this common?
[+] [-] caseysoftware|14 years ago|reply
In my opinion, the real underlying goal is to get people out of their normal environment for a day or weekend, make everyone think differently, prioritize everything, and build connections within the local community. There are very few non-purely-social events that cross programming languages, tech communities, and geographies. Hackathons serve that purpose nicely.
When I close out a Hackathon, I always ask "who lives in this city or within 10 miles of here?" Nearly everyone raises their hand. Then I tell them: "Regardless of how these demos go, you met a bunch of people who live, work, and make things happen right here in your area. While we'll see what you did today, I'm more interested in what you do going forward. There's no reason these relationships have to die tonight."
Disclosure:
* I'm a Developer Evangelist at Twilio and run, assist, etc Hackathons, Hackdays, etc all over the place.. the most recent was an API Hackday here in Austin yesterday. And I basically said the above.
* My coworking space - HubAustin - launched from Startup Weekend a year ago and after four months of operation, we're 2/3 of the way to being profitable.
[+] [-] crymer11|14 years ago|reply
[+] [-] nhashem|14 years ago|reply
Here are some reasons why I like taking part in a hackathon event (assuming the goal is to produce some sort of web application):
- Tradeoffs are easy. You have no time for bells or whistles. You consider a basic feature list and start working. If a feature starts to take too long to implement it, you just axe it. You probably end up with something that doesn't have many bells and whistles, but the key distinction is you end up with something. I can't tell you had some many side projects I've worked on had some painfully implemented bell that was pretty cool, but was pointless because I never got any core functionality working.
- All you can do is use what you know. In one hackathon group I was in, I was the guy who ended up knowing the most sysadmin/web server stuff, and the guy who knew the most HTML/CSS/JS. So I basically did my best to manage through installing/configuring everything at the server software level, and then mucked around with some CSS templates trying to shoehorn it around my team's application code. I spent the whole time out of my comfort zone, on two very disparate pieces, and it was great. Here was an environment that required me to do nothing else but pick up those technical skills, in a very focused time period, with tangible results if I did. Much more effective than all those times I'd think, "hmm maybe I'll play around with jQuery more" and never did.
To go back to the running analogy, good software development is like running a marathon. It takes time and discipline, not preparing effectively usually means you'll end up going slower or being injured, and it's all about a steady incremental process that builds up into something great. But sometimes it just feels good to toss out your planned 20 mile run for the day, and just run out your front door and sprint around the block as hard as you can for 10 minutes, pushing yourself in a different way and learning something about your skills or capabilities that you never would otherwise.
[+] [-] njharman|14 years ago|reply
And Hackathons are very distinct from software sprints. The later being the business end of a lot of design, architecting and planning with clear goals.
[+] [-] Alind|14 years ago|reply
[+] [-] tworats|14 years ago|reply
Dave must not have been to a good hackathon. I've personally been involved in hackatons where we created what went on to become a commercial product in under a day. The code written during the hackathon may not have been part of the final product, but the creation of the product (what it is, what it does, even much of how it looks) was the result of the hackathon.
I have the diametrically opposite view of Dave in this case - hackathons are exactly the tool needed to obviate the need for months of wrangling with "marketing people". Instead you can go directly to a tangible product that can be touched, tested, and discussed in a meaningful instead of abstract way.
[+] [-] aliya_bhatia|14 years ago|reply
By using Startup Weekend to create a MVP, we were able to switch the discussion from "What if we could..." to "We've built the product. What do you think?" Before we had even incorporated, teachers and administrators who saw the before and after could rest assured we could implement on our vision and continue to iterate on it.
[+] [-] mechanical_fish|14 years ago|reply
there will never be a Julia Child of software
rings false. Julia Child would cook stuff in front of you on TV so that you could watch how a real cook uses her tools, and hear the cook talk a bit about how she approaches her work.
Obviously the point isn't to taste the food - it's on TV. And obviously the TV show barely scratches the surface of Julia's work: It took her years of practice, apprenticeship with knowledgeable teachers, hundreds of tests of recipes, and so forth. But just because watching Julia can never be the same as being a chef doesn't mean her shows aren't useful.
The point of a hackathon is to get an up-close look at other people in your craft using their most familiar industrial-strength tools and techniques to build something a bit bigger than an academic example. Just shoulder-surfing a programmer using their tools well can be inspiring: Look at what DHH did for Textmate.
[+] [-] thebigshane|14 years ago|reply
[1]: http://www.youtube.com/watch?v=ZV-AFnCkRLY Making Metagun
[2]: http://www.youtube.com/watch?v=MhQ70O1MiXc Making MiniCraft
[3]: http://notch.tumblr.com/
[+] [-] aspir|14 years ago|reply
[+] [-] dons|14 years ago|reply
They have been absolutely vital for building team cohesion in the sprawling open source efforts, and consistently produce good plans for the work that happens after we leave the event. Project launches also happen at these gatherings.
You just have to make sure everyone is engaged, knows each other, and what they're working on. Plan ahead, and arrive with code.
[+] [-] there|14 years ago|reply
For OpenBSD, the developers are all working as a team on a central project, but usually have sub-projects or tasks related to OpenBSD that they've been working on independently prior to the event. They bring their code to work on or debug, they meet new developers that are normally scattered around the world, test code on different machines, discuss new projects, and socialize (which usually brings out more ideas). Most of the time, those ideas aren't finished at the end of the event, but they've been given some direction and help or have been inspired to start on something new.
The hackathons that Winer is writing about are basically just competitions to see who can throw something together in 24 hours or however long the event is. The ones I've seen put on by Facebook and Twilio seem like nothing more than marketing for their own products, and the developers get some marketing for themselves by winning the competitions.
[+] [-] steve8918|14 years ago|reply
It's like a jam session for musicians. It's a way to immerse yourself in the art of creating. 99% of all jam sessions are probably crap, but maybe, just maybe, you'll get that one killer riff that will be the basis of your next hit song.
In the same way, yes, I'm pretty sure that there won't be any Angry Bird 2.0's coming out of a hackathon, but maybe the beginnings of an idea that could lead to the next great app will be born from one.
[+] [-] mvzink|14 years ago|reply
> However, to make good software, requires lots of thought, trial and error, evaluation, iteration, trying the ideas out on other users, learning, thinking, more trial and error, and on and on.
The whole point of a hackathon is practicing and experimenting with some of those or other aspects of software development in an environment where the quality of the product isn't that important. The product doesn't have "to be any good" for it to be a successful hackathon project!
The ill-recieved Facebook timeline comes to mind:
https://www.facebook.com/notes/facebook-engineering/building...
One could easily say this support's the author's argument, but it doesn't really evidence that hackathons are nonsense, just that hackathon projects are often not viable business-wise. It's great if they are, but that shouldn't be the point.
[+] [-] davewiner|14 years ago|reply
My feet are just fine, btw. :-)
[+] [-] dasil003|14 years ago|reply
Dave obviously saw something or experienced something that rubbed him the wrong way and then indirected a few too many times to post this nonsense rant. In general hackathons are mostly about programmers and builders having fun. Can marketing people abuse hackathons? Yes. Can marketing people abuse anything? Yes. So just tell us what's really bothering you.
[+] [-] iqster|14 years ago|reply
[+] [-] veyron|14 years ago|reply
Once you have the groundwork down, you can spend off-hours iteratively improving the products
[+] [-] micheljansen|14 years ago|reply
If you think of hackatons as idea generation + prototyping events, then all of a sudden they begin to make sense. To stick with the "marketing guys" metaphor, it is Don Draper sparring with Peggy; throwing slogans against the wall and seeing if it sticks and sketching out a plan.
Marketing also has the equivalent of the artful "software making" that the author refers to. It's the labour-heavy generation of artwork, copy, campaigns and so on. But it all starts with the idea.
[+] [-] rsobers|14 years ago|reply
Correct me if I'm wrong, but I haven't seen anyone carrying the "Hackathons are how we build software" banner.
[+] [-] jroseattle|14 years ago|reply
Frankly, I've always felt they were a great way for engineers to play product people, get the juices flowing and just try to get something created in a very short amount of time. It can be the equivalent of chicken soup for the engineering soul.
[+] [-] candre717|14 years ago|reply
I liken programming to that process. There's a fair amount of intention and consideration that goes into composition. With activities, such as pair programming, I argue that is possible to see inside a creator's head.
The benefit of participating in a hackathon is fluidity. There are monolithic projects for which the hackathon was not designed to address. But, at the end of the day, you're a better problem solver by working under the constraints of that kind of environment.
[+] [-] checoivan|14 years ago|reply
I don't go with the expectations of having a full blown product ready for market release in 24 hours. I certainly know I might learn something new from experimenting or from others, come out with a good prototype, and simply be back on sunday very happy after doing something really fun.
Also don't underestimate some engineers abilities. I've seen guys crank out things in days that would take months to others.
[+] [-] grizzlylazer|14 years ago|reply
[+] [-] _delirium|14 years ago|reply
[+] [-] geraldfong|14 years ago|reply
Hackathons don't generate code ready to ship, but that does not make it nonsense. They are meant to create "sketches" of programs. Sketches are created to convey an idea, and solidify the imagination. They are not the end product themselves or are they the basis for the end product. They are instead an aid. Similarly, whenever I hack and decide that I actually want to pursue the project, I start from scratch. The hack helps refine the design and architecture of the project much more than simply thinking about the project.
disclosure: I'm an officer of the Hackers@Berkeley club in UC Berkeley. From what I've seen, hackathons are when students really step out of their comfort zones and learn new skills to create innovative projects. Great things have come out of them. Once in a while, those hacks even become the sketches for new startups.
[+] [-] davewiner|14 years ago|reply
Why 24 hours? I find that I need to clear my mind after four or five hours of technical work. If I do that, I get a lot more done.
And my projects come in 4-5 hour chunks of code writing and debugging and everything else that goes into the development process. A bit, but actually very little, requires or even benefits from face to face talking with people. The level of concentration required is blown by just one conversation.
Why not other structures for collaborative development?
I like taking one-hour walks with people I'm working with. Lots reason this works really well.
Demos are good too -- for sure. I could see a meetup where people got together to do one-on-one demos of projects they're currently working on.
I suspect that's what people are really doing btw at hackathons. :-)
If you go back and look at my piece and read the first sentence, you might get an idea of how I approached this.
It was just a blog post, btw, not a manifesto!
People here are reading way too much into it.
[+] [-] plamere|14 years ago|reply
Some more of my thoughts on hackathons here:
http://musicmachinery.com/2012/02/20/hackathons-are-not-nons...
[+] [-] prakashk|14 years ago|reply
[+] [-] cdixon|14 years ago|reply
[+] [-] drostie|14 years ago|reply
Consider the action around Apple’s iOS alone: Since its 2007 debut, 500,000 applications have generated $3 billion for developers. (Android’s 400,000 apps have earned around $100 million.) ... It costs $5,000 to throw an event for 100 participants—a tiny investment considering the payoff if a participant creates a blockbuster app that the company can market... At one hackathon hosted by an upstart open source platform, I watched the winning team hoist an oversize novelty check for $10,000.
http://www.wired.com/magazine/2012/02/ff_hackathons/
If your mental math is good, you'll see those first numbers as 2 x 3000 and 1000 / 4, or $6000 and $250 respectively, in average revenues per app. So, I'd anticipate that Android can't really motivate a hackathon. Also there is some level of bias because really bad ideas might get filtered by the hackathon system, so that perhaps you are automatically in the top 10% of apps and your expected value is instead much higher, $60,000 or so. I doubt that it's quite this high, though.
Do they keep all of the submissions, or just the one that wins the prize? Because it sounded like they had 5-person app teams in this contest, and 100 people could potentially create 20 successful apps. If you got to keep all of them, then that's 20 * $6,000 - $5,000 = $115,000 expected profit before paying the programmers. Giving $10,000 to a single winning team is actually pretty absurdly conservative -- "you do all of the work, we'll keep over 90% of the profits." They can maybe get away with it because we think of ourselves as winners and splitting it up among 5, $2,000 is not bad for two days lost. Then again, assuming that everyone else is as good an app designer as you are, your expected value is only $2,000 / 20, and $100 is actually a pretty pathetic salary for that sort of competition. I mean, I know that you're "doing it for the love" or summat, but still, it sounds like these hackathon hosts have found a way to make programmers work for peanuts.
Unless when they said that the team hoisted "an oversize check", they mean that each member of the team hoisted an oversize check for that same amount. Then the profits are a little closer to 50/50 split (which is still a bit crazy) and the expected profits of your 48 hours of work are $500. Is your overtime rate $10/hour? ;-)
[+] [-] jarofgreen|14 years ago|reply
I've never actually been to any hackday where they kept the submissions. The only one I've been to that was really organised by a particular tech company, they obviously tried to get you to use their platform but said you didn't have to (some didn't and it was fine). Is this common?
[+] [-] zbowling|14 years ago|reply
PS. I'm the Zac Bowling from that article.