Before you criticise “hackathons”, don’t.

There are a lot of blog posts that criticise hackathons as a general concept, and without exception we think they all get one thing wrong.

Basically, the problem is people write about one specific practice at a hackathon and then use that to condemn all hackathons. In fact, there are many different and diverse ways to run a hackathon. So this is like trying a mango and not liking it, and then condemning all fruit.

Now, we have to be very clear we’re not saying hackathons are beyond criticism. Certain practices at hackathons can cause problems for some people, and this should be raised and discussed freely. But always try and do it in a way that specifically mentions the practice in question and don’t assume all hackathons are the same. Instead, maybe think about different ways you could run a hackathon that would help tackle the problem.

For example,

  • Some hackathons have such onerous terms and conditions that many people argue the sponsor is just trying to get people to work for free and then they will take the best ideas. This does happen sometimes. But not all hackathons do this.
  • Some hackathons encourage people to work all night. It is argued this excludes people with less energy or other commitments such as family. Again, not all do this – I’ve been at ones that encouraged you all to leave at 5pm.
  • Some hackathons feed people pizza all weekend. This is obviously not a healthy balanced diet. But don’t worry – many serve full meals and have fruit around.
  • Some hackathons focus on a business or startup plan. Some people argue not everything should be a business or a startup. Great! Some hackathons are specifically focused on social issues.

Basically, the term “Hackathon” is now applied to such a wide variety of practices that it has to some extent become meaningless. By all means, lets have criticism and constructive debate about certain practices. But don’t assume a particular practice you don’t like happens at all hackathons and write them all off.

Not a coder? How to do well at hackathons

So you’ve got a great idea, but no-one in your team is a coder. What can you do at a hackathon that is both productive and shows of the potential of your idea well? This post is a very brief introduction to several things you can do – it should be easy to find out more on these topics online or from others at the event.

The first thing is to develop the idea more to work out all the details. Some tools for doing this are wireframes and personas.

With wireframes, the idea is to draw how each screen of your website or app will look like and how users will move between screens. They don’t have to look good; this is about the functionality. In fact, it helps if they look plain and simple as then people looking at them concentrate on the functionality and not on whether they like the particular graphic you have used. Here’s an example:

Wireframe Example

With Personas, the idea is to build up an idea of who will use your website or app. Invent fictional characters and give them as many details as you need to make them realistic. Make up multiple characters if needed.

The point of wireframes and personas is to think in detail about exactly how people will use your service, and what their motivations for doing so will be. You will hopefully surface many questions about small details that you can answer. This will serve two purposes: make your idea look more realistic when you present it and make it more likely you will attract others to your team. Programmers hear a lot of people who say “I’ve got an idea” so they tend to ignore them – if you can show you have thought through your idea carefully they are more likely to listen to you.

You could also work on the design and marketing message – how will it look and how will you attract people to it? This will help your presentation look good, but will also help you refine your idea. If you can’t come up with a quick simple marketing message and a way to explain to people what your idea is, then your idea may be too complicated and may need simplification.

Other possibilities to work on over the event is to work out what would make a really effective demonstration for your idea – can you fake something?  Maybe you have a service where people submit some information to a website then get emailed some other information – so set up a google docs spreadsheet with a form to collect information, then have a team member sit there and manually send an email in reply. The person you are demoing your service to doesn’t need to know it’s not automatic.

Can you conduct some kind of user research – show your mockups and fake demos to some people from your target market? You should learn lots from this.

Lastly, bear in mind that even with teams who are programming furiously* no-one expects a finished product over a single event. So don’t try. Concentrate on exploring the idea in more depth and showing off effectively what you have done in a brilliant presentation. Remember that at many events your all too short presentation is all you will be judged on, so if you’re approaching the end of the event and you have several different things to do, do the thing that will help your demonstration look best (this applies to coders pondering what feature to do next too).

Above all have fun! Hopefully you will leave with a more in-depth idea, some great feedback to encourage you and maybe even a great team too for the future.

* In fact, sometimes the teams who are coding furiously are at disadvantage, as they have started coding before they really know all the details of the problem. They are at risk of coding the wrong thing. So sometimes it’s good to do a lot of work researching things before anyone codes a single line.

