I am sure by now you’ve heard about the Hackathon, but if not let me give you a brief overview of what this concept is.
What Is A Hackathon?
These days there are a lot of developers (programmers, devs, code-monkeys, whatever you like to call yourself), but in the workplace there can be limited amount of time available to you to try out ideas, learn some new ways of doing things, or exploring other tools that can make your code much better. Maybe you have a subscription to Pluralsight or you enjoy trying out code from websites and blogs, or grabbing the latest code from a project on GitHub.
But when do you actually get a chance to try it all out within the office and against your projects? For most of us, not very often and trying it outside of the working environment is great but then do you ever get to put any of it into practice? Maybe, maybe not.
Along comes the Hackathon!
A Hackathon (or Hack Day) is a day that you and your team get to do a coding challenge. You may work individually or as a team in order to produce some functioning code within the given time allowance, trying out new ideas and different ways of working (which is why working in teams is great). Then, at the end of the day each team gets to run a demo of their project, explaining the objectives, why we need it, show the code in action and get some feedback from your peers.
Generally, each project is judged by a panel (could be your peers, could be a small group of colleagues who are not developers that comes to your demos) and a winner is found with a prize on offer to that team.
What Is The Point?
There are multiple benefits to this, however many of these may depend on what you are allowed to do by your boss or whoever authorises the Hackathon (boo to them if they don’t allow all of the fun stuff).
First and foremost, this is a team building exercise. You get to have a day spent coding with your colleagues. A little bit of competition between colleagues isn’t usually a bad thing, especially when the whole team is on a level playing field to produce a project in just one day.
It is also a chance to learn some new coding skills by trying out technologies that you haven’t before, trying different ways of doing things or, when working with another person, see how they code and you can learn different styles or ways of doing things you hadn’t thought of before.
The Business Case
Now, so far this has all been from the point of view of the developers, which is great; but if you’re on the business or management side of things then you may be asking yourself “what does the business get out of this?”, and rightly so.
From a business perspective, other than improving your development team (morale is a very good thing to boost productivity in a dev team, as is improving their coding ability) this comes down to the projects that are worked on in the event.
Ideally, developers should consider before the day whether they are going to work as an individual or in a team. They will then need to decide the project that they want to work on and, if appropriate, complete any design or research that needs to be done before the day. You won’t want your developers to be doing this on the day otherwise they are likely to run out of time to actually implement their project. These projects should be improvements, features or other tools, etc. that improve or enhance the existing systems that are in place (or potentially a new system to fulfil a need where one hasn’t been developed previously, if possible to develop in a day).
The importance of this is because anything that is suitable should be implemented into your actual system after the Hackathon. This does mean that you may need to spend a couple of days to tidy up code, tweak it to work slightly differently if you see a viable use case that hasn’t been accommodated, or just make further improvements if it is something very much needed. This makes the the Hackathon a great way for the business to gain some additions to the system that may not have been implemented otherwise while improving your development team.
It really is a win-win.
Pitching It To Your Boss
This will likely be the largest hurdle in getting Hackathon’s going within a corporate environment as not selling it right, or just having a boss that doesn’t agree with it, will put the idea out straight away.
The first thing to do is to explain what the Hackathon is, how often they will run and what will they get out of it. The biggest seller is that the code written will – in the majority – go into production, so it isn’t like you’re writing throwaway code or something for your own personal project while getting paid for it; you are working to improve the systems that you are already working on.
If they have shown some interest in this, then you’re into a good start and, hopefully, everything is just easy sailing from here.
Where possible, give examples of projects that could be run. Make it clear that a part of the Hackathon is to allow developers to come up with projects as we do not want to stifle their creativity by dictating terms or the code they write as this defeats much of the point of the event. Nevertheless, the first one may need a couple of ideas thrown out there for your developers to get into the swing of the kind of projects they could do with a high degree of success of being pushed into production.
A Typical Hackathon Schedule
You can structure the day however you like, but here is a simple suggestion.
You should see if your budget will allow for you to do all of this, but if not maybe you could see if developers would be willing to throw some cash in a pot, or just make it cheap and do away with some of the niceties.
09:00 Start the day in a room away from your usual desks, if possible, with breakfast and a quick introduction to the day. Getting everything setup and all ready to go.
10:00 Begin coding.
13:00 Team lunch (order pizza, maybe)
14:00 Continue coding and begin preparing your demo.
16:30 Demo all projects
17:30 Awards/prizes followed by a chill out session/drinks/dinner
This concludes the Hackathon, with every project having been demoed and a good chance to discuss what has been developed, it is now time to spend some time socialising and enjoying a well deserved rest.
Awards and Prizes
Traditional, public Hackathon events can yield prizes such as cash or tech, such as iPads, etc., however being a corporate event which is designed to promote team building and bonding rather than purely going for the win it would be much better for prizes to be more token-based rather than large or expensive items that could cause problems.
Better options are small trophies or medals, something that can be placed on their desk for “bragging rights” rather than anything too material.
It is up to you what you want to award, but as long as it doesn’t cause negative effects on the team building that this promotes.
The Rules of the Day
Rules, rules, rules… everything has rules. A Hackathon is no different, but these are there to make it fair and not stifle gameplay.
Set rules that will allow you to run an effective event, however you may want to consider things like:
- Coding may only take place within the allotted time; no coding outside of the event as this makes the challenge unfair for those who haven’t or couldn’t spend time outside of the event doing the same.
- Everyone taking part must place a vote at the end of the demos as to who should be the winner and cannot vote for themselves. It is up to them to decide if they vote as a team or individually, but if for any reason more than one vote is cast then this must be consistent (e.g. you cannot vote in a round individually and then in a second round as a team).
- You may want rules around what the team’s can or cannot do as part of their projects. For example, you may require a specific API to be used or that projects must focus on a specific system. You may also want to make rules that prevent developers creating projects that change the fundamentals of a system that are required for security purposes or are explicitly in place for compliance or other business reason
- Team sizes, you my decide you want to allow a maximum or minimum number of developers in each team. This will depend on the size of your development team.
- Hard stop times should be introduced as well. This prevents a developer working through the lunch break, which gives some time for them to take a breather, eat lunch and socialise with colleagues. After all, this is a team building event.
You may add as many rules as you like, but just ensure that they do not prevent the day from fulfilling any of the objectives of creativity and bonding.
After the Day
After the day, the most important part is to ensure that you do not forget about the code that was written. Make plans to get anything agreed into the production pipeline. Whether than means pushing your code into a branch to get it into a release (after some proper testing, of course) or putting issues into your backlog to allow time to be allocated to bring the code up to production standard/implement the changes suggested during the Hackathon demo.
This is a vital step to ensure that a future Hackathon doesn’t spawn projects that are, effectively, useless to the system it is being built for as devs know their code isn’t likely to go to production. It also makes it more encouraging for developers to know their ideas can get turned into code and hit production, in turn they will suggest more beneficial projects for the next event.
Good luck and have a great day!