Thinking about Hackathons

Background

So I recently started walking to and from work. The walk is about 3.5 miles which takes about 50 minutes. This gives me a lot of time to think, even over think but even I bore myself sometimes so I decided to give podcasts a try. I grabbed a load of Hanselminutes and Herding Code episodes to maybe learn something new. One of the Herding Code podcasts really caught my attention - 109: Harmony Hackathon. The podcast tells the story of a group of people that got together and spent 48 hours designing and developing a solution for a charity organisation. I've heard of hackathons before but hearing these guys talk about their experiences while using a technology stack that is my bread and butter (.NET) just got me all tingly inside.

I wanted to do this. I know it sounds pathetic but the experience of hashing something out, cutting code and working totally agile without the bureaucracy of management slowing things up¹ sounds really fun to me. I tend to get bored on long running projects. I really want to try new things in real projects but convincing managers or customers is a near impossible task as the "play it safe" attitude makes a lot more sense to them. Come on guys who cares about money when there is fun to be had?

So anyway this got me thinking. How would I go about this, why would I go about this and how would I get other people to give 24 or 48 straight hours of their life for something like this? I mean I live in Belfast, Northern Ireland not exactly a MAJOR hub of geek activity.

Hackathon Goals

So why would we do this? Having clear goals upfront is really going help sell this to people. They will also act as guidance and help drive the entire event to the finish line. There are plenty of reasons, perhaps even contradictory ones,

• A finished product or prototype
• Education of technologies and techniques
• The experience
• Technology evaluation
• Networking
• Something to put on your CV

I realise that much of this is done on a per person basis but unless each persons goals are aligned in some way there is a risk the whole thing would fall apart. Personally I think people wanting to leverage it for any sort of networking, CV building or taking unfounded punts on technology need not apply. I am not adverse to a bit of risk taking in the technology stakes but they need to be calculated risks rather than a "ohhh shiny lets use this" attitude. If it's putting all the other goals at risk it's not worth it.

• A finished product or prototype
• Education of technologies and techniques
• The experience
• Technology evaluation
• Networking
• Something to put on your CV

I'd be happy working with people who agree with me on at least 2 of the points above. But of course this isn't a hard and fast rule and I remain open for the greater good.

The Idea

So what would we do? I don't think it would work very well if we just played around with some technologies and produced a few prototypes. No, addressing a real work problem or need that is of sufficient size and complexity that allows us to drive a spike right through the entire solution gives us something to work towards. Actually producing something that works or at least proves that the idea is viable seems almost mandatory. The thought of walking away after the 24 or 48 hours with something that you can show people is a noble goal. Whether that be for charity, something internal for your company or something for the open source community.

I have plenty of ideas I would go for but this isn't a dictatorship (not at this point anyway) this is only going to work if people feel really involved, after all when the "mid way slump" starts kicking in you're only going to make it through if you WANT it to work and are invested in experience. I guess what I am saying is you'd get people together - potential developers, product owners, investors up front and brainstorm, plan and argue. This brings me on to another point….

The 7 P's

Prior Preparation and Planning Prevent Piss Poor Performance. The more I think about this hackathon thing the more I come to the conclusion that it is so much bigger than the 24 or 48 hours of design and development. Like all good adventures you have to go in prepared. What would you need upfront?

• You need your goals clearly defined
• You need a few user stories so there is something for people to do while things are getting established
• You need your stack and approach mapped out (including source control, CI and Build Server etc.)
• The participants need to at least have a fair idea what they are doing
• You need to have some sort of rough plan or schedule
• You need food, drink, beer, alternative entertainment
• You need a venue, a comfortable venue with internet access
• Oh and I guess you need to invest in whiteboards. Lots and lots of whiteboards, and markers, and cue cards and possibly deodorant.

People involved

Agile makes sense here, of course it does. So it's not just a matter of locking a few devs away with coffee and vitamin pills. No you need product owners at hand, you need someone testing and you need some sort of BDFL (Benevolent Dictator for Life). I guess a BDFL isn't mandatory but a technical lead who has the final say is certainly going to make the decision making process a lot quicker - be that good or bad.

Motivational people are another thing that would come in handy. Having people see something and be like "yeah that's nice, good job" is going to keep those flagging energy levels up.

Developer headcount is another balancing act. You need enough people to make the goals achievable but you also can't have too many people or you risk stamping on each others feet. I guess it depends on the size/complexity of the idea you want to implement but a finger in the air guess I'd say between 4-8 developers with a product owner and a tester (could be the same person) would be a nice number.

Development Approach

I've already said agile seems like a perfect fit and I think the whole ecosystem that agile brings in fits well. TDD/BDD almost seems mandatory here - at least some level of it. Checking in code with no tests around it is going to cause a headache when you hit a bug that takes and hour to track down. A strict regime of constant branching, merging and checkins (every 20 minutes or less) along with a fast continuous build system will help discover problems ASAP.

Atmosphere and Communication

An entire project condensed into 24/48 hours is going to magnify the pain points and tensions will rise. Techniques such as Pomodoro would come in handy to make sure people aren't burning themselves out too fast. A quiet room and alternative non-computer based entertainment will give people a quick escape on their pomodoro break and a chance to get their head showered. Communication NEEDS to flow so regular standups (every 30 minutes to an hour) are essential to spot problems early and find a way to resolve them quickly. Again having some sort BDFL could really help in this situation.

Where now?

You know what - someway, somehow I am going to do this. Consider it part of my career bucket list. Something I want to do before I join the great geek scrapheap in the sky. Could I get the people? Yeah I reckon I could. Could I get the sponsorship/support? Most likely. Could I find a suitable idea to run with? Hells yeah. So what is stopping me? Hmmmmmm nothing. BRB got a hackathon to organise……..²

¹ Not all managers are created equal but they have a job to do and process, meetings, documents etc. all get in the way.

² Yeah really. No joke. I can but try.