Hackathons: getting domain experts and developers to mix

One of the big challenges to overcome at a themed hackathon (like NHS Hack Scotland) is getting domain experts to mix with the developers well.

If this isn’t done, then what’s produced will be of little value. Developers left to themselves will produce things that don’t solve real problems or things that rely on unrealistic assumptions and thus will never work in practice. Meanwhile the domain experts won’t fully grasp what technology can do for them and will come up with something vague (“we could have an app?”).

If this is done right, then people will learn from each other and the concepts produced should be a much better fit. Even if nothing concrete is produced, the collaboration should educate and enrich both sides and send them back with renewed energy and focus.

The first simple step is to make sure the event does not do anything to prevent this. I’ve seen one hackathon that made people wear different colour wristbands and then made all the domain experts leave at a certain time to let the developers work – thus instantly throwing a barrier between them.

But this collaboration is something that has to be explicitly encouraged. People will tend to talk to the people they know when they arrive, but you want to force them to go and talk to the people they don’t know from the “other side”.

sicampstickersOne tactic is “organised fun”. For instance, the game where you are given a sheet of stickers. Some are blank and some have general titles on them like “Educator”, “Innovator” and “Maker”. You can’t stick these stickers on yourself – you have to talk to someone, ask what they do and stick it on them. This is great for getting people to start a conversation by asking others what they do. Note some people get a bit uncomfortable at “organised fun” that is to forced or twee – you have to ask what is the overall benefit of making everyone feel more connected and find a balance.

Another tactic is to give space for ideas or peoples thoughts to be aired. Having a structure for this means that people who may be to shy to go up and speak to someone will have a way to engage. Have a board where anyone can pin up a sheet with an idea on it or another message. Have a space at the start for anyone who wants to stand up for 30 seconds to mention what they want to do over the event. Have someone who tracks what people are working on – then if someone is looking lost it’s their job to go and find out what they want to do and introduce them to some people. If there are several different themes have banners for each one in a different part of the room with people standing by them, so attendees know where to go to talk to someone.

I’ve seen other hackathons have bookable slots for sessions with domain experts where teams can go and get feedback in an informal chat session. It’s better to have the domain experts in the teams if possible, but this is still good.

Somehow, you must find a way to get people together. For a themed hackathon, getting domain experts and developers to mix is the essential ingredient!

Photo from Social Innovation Camp

More posts on Hackathons to come!

Why go to a hackathon?

Hackathons and hack events are having a bit of a moment right now with lots on and lots of people discussing them. One of the problems in the discussion stems from the fact that there are many different reasons people go to hackathons.

  • Education – learning some new technical skill by doing something.
  • Education in a new field by learning from others there.
  • Meeting people in general. Maybe just chatting or working with them on a team.
  • Trying a new idea out over an event.
  • Starting a new company or social enterprise over the event.
  • Wanting to use your skills to help a good cause like a charity.
  • Building on an existing project (probably an Open Source one) and recruiting people to it at the same time.
  • Winning the prize.
  • Showing off what you can do to win something later. Sometimes this may be direct; the organiser of the hackathon will commission some of the best entries or offer a prize but sometimes someone else at the hackathon will like what you do and approach you about something else later (a type of networking, basically).

Also, organisers have their own reasons. They may want to encourage something like education or they may want the event to produce some software or ideas they or others can use.

So why is this a problem? Because people often fail to appreciate these different reasons and in particular they don’t appreciate there is a different style of hack event for each of them.

Compare a hack event where organisers want to encourage a finished project to emerge to one where the organisers want to encourage learning. The former will usually offer a really sweet prize (maybe an immediate thing like some geek toys or a delayed thing like a commission) whilst the later probably don’t want to offer any judged prizes.

People have to understand this. In particular if they have a bad experience at one hack event because their aims don’t match others, they shouldn’t assume all hackdays are the same and slag them all off. Sadly, I’ve seen this pattern in many blog posts.

Let’s not let a few bad hackday experiences ruin the concept for everyone!

More posts on Hackathons to come!