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.
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.
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.
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.
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.
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.
[1]: http://www.youtube.com/watch?v=ZV-AFnCkRLY Making Metagun
[2]: http://www.youtube.com/watch?v=MhQ70O1MiXc Making MiniCraft
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.
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.
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.
> 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.
My feet are just fine, btw. :-)
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.
Once you have the groundwork down, you can spend off-hours iteratively improving the products
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.
Correct me if I'm wrong, but I haven't seen anyone carrying the "Hackathons are how we build software" banner.
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 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 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.
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.
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.
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.
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.
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? ;-)
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?
PS. I'm the Zac Bowling from that article.
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.
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.
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 :)
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.
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.
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:)
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.
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.
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.
... for trying to achieve /what/ excactly?
Nuance. I know. Nuance is overrated. Especially on the interwebs. Sorry about that.