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 nine women can’t make a baby in one month. When we pretend we can accomplish something in a hackathon or two we it’s like 50 people making a baby in two 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.

Jeff co-founded Thoughtworks' Social Impact Program and is currently with Mercy Corps as a technology advisor. Visit his blog to read more about his experiences.