Why Hackathons Suck (and don’t have to)
Techies love hackathons. What could be better than getting together for an evening, or a weekend, with food, friends, maybe a beer, and using one’s magic powers to create a piece of technology that saves the world?
I exaggerate. Most people don’t think they’ll save the world in a weekend, but sometimes they act as if they believe they can.
As software professionals, when was the last time we went to our bosses and said “No problem. I’ll build that brand new production system for you in 8-16hrs”? Probably never.
Certainly not as often as we’ve freaked-out when the boss came to us with some impossible deadline. “You can’t expect me to build something effective, reliable, great in N-months!” we scream. “Be reasonable!”
So why do we sell the myth of the 2-day app to non-profits and other mission driven organizations?
Maybe we like the buzz of seeing ourselves as heroes able to jump tall-buildings with our nerd super-powers.
Or maybe we just like the pizza.
Either way, there are several problems with the way a typical hackathon model that make it almost impossible for them to succeed. I list some specifics below, but first I can sum up the core issue:
Hackathons just aren’t serious. They are in no way up to the challenge of delivering effective, useful, impactful technology.
A little more detail:
- Understanding the problem. Tough problems are complicated and require complex solutions. When we attend a hackathon, we expect to show up, read a paragraph long problem definition, decide on a solution, and start typing without any research or study.
- Our customers can’t commit to the effort until we do. Hackathons don’t guarantee delivery of useful functioning software. Volunteers who attend don’t commit to finishing a project, just to spending a weekend and maybe some non-committal “follow-up volunteer time.”If we can’t promise results, how can the people we are trying to help commit the time and effort required to shape and adopt some new technology? Most can’t and don’t. So even when we do deliver something, it often arrives at an organization with little (if any) organizational commitment or ability to use it.
- Hackathons can be a burden on our customers. The organizations we want to help are tackling hard problems with very few people and very little money. Helping us prep problems, participating in the hackathon, and trying to politely guide well-meaning (but rarely committed) post-hackathon volunteers takes time.When I was CTO of a non-profit, it seemed so rude to turn down an offer of help. A few times I spent time out of my crazy-busy day to work with nice people who wanted to volunteer (including throwing hackathons). In retrospect, I shouldn’t have—we never received any deliverable that we couldn’t have hacked quicker ourselves.
- Software Technology Takes Time to Build. We’re aren’t painting a community-center rec-room. Software takes time! And half-finished software is useless. What about the occasional project that really only take a couple days of effort? My colleagues at ThoughtWorks like to point to this good piece of pro-bono effort we performed. But even in this case, it wasn’t just a few days of coding. Our efforts included an ongoing commitment to keep the live service operating as long as it was needed.
- Building it right takes sustained, ongoing, engagement. This one should be self explanatory to software professionals, yes?
Most programmers are familiar with Brooks’ Law that 9 women can’t have a baby in one month. When we pretend we can accomplish something in a hackathon or two we it’s like 50 people making baby in 2 days, and then we let it starve.
So should we just give up and enjoy the pizza and socializing without pretending we are saving the world?
No. We can get serious and we can learn from people who have models for successful volunteering.
While writing this blog I decided to call a friend who I thought could help me think through a better approach. He’s a software entrepreneur. He’s also a carpenter and a long time volunteer with Habitat for Humanity.
Habitat accomplishes something pretty amazing. They regularly plan and complete complex, long-duration projects using a mixture of sweat-equity from soon-to-be homeowners, paid experts, and volunteer efforts from both amateurs and skilled professionals.
For those of you who don’t know Habitiat, they build houses—everything from simple single-family homes, to multi-unit urban condo developments.
It would be too long a blog post to go into all the details of how they accomplish this, but here are some key elements that could be used in a successful volunteer software development project.
- Take the task as seriously as you would your own work. You wouldn’t want to live in a house a bunch of yahoos hammered together in a weekend. You wouldn’t want your business or your favorite non-profit running on software a bunch of yahoos hammered together in a few hackathons.
- Commit to delivery. Habitat doesn’t say “we’ll hold a hammerathon once-a-month and see what we get.” They commit to building a finished house.
- Get commitment upfront and engage customers throughout. Habitat home-owners are screened and selected ahead of their building project. They commit, from the beginning, to work for a year or more to build their house. They have skin-in-the-game, and they are going to use that home.
- Continuity and follow-through is a job. Habitat acts as developer, financier, and general contractor on their projects. They have full time (paid) managers on staff that plan projects, recruit volunteers, and see the work through to completion.The minimal equivalent on a software project is a product owner and a project manager to see the work through from conception to delivery.
- Some things you pay for. Habitat is very good at getting trained professionals to donate their services—like architects who contribute plans pro-bono. But sometimes you just need to pay someone. Often these are skilled tradespeople like plumbers and electricians. If we can’t find volunteers with the right skill on a volunteer software project, we need to find a way to pay someone. Perhaps a UI designer or two.
- Volunteer events add energy and attract contributors, but they are a small part of a larger sustained project plan. Habitat works hard to bring volunteers to project sites on a regular basis. Those volunteers have fun and perform valuable work. But these weekend-events are not the only (or even main) source of effort. The events fit into an overall project plan. The short term volunteers, when they show up at a work site, are directed by full time workers both paid and long-term volunteers.THIS is where hackathons can fit in. They can inject energy to a project and attract long-term volunteers. They can be critical components of a larger framework.
If we want to provide real value for the organizations we are looking to help, we need to expand our efforts beyond these fun little events and find ways to create (and pay for) an ongoing sustained project effort.
What if you (or your company, or your hacker-group) can’t can’t commit to an ongoing project?
The Habitat analogy still holds. You don’t have to be Habitat for Humanity to do useful work. You can be a one-weekend volunteer. The key to being a useful one-weekend volunteer is to make sure someone else is seeing the project through and that you are helping them.
So if you can’t commit to following through on a many-month, many year project—and let’s be honest, most of us can’t—you can make sure that your efforts are serving the people who have committed for the long run.
- Ask more from your hackathon sponsors. If you want a company to help out, don’t just ask for a conference room for a weekend. See if they will commit a product owner/project manager to see the project through to the end.This could be by taking one key bit of work that comes out of the hackathon and committing to organizing volunteers for many months to complete it.
- Is that asking too much? There is an easier way. Have your hackathon contribute to a long running humanitarian software project that already has a committed core set of developers and managers. Projects like OpenMRS.If you do this, remember that engaging these organizations does sap some of their effort. So make sure your hackathoners are committed to at least returning enough value to cover the time OpenMRS or OSM will spend helping you organize.
At the end of the day, it’s about caring more about the value we provide, the outcomes more than the pizza and beer and ego-stroking we know we’ll receive.
http://newyork.thecityatlas.org/lifestyle/solutionism-nowhere
http://davidsasaki.name/2012/12/on-hackathons-and-solutionism
The recent articles linked above state, more eloquently than I did, one of my core concerns with hackathons—that they promote a kind of ‘silver-bullet’ uniformed approach to solving a problem. That with the “let’s knock something out in a day” approach leads people to make what is easy, not what is needed, or what can actually solve a problem.
These articles call this approach “solutionism” and point out it’s failures. The name cames from Evgeny Morozov‘s new book, To Save Everything, Click Here: The Folly of Technological Solutionism, which I’ve pre-ordered, but not yet received!
I like the article. I think we have some slight differences on what we think the purpose of a Hack Day is, but I think we both recognise that there’s some issues to be solved.
I wrote up my thoughts after the recent CharityHack here in London on my own blog. It’s mainly written from a developer’s perspective, but I think it highlights a lot of the same issue:
http://cristianobetta.com/blog/2012/11/12/hacks-products-a-discussion-on-responsibility/
Having just finished up a highly successful hackathon this weekend (grgivecamp.org), I couldn’t disagree with you more. At least half of the projects had already deployed by the end of the weekend, and the rest of them have been deployed a few days later.
I think the key to our success was the massive amount of work put in by the organizers in selecting and working with non-profits before the event, to ensure that the projects undertaken were within a reasonable scope of a weekend. Project leaders met with the non-profits a month in advance to gather requirements and were working with them through the month to clarify the project requirements. While it is easy to focus on the actual gathering and coding session, the preparation is what makes or breaks the event.
You mention you were a CTO of a non-profit, which suggests that your organization may have been too large and complex to benefit from such an event. Most of our non-profits were small 2-3 person shops who maybe had an intern if they were lucky. For that size of organization, throwing up a basic WordPress site where they can reach out to their members is huge, and entirely within the scope of a weekends development effort.
Unfortunately this model of shrinking your scope doesn’t provide a way for hackathons to attack larger problems, but it does provide a way to still get great value out of a timeframe that is easier for developers to commit to.
Jeff – thanks for putting this out there and for your years of service developing technology solutions and innovative models of engagement for social good. I appreciate your perspectives and contributions to the field, and I’ve learned a lot from you.
While I agree that hackathons don’t often live up to their potential, I think their potential is huge! My summary: the hackathons I’ve been to seem like a pretty good uses of participants and community partners time towards the goals of delivering effective, useful, impactful technology, and together we can make them better!
I am really encouraged by the work of organizations you are already supporting including RHoK, SocialCoding4Good, and OpenIdeo to use hackathons as a model for creating technology solutions to social problems. I think the points you make about asking more upfront, and finding ways to tie hackathon efforts to larger ongoing projects are great and these partners are actively working to to incorporate these into their models.
I also agree that Habitat’s model has some interesting insights to offer. If you are trying to build houses, hackathons aren’t going to be the best model to reliably get you a structure most people would want to live in, and your points about paying for somethings and follow through are important.
But Habitat and Houses may not be the most applicable model. There are others that can be useful framing for hackathons. For example: KaBoom! uses a Community Builds model for playgrounds that might be more applicable to a one day code sprint. I’ve been a part of some amazing KaBoom! projects that have transformed neighborhoods, and it’s a (mostly) done-in-a-day by volunteers. They do require solid prep work, clear goals, roles and strategy, use of paid experts and hired muscle as necessary, and follow up maintenance and care. But the actual community building days are highly collaborative and engaging events that help build community among volunteers, local residents, beneficiaries and partners. And they result in tangible benefits and transformation for the community.
Building on your thesis, I’d say: “[Most] Hackathons just aren’t serious [enough yet about the social impact they are creating, and are still learning how to scope projects that can be tackled in the short sprint format, staffing them with the right mix of participants, maintaining the successful projects through community partnership and resources, and being disciplined about shutting down the ones that aren't moving forward.]
I like your Habitat analogy – since I donate my time and skills to them on a regular basis. For example, last week they moved to a new location and that meant rebuilding the network from scratch, with the bare minimum of costs. Ok, I got it done, hackathon style – but it would be a mistake to consider it anything else than an ongoing project. I guess this is where most tech volunteering goes wrong – we tend to consider the now and try really hard not to remember that our work is worth little if not maintained and cared for.
I think you make a few good points. If I would share your goals, I would agree with your points. In my opinion your evaluation of the quality of the work hits the mark.
Where I think different is what the involved people in a hackaton really want to achieve.
Lets think about the organizer and her motivation: I don’t think it is about getting code; at least I think it shouldn’t be about getting code. I could believe a valid motivation (besides visibility) could be to receive a bunch of ideas, maybe including a novel one. Another motivation could be to see lots of contributions, look at their coding or other skills and get an idea whom to try hiring. Or maybe planting the idea the company is doing good stuff and one should work here. Or maybe promoting a particular toolset or library or programming language to use.
What could contributors want? There may even be contributors who like to do a donation. However, I can imagine a nearly endless list of other possible motivations:
-Learn a new skill.
-Compare their skill with the skill of other people.
-Check out how other people work.
-Meet new people and evaluate their skill before asking them to become their partners (or trying to hire them)
-Check out whether you feel comfortable with the organizing company before applying for a job.
-Hope to see interesting problems worthy of being attacked.
-Program something different then what they normally program; to some geek that could be one way of relaxation.
Depending on peoples goals, the very same Hackaton could be anything from total waste of time to huge success. This may or may not have anything to do with the quality of the work done.
We’re aren’t painting a community-center rec-room…
I have done this before both through our church and through a charity called Christmas in October and in both cases this left a terrible taste in my mouth.
The Christmas in October job was particularly “slap-dash”, many of the walls were not cleaned before the new paint was layered on. Small pieces of the house were fixed, but we also ran around fixing botched efforts from previous workers, like windows that had been painted shut.
The Church deal was equally disappointing. The place really needed two or three coats and there were lots of pieces to move / tape up / patch and fill. But instead of staging out the process, it was simply an “everyone show up at 9am” event.
The job was completed, but it reeked of amateur and you knew it needed to be re-done in a couple of years. I really hate doing a crummy job, especially when it will fall apart over the long-term.
These two experiences felt the same way for me that the whole “hackathon” experience feels for you. Maybe painting a community rec center isn’t that easy either
I have never been to one of these types of events, I had planned on doing one locally this fall only to discover that it has been scheduled for a time that I cannot attend.
I certainly do not know about the charity hackathons in your area, but it sounds to me like there is a serious issue with expectation at the root of your discussion here. An employer pays you and has a right to expect certain level of performance from the applications developed. Overall, application development does not always HAVE to be at the level expected by your professional employer.
Everything I have ever heard about the local versions of these types of events are that the organizations in question HAVE NOTHING, including NOTHING with which to pay “professionals” like you describe in your Habitat for Humanity analogy. They are pleased to accept applications that serve their very basic business automation needs which CAN be completed in a very short period of time, i.e. a weekend with a few competent developers and a half decent project manager, which is more than they had when they asked for the help.
You don’t need to build a Swiss watch for someone who just wants to know what time it is within a few minutes…
Thanks for the post. Totally understand the frustration when there no commit or delivery of any result. My team is working on a hackathon proposal for a team building event. The leads will provide guidelines to the team and set up some expectations so that hopefully at the end we do get some meaningful results. This isn’t like a true hackathon, so we call it a code fest instead.
I like all the points stated in the post. But it seems to me hackathon is not about to deliver great value during the hackthon or 2. But it`s the way to unite people and let them inspire each other. I maybe wrote a very intricating thing, let me give an example to explain it:
Assume you want to move chemistry. You can surely take it all seriously and work on some real taugh/important tasks in chemistry. Probably good team with a nicely defined goal will do a good contribution. But if we gather a lot of people who are interested to do something valuable(and this is one of the ideas of hackathon) and give them some task to try chemistry together. Some people can be really change their vision, start to burn with some idea. And value will be received later, after the hackathon. When person who saw how great developers did something great was impressed and want to impress others, want to deliver something valuable. So this is one of the points.
I want to stress separately, that I don`t think well thought approach that is bad and hackathons are perfect as they are. I only want to say, that some things are done not to deliver as much value as it`s possible. They are to inspire, they are to put others on rails of delivering in future.
I attended a Hackathon a while ago, and came off with the same feel. Too little time to think about audience and a unique pitch on an idea, and even if we did, it wouldn’t be reliable or polished.
Perhaps Game Design Hackathons are the only kind of hackathons worth going for. At least it can be a prototype game worth investing more time in.
I’m Sorry but I think you are missing the point here, hackathon events may be a few days, but are rarely a “been-there done-that” affair. I am going to be attending a hackathon here in UK in January and from speaking to one of the event organizers, I have gleamed that they actually do expect or would like continual involvement and are quite up-front about this, just as I am quite up-front about the terms of my involvement are. I think the biggest problem with a hackathon is someone treating the attendees like employees, they are not, if I walk in and one of the organizers annoys me I have free reign to walk out and I’ll still have my job in the morning.
I’m not stating that all of your points are invalid, as far as I can see they are great points, but perhaps a little over-stated. Most of them seem to approach hackathons as if there was a client->provider situation, but it is actually more of a problem->solution approach and many projects (like the one I am going to in London UK in January for the UK National Health Service) are for good causes that make developers want to be a part of them rather than being motivated by pay, pizza or drinks.