Hackathons at `${YOUR_COMPANY}`

Hackathons at `${YOUR_COMPANY}`

So, we held a hackathon recently, and we liked the experience so much that we have already planned for yet another

Current & Next

Software at different stages

Before diving right into hackathons, let’s first talk about a couple of paradigms that a software dev company would typically need to think about

Current & Next

Maintain software which customers are using
Build “next generation” software
Balance: Tech debt vs green-field

First paradigm is that there’s a tug of war between, on one end, fixing and maintaining software that’s already out there in the field, with customers using it, paying for it, and expecting it to work; and on the other end, building the next big thing that’s going to do all these new things. You can’t afford to focus all of your time and energy on one to the neglect of the other, a balance needs to be found.

General & Specific

Splitting up software

Another paradigm is about where & how to split your software up.

General & Specific

Build something useful for Autopilot
- Some parts: General purpose
- Some parts: Business specific
The split happened organically

There are various approaches to this, & one of them is to answer the question "Is this specific to my business, or is this more broadly applicable?" for each part of the software. Then put all the specific things in one repo, and all the general things in another repo.

General purpose

Also proved to be useful architecture
General purpose parts can be open sourced

This is makes for useful architecture. And, this also paves the way too open sourcing the general parts.

Hackathons

current vs next
general vs specific

Currently, our plan is to run hackathons themed around using the general purpose parts of the next gen projects.

Knowledge sharing

~3 devs working on each project
How much do the other ~20 devs know about this project?
One team “hosts” a hackathon themed around using their project
Workshop prior to hackathon

We have a small number of the devs working on any one project, and the rest largely don’t know much about it. Left to go on like this, eventually domain knowledge about each project tends to be very silo’ed. So how do you nip this in the bud, and get everyone on board, and share the knowledge? We used a hackathon that was hosted by one of the teams. Leading up to the day, the team ran a practical session where the rest learnt the fundamentals of using their project, a workshop.

Event organisation

Posters
Cater lunch, drinks, snacks
Have presentations on next day

Make the hackathon an event, because it is one. Put up posters around the office, blog posts, slack announcements, etc. Treat it with the same importance as as an external event, market it internally, make sure that no one is going to turn up on the day, and say "Oh, today is the hackathon is it?" Instead it should be top of mind, and everyone has thought of potential ideas ahead of time.

Another thing that we did was to hold the presentations the next day, rather than on the same day, so that the full day can be used for actually making and building. Otherwise it would really wind up being a half-day affair.

1st edition

What we built

… and then we built some things on the day itself.

Habit tracker - Daily checkin with your habits
Gamblebot - Analyses how odds change during a match
Mealhack - Slackbot with mealpal auto-order & reminders

Here’s some of what we built

Giving Autopilot a voice - Use Alexa to control autopilot
Drink water app - Track daily water consumption
Maestro- Remote replay + visualisations from MIDI keyboard

… and some more

Newer Relic - server health monitoring
Desk sensor - track standing desk heights
Brainfuck interpreter - functional conditionals & new Turing tarpit

… and yet more

What we built

Everything used the project of the “host” team (that was the rule)
Some were itch scratchers
Some were life hacks
Some were things that Autopilot might actually use

We built a whole range of things from voice commands to server monitoring, from web apps to hardware hacks. But all of them made use of this one particular project.

Pros & Cons

of running an internal hackathon

So, what’s in it for us? And, what’s in it for you if you participate in or organise internal hackathons too?

Cons

Lose 1 day of development time

It has to be said that while we’re building all of these cool things, the business-as-usual dev works is put on hold.

Pros

Other teams know how to work with the project of the “host” team
Flushed out bugs
Surfaced novel use cases, & new ideas
General purpose —> fun things

We got a lot of benefit out of it though.

As anticipated, knowledge sharing increased. Also as anticipated, since we used the general purpose project, fun and crazy ideas were built.

The host team got a lot out of it too, as the sudden frenzy of users using it novel ways flushed out bugs, and also surfaced new features that might be nice to have.

Future

What’s in the works

After all of that, we’re pretty keen on holding more hackathons.

Future

Continue hacking, pivot, spin off??
Open source general purpose projects
Another team “hosts” next hackathon
Invite guest participants

Some of the things that we built are worth continuing to work on Some of them could be open sourced too. The next hackathon will be hosted by a different team, and we even thinking of inviting guest participants

Questions

Questions?

Reverse questions

If you have run hackathons at your company, I would like to hear about your experiences too!

Hackathons at ${YOUR_COMPANY}