Lesson: Intro to Hacking with Greg Osuri

Step: #7 The Event: Hackathons are the weddings of code

There are two ways to go about throwing a hackathon. Say you are an established company and you don't quite have an agenda in mind and Facebook does this really well. What they do is, they tell you just to come and hack, there are no rules, there is nothing. Here are a set of APIs, just have fun, just pure fun. That is very important to them because that is how they drive their entire company, internally, externally and that's the invisible innovation that Zuckerburg sees. And the fact is that it always works out for them.

But for more traditional organizations like Hurst or PayPal or Hasbro having a clear agenda as to what you want to get out of the hackathon. In most cases it will be, we have an API we want to launch it and we want to invite people to come use this API and tell us how it is. Having that agenda is very important. Now once you have set the agenda you can either go hire a company that does white label hackathons. That means that they help you manage these or you can run it yourself. People come to hackathons and work in a team to achieve a common goal. Usually three to four, we haven't seen anything bigger than four. But some of them work in pairs too. But ideally three or four people is a good team.

So Hackathon.io is a logistics management and a discovery platform for Hackathons, so people can if you want to find out what Hackathon is having in the city, you go there the directory. If you want to host a Hackathon, all the logistical part like judging, scheduling, all those tools are packed into this platform that lets you run Hackathon smoothly.

We had AngelHack, we use that platform to run massive Hackathons, about 30 cities at the same time, that sort of thing. It's also a great place for discovering people, if you want to hack with somebody, have this idea, you're looking for a particular skill set, you can go there. Type in Ruby, you'll find a Ruby developer to work with.

Certainly there are rules as to when you have to code, when you can start coding, when you have to stop coding, when you have to submit your hack. But there are general rules about what not to do at a Hackathon, I don't think so. I mean the whole culture in the Hackathon itself, means come there do whatever you want.

The process that Hackathon.io we had established was pretty phenomenal when it comes to speed. One of the things we do is we use github.com to host our software. GitHub provides mechanism to create multiple versions of the same code base. So, we would have a master branch and a developed branch and we use master branch to match what's in our production and develop branch to match what's in the staging which is a stage before production where we push a code so that everybody can see. And the process we had was the moment we write a requirement, we put it as a story in Pivotal Tracker.

That gets assigned to the engineer and the engineer takes a look at it, provides some estimate and if you're okay with the estimate, he goes forward with the task. Often times estimate is less than a day. So once he is done working on the task, he pushes the code base to GitHub, to the developed branch and that gets push automatically to the staging branch. This chain is called continuous delivery.

Once we're satisfied, what we have seen in staging, we merge that with the master branch and that gets pushed to production and automatically the next thing you know it's in production. That happens with everything including infrastructure. So, you need to add new server and we need to remove a server and a consolidate servers. We continuously keep pushing a change, continuously seeing that happen deflect of production. That process has worked really well. And I see that process, that's a de facto process; a lot of companies today are in a mode to adapt.