This Weekend I Moved Fast & Broke Many Things

The AWS running our hack was turned off on Monday 18th – if it goes back up, you’ll find it HERE. It’s times like these that a screenshot seems like a good idea…

I’d never before competed in a hackathon. I didn’t have a team before I arrived. I didn’t have an idea of what to build. I’m terrified of back end/server side stuff. There were plenty of arguments for me to stay at home this weekend and let people far smarter than I take a shot at the prize. But my house had gone on holiday, so I had nothing better to do really.


48hrs, 6-7 pizzas, 10+ cans of red bull, 3-4 APIs, 88 git commits, thousands of lines of code, hundreds of thousands of database entries and 0 arguments later my team and I were announced as the winners of 1st place at the Imperial College Hackathon 2013 and the recipients of a £500 cash prize. But how?

The Team:

I went along knowing only one other guy there, Pruth. So the Friday prior was spent scoping out who we wanted to form a team with by the process of multi-layered conversation making. No-one wanted to be stuck with someone they couldn’t work with. Luckily for us, we teamed up with Tomasz, Geovanni, Ben and Hector (well… he was around on Saturday). Together we formed team “Awesome T-Shirts”.

A Note on the name: it’s actually a contraction of Tomasz’s adage “I learnt jQuery and I all got was this awesome T-shirt”

The Idea:

We had a team, but were no closer to knowing what we were going to build. We had at our disposable an AWS Ubuntu server and a Raspberry Pi. It wasn’t looking great going into Saturday morning. Then BAM! Geo hits us with a problem we reckon we can solve. It goes a little like this:

You want to go on holiday. Maybe you want somewhere with good music, nice places to shop and cheap booze, but you’re not so interested in the cultural or historical background of the place you’re going. How do you know where to go? You could head over to Expedia, but they require you to know where you want to go on holiday before you know where you want to go on holiday. What if you could set criteria for your trip and see suggestions and compatibility scores for holiday destinations all displayed intuitively and accessibly on a map?

How the F**k do you build that?

It was a hack, I’ll say that much from the start. The code was (and probably still is) a mess. The data was cached (very few if any live API calls were being made in the first prototype), and the UI, although it looked impressive, had some serious bodges going on (the main interface was an image gallery stripped out and filled with inputs for holiday criteria etc.)

But the things we faked and the things we didn’t get working, or didn’t get to implement are nothing compared to the lesson learnt along the way. A quick word on advice at this point: if you get it from people who know what they’re doing, take it. Take it and live by it until that advice breaks. (And know that in a Hackathon, code breaks far more frequently than the advice of good coders). We had a few talks at the start of the event and they were invaluable getting us to a point where we were competing for top spot come the end of 48hrs. And to those who spoke: for your advice, I thank you.

One of those speakers, Peter Hamilton made this cool Hackathon Tracker. It’s well worth checking out!

But dare I say, they may have missed out some crucial things which I think we crucial to our success (and potentially the reason other teams didn’t have a workable demo come 5pm on Sunday). Here’s what I think a pretty big deal on hack days:

RESTful APIs & Delegation

We were building a website, so I will speak in webby terms, but I think these principles can be applied in a broader context.

Know from the outset who is building your front end and who is building your backend. Who is responsible for the database structure? Who is responsible for JSON calls to the server from the client side? What is UI and what isn’t? (and when you figure that one out, put each in a separate div).

These kind of things are important for stupid and critical reasons. The stupid ones first: so you don’t have git merge conflicts. Merge conflicts cause two or more people to halt for 3 minutes while you crowd around someone else’s computer with a different text editor and different OS and try to mash together code old and code new while trying constantly not to drop your chain of thought on the problem your working on elsewhere… It burns up time and breaks the rhythm. Separate out from the start and stay separate.

Secondly, these clear boundaries make for a smoother app dev process. For example, I worked solely client side. I presented the user with criteria categories, asked them to set certain variables and then wrapped these up in a wee JSON object to pass to a javascript function Tomasz had written to analyse those preferences and rate destination compatibilities accordingly. We had a 2 minute conversation on the structure of that javascript object. 2 minutes. That’s all. After that, we went our separate ways, built our respective sections of the site and when it came to fitting the pieces together it couldn’t have been easier. Tomasz wrote a small javascript function which took my object and passed it to his server side compatibility algorithm thingy-muh-jiggy and the rest is foreign to me. I have very little idea how that data is processed and is rendered to the heat map etc. BUT BECAUSE IT’S A HACKDAY I DON’T NEED TO KNOW!

So if I had one piece of advice to give, it would be that

What it came out like


In the end our prototype appears to do a lot more than it really does, but that’s ok. If anything that’s my fault (if you can call it a fault – I would argue that a UI vision of how the product could work was pretty important in subconsciously leading the judges to think we’d built something pretty cool). I built a lot of sliders that set criteria, the data from which does not go into the rendering of the heat map or compatibility scores associated with each European capital city (except Paris – Foursquare’s fault and not ours).

But what we do have is a heat map which will update according to your holiday preferences. Better still, those preferences aren’t boring price ranges or distance from the airport type metrics. They’re semantic and relatable. They are more akin to the kind of questions you’d ask a friend when looking for suggestions for a trip. And the entire framework is suitably modular and scalable such that it can easily integrate new social networks. It could note where you’ve been to before and send you to places it like or completely different to it upon your request.

Sounds cool right? I think so (and so did the guy from Facebook – at least I think he wasn’t just being nice…). All that remains is for you to try it. At the bottom of this post is a link so you can go have some fun with it yourself. Let me know your thoughts any-which-way you like. Cheers


The only time I wasn’t scared of my code breaking was when it was already broken, and even then I felt like it hadn’t quite gone wrong enough to convince it me wouldn’t screw me over a second or third time before I was done debugging.

The AWS running our hack was turned off on Monday 18th – if it goes back up, you’ll find it HERE. It’s times like these that a screenshot seems like a good idea…

Link to GitHub