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.

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.

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.

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!

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.

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.

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.

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.

    > People here are reading way too much into it.

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? ;-)

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.

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 :)

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.

This is written by a man who thinks each and every paragraph he writes is worth linking to.

> 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?

You are right. It's like a mini-MVP off.

PS. I'm the Zac Bowling from that article.