Hackathons are nonsense(scripting.com)
scripting.com
Hackathons are nonsense
http://scripting.com/stories/2012/02/19/hackathonsAreNonsense.html
39 comments
Exactly. I landed my current job solely through relationships created during a recent local hackathon and the exposure it afforded me.
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.
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.
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 more like fartleks, no?
yeah, right. usually I call it interval. But you are right. this is the right term.
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.
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.
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.
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.
Watching `notch` live-code is also very popular.
[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/
[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/
To reiterate your point, Ryan Bates of RailsCasts.com could be considered a Rails "Julia Child."
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.
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.
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.
The Haskell ones were modeled on the OpenBSD ones, by the way. (I used to maintain the Haskell ecosystem in ports).
I've never been to an OpenBSD hackathon, but I've heard good things about them from others. They get a lot done on ports and various projects (PF, OpenSSH, etc) during the hackathons. It seems to be a big part of their culture.
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.
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!
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.
> 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.
Where did you get the idea that that was my assumption?
My feet are just fine, btw. :-)
My feet are just fine, btw. :-)
Indeed, you don't explicitly make that assumption. It's just the only one I could think of that would make any sense of your leap from "quality software takes a long time to make" to "hackathons are nonsense". If you won't warrant that assumption, then I don't know what the point of the article is.
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.
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
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.
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.
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.
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.
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.
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.
Not true. The purpose of hackathons is never to make good software - it's about prototyping, testing ideas and going outside your comfort zone.
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.
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.
It was just a blog post, btw, not a manifesto!
People here are reading way too much into it.
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.
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.
Some more of my thoughts on hackathons here:
http://musicmachinery.com/2012/02/20/hackathons-are-not-nons...
Some more of my thoughts on hackathons here:
http://musicmachinery.com/2012/02/20/hackathons-are-not-nons...
> People here are reading way too much into it.
Okay I hate to tell you this -- but you're reading too much into my telling you not to read too much into the other thing. :-)
Who said I didn't expect them to do it!
Of course they're going to do it.
And of course I'm going to say they're doing it.
And of course someone is going to ask how can you expect people to not read into it, especially one with such a provocative title?
Conclusion: Life is wonderful!! :-)
No sarcasm, this is fun.
Who said I didn't expect them to do it!
Of course they're going to do it.
And of course I'm going to say they're doing it.
And of course someone is going to ask how can you expect people to not read into it, especially one with such a provocative title?
Conclusion: Life is wonderful!! :-)
No sarcasm, this is fun.
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.
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? ;-)
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? ;-)
> Do they keep all of the submissions
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?
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?
Just to clarify, I've seen lots of hackdays organised by platform providers so they let you keep the end result and they still benefited because their platform got traction/apps/focus/whatever but never one where they actually take your work off you.
Thanks for that, it makes the original statement "...if a participant creates a blockbuster app that the company can market" much more clear: it's not a marketing gimmick for the app but some marketing gimmick for a platform for designing apps, which the company happens to be selling.
At the same time, it confuses me even more, because I'm surprised that this works as a marketing tactic. ^_^;;
At the same time, it confuses me even more, because I'm surprised that this works as a marketing tactic. ^_^;;
You are right. It's like a mini-MVP off.
PS. I'm the Zac Bowling from that article.
PS. I'm the Zac Bowling from that article.
I thought hackathons were just meant to be promotional in nature. Sure they can't straight up admit it isn't about the code (as that's where they get the promotion from) but every hackathon I've looked at has been more about the API, the sponsor(s) or the technology than actually getting anything concrete out of the process.
We just had a very successful hackathon where I work. About 10 separate teams coded basically overnight and the results I think surprised everybody. There was something about the energy and, well, slight insanity of staying up all night just to see if we could deliver a full product in under 20 hours...there was definitely something to it. The demo the next morning, where all the teams showed what they had done was pretty dang impressive. A few of the delivered results will likely become real products.
So from my perspective, the energy and "field day" attitude of a hackathon creates an urgency and focus that's feels like the early days of a startup, where sheer adrenaline and excitement creates more productive mental state and team effort I think. It's a thing, I tell you.
So from my perspective, the energy and "field day" attitude of a hackathon creates an urgency and focus that's feels like the early days of a startup, where sheer adrenaline and excitement creates more productive mental state and team effort I think. It's a thing, I tell you.
> slight insanity of staying up all night
I may be weird, but I find that sleep deprivation is sometimes helpful.
After 20 years of development I have put my fingers in every mousetrap there is. So I can be overcautious.
The critical voices seem to be silenced first when I'm sleep deprived. Granted I'm probably not at my best as a developer either, so I wish I could figure out some way to enter that state at will, and re-enter my critical mode when I need to test or debug.
I may be weird, but I find that sleep deprivation is sometimes helpful.
After 20 years of development I have put my fingers in every mousetrap there is. So I can be overcautious.
The critical voices seem to be silenced first when I'm sleep deprived. Granted I'm probably not at my best as a developer either, so I wish I could figure out some way to enter that state at will, and re-enter my critical mode when I need to test or debug.
This is exactly what the OP warned against. When the marketing people find out about all these "near products" you guys churned out in a day, say goodbye to sane development schedule.
Seems like it's similar to physically going to conferences and focusing on some topic 100%, instead of just watching the same video streams and presentations at home.
I don't thing hackathons are for building a software that will be shipping right away. I think the objective of hackatons is to do quick experimentations, be as creative as you can and see if something interesting and new comes out of it in a few hours.
If something doesn't exist you don't even know if it's possible to accomplish. In a normal working schedule it would be very difficult for you to get time to work on something nobody-knows-if-it-will-work-or-not. Besides, your boss will not be very happy if you 'waste' time on that.
So the goal of hackatons, in my opinion, is to spend some time to travel on uncharted seas...you may find nothing...you may discover America. But you have only discovered it, not conquered it...that will take more time :)
If something doesn't exist you don't even know if it's possible to accomplish. In a normal working schedule it would be very difficult for you to get time to work on something nobody-knows-if-it-will-work-or-not. Besides, your boss will not be very happy if you 'waste' time on that.
So the goal of hackatons, in my opinion, is to spend some time to travel on uncharted seas...you may find nothing...you may discover America. But you have only discovered it, not conquered it...that will take more time :)
Hackathons aren't always about just making good software. For me, if you're at a hackathon and not pushing your limits, then you're not really getting into the spirit of the entire affair. I have good memories of one in particular where I submitted the awful, horrendous results of me trying to learn computer graphics in just twelve hours. I could have just sat down and made yet another CRUD app, but instead I learned about Three.js, and now that I got over the initial hurdle of just sitting down and tinkering with it, I've been more inclined to just play with the framework.
It's like the proverbial journey that begins with a single step. Sometimes all you need is that first step to force you to go try something out, immediately.
It's like the proverbial journey that begins with a single step. Sometimes all you need is that first step to force you to go try something out, immediately.
This is written by a man who thinks each and every paragraph he writes is worth linking to.
Hackathons have an "inspirational" value. By forcing an artificial constraint they demonstrate to participants how much they can do in a single determined sprint.
There may be little further connection to what it takes to make good software (let alone a good business), but there is value in realizing that something of utility can be built under time and money constraints.
It is kind of silly, though, how many of those are popping up, and how they are turning into competitive formats. And I'm sure some people misunderstand the point of the idea. So what? That's true for many things and it doesn't make them worthless on its own.
There may be little further connection to what it takes to make good software (let alone a good business), but there is value in realizing that something of utility can be built under time and money constraints.
It is kind of silly, though, how many of those are popping up, and how they are turning into competitive formats. And I'm sure some people misunderstand the point of the idea. So what? That's true for many things and it doesn't make them worthless on its own.
This software analogy is more flawed than most. Both of the other things have timed contests exactly like a hackathon. Cooking has Iron Chef and all of those variants, and film has their own 24-hour (or X-hour) contests where teams make a film along a certain theme. In all cases, it's not so much about the finished product as it is about the process, and a way to measure the abilities of the contestants. And if the challenge is good enough, a way to grow in that field.
As well, I'm pretty sure a lot of the "hacks" you see come out of hackathons are actually projects that were well underway before the event.
That is a common type of hackathon, and usually the more enjoyable. Going from zero to something cool is fine, but joining up with an open source project for a few days and fixing problems and adding features can be a lot more rewarding, and a lot more useful.
This is commonly known as cheating. I'm fairly confident it doesn't happen very much.
>This is commonly known as cheating
I agree, I don't like to bring in existing code. Once I saw a friend of mine do (very obviously), still the jury was so impressed that they awarded him $25k in advertising for his bootstrapped startup. That moment I wished I had done the same thing:)
I agree, I don't like to bring in existing code. Once I saw a friend of mine do (very obviously), still the jury was so impressed that they awarded him $25k in advertising for his bootstrapped startup. That moment I wished I had done the same thing:)
Surely, it's hard to draw the line, what if you've written a similar thing before? or spent weeks coding in your head before hand?
Hackathons are good at creating MVPs. To create something more than an MVP, you need to go out and talk with the users and ask them what they want out of the product.
Personally, I attend hackathons because they are fun. It feels great to be surrounded by others who are motivated to do really cool things. Not to mention we are usually all armed with energy drinks and endless amounts of food.
Personally, I attend hackathons because they are fun. It feels great to be surrounded by others who are motivated to do really cool things. Not to mention we are usually all armed with energy drinks and endless amounts of food.
For me it's also not about "building software" it's a mix of things like trying out a new technology. Creating a proof of concept that I can work later on (maybe for years ;-) But one of the most important things: Work with other people. Feel their workflow. At Hackathons there is lot of intense energy and in the end it's about us and not any marketing guys.
Just having finished hosting a hackathon ( http://blog.blrdroid.org/?p=526) I totally disagree.
Hackathons are more about fun and in the process if something comes out of it , its a bonus.
If you are going into a hackathon with the goal of getting something out , your approach is wrong.
Hackathons are more about fun and in the process if something comes out of it , its a bonus.
If you are going into a hackathon with the goal of getting something out , your approach is wrong.
I agree, although no truly great product is made in one night, hackathons can lay the foundations or the idea for something great to be elaborated on. Very few times do people get together, outside work time to build something, just for the sake of building something. Its important to give this time.
I think this is spot on, I doubt the actual code written at the event gets much use afterwards but the connections made and the teams formed can go a long way.
Our startup (www.stylegauge.com) began at London Startup Weekend 2011 and is now a few weeks away from launching trials. The codebase has changed completely and the ideas evolved a lot but it was the hackathon which got it going.
Our startup (www.stylegauge.com) began at London Startup Weekend 2011 and is now a few weeks away from launching trials. The codebase has changed completely and the ideas evolved a lot but it was the hackathon which got it going.
I think that Hackathons are invaluable for meeting people you are going to work with long term. However, I agree it's rare that you will do something significant during an 8/10/12 hour hackathon.
I definitely think good software can be made in 24 hours but sure, if you're trying to build Skynet in a Hackathon it will probably not be very good.
"Hackathons are nonsense" ...
... for trying to achieve /what/ excactly?
Nuance. I know. Nuance is overrated. Especially on the interwebs. Sorry about that.
... for trying to achieve /what/ excactly?
Nuance. I know. Nuance is overrated. Especially on the interwebs. Sorry about that.
Hackathons do make a lot of sense for PR and HR.
Hackathons are primarily a way for companies to more easily identify good developer hire candidates, and likewise, for developers to make new connections and promote themselves. Everything else is a shared lie and/or a distand second in importance.
This might be true for some of them. But it is not for those, which I attended.
Looks like Dave Winer got full of shit... So sad.
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.