Unomaly Hack Week

For fun and profit — the why, how and our takeaways.

So, Unomaly had a hack week!

After the last release, we decided to take the whole following week and let everyone work on whatever they want! The purpose was to encourage people to get creative and explore ideas without restrictions. This resulted in almost a dozen projects, done both individually and in self-formed teams.

Why a hack week?

Making software is a highly creative endeavour. However, day to day work largely comes down to following a roadmap and making prioritizations according to customer needs and team strength — slimming and stripping — in order to sustain a business. Even if you try to stay agile and all that jazz, there will be times where people have great ideas that just sound too “out there” to bet on — or that need exploration before they can even be suggested. And that’s what we think the hack week is for!

The whole software business has its roots in the hacker scene. Before it became a way actually making money, people would just get together at their spare time, and work on things that sparked their curiosity and challenged their intellectual abilities (and sometimes left them severely sleep deprived) — to hack! Hacking is tinkering, inventing, playing around and exploring without constriction, or even necessarily a goal. It’s about letting of go of what is useful or what will make you the most money, and just having fun! However, as it turns out — what is created in this way often turns out to both profitable and useful.

Google is famous for letting their employees spend 20% of their time on side projects — being anything they want. This might sound radical at first, but it’s got many things to show: it’s where Gmail came from! And point here is: even if Gmail now seems like an obvious thing — the idea to even work on it, might never have landed in a roadmap, had their engineers not had time to start the work without a formal approval. A way to look at it: you put 20% of your roadmap, planning, etc. entirely in the hands of your teams — no questions asked.

What makes a good hack week?

A concern that was mentioned before the hack week, was that it can be become a way to make people work late nights, putting in unpaid hours, and doing leftover work from sprints that should in fact they should be part of the roadmap. This was why we put it after the release, to make sure the team was under the least amount of pressure.

Another thing pointed out by a team member is the importance of making sure it doesn’t turn into a competition of who has the greatest brainpower, is the most creative, or can put in the most amount of hours. In the spirit of true Swedishness (everyone gets a medal!) — we think it’s important that all work is shown appreciation, since the whole point of hack week is to have fun and not feel constricted!

Getting down to business

Step 1: Gather ideas

We started out by collectively compiling a list of ideas that people wanted to work on. This included such novelties as:

• Port unomaly to Common Lisp to prove that it is the One True Programming Language once and for all
• KILL THE MODALS WITH ALL THE FIRE IN THE WORLD.
• Multidimensional situations or transdimensional situations (!!!)

And about 30 more! With the list of ideas completed, it was time to…

Step 2: Start hacking

People were free to work in any constellation — by themselves, or in a team, on any idea they wanted. This ended being the following:

Explore launching Unomaly as a Service (Jeff)

Hack Week doesn’t have be about code! Jeff took to a stab the product-level perspective and looked into what would mean to launch Unomaly as a Service — with the fantastically inappropriate abbreviation UaaS. He presented some good reasons for doing this, and a redrawn architectural diagram.

Reimplement comments using GraphQL (Gustav and John)

Pain points with the REST API, and perhaps a bit of sheer curiosity inspired John and Gustav re-implement the comments feature using GraphQL.

Tooling for release process (Johnny and Carson)

More often that we might want to admit, the process of making a release has been associated with stress and cursing, due to a few manuals steps still lingering around. Carson and Johnny took matter into their hands and produced some good tooling.

Stability metric and frequency spike detection (Filip)

Filip experimented with new ways of detecting anomalies: a new System Stability Metric derived from our baseline data. He also looked at T-digest spark detection as an alternative way of detecting spike-type frequency anomalies.

Store learning in ScyllaDB (Filip, again!):

Filip had soooo much he had to get out that he embarked on _three _projects. Scaling, has been on the horizon for a while now, and ScyllaDB has been a database frequently brought up. Filip reimplemented our database schema in ScyllaDB, and his research made a promising case for using ScyllaDB to store our learning and better handle data replication and auto-scaling our worker instances.

Simplified versioning (Lowe)

Lowe decided to scratch an itch regarding our. We’ve been on Unomaly 2.x.0.y for a long time, with 2 and 0 never changing. So we decided to change this to just x.y, or major.hotfix.

Flow for free trial in website (Kai)

Even Kai, our consultant, pitched into hack week by redesigning the signup “sign up for a free trial” flow on our website.

Kill the modals (Daphne and Vega)

Vega and Daphne did a revamp of our user interface. They provided some great before and after mockups, making the UI more streamlined, consistent — and most importantly: free of modals.

Ingesting metrics (Alex)

Alex looked into analyzing metrics, in addition to just textual logs — and finding anomalies in them as well.

Step 3: Presenting

At the end of the week, we all gathered with snacks, laptops, and a big tv — and everyone presented their work to the rest of the team. It was great to see the engagement that comes with everyone presenting something they fully picked at their own choice. Also, this became an opportunity to cross-pollinate ideas: the revamped modal-less UI provided a suitable place for the metrics that Filip had come up with in the backend. Or, the new versioning scheme devised by Lowe was so popular that a on-the-spot vote was made, ruling in favor of it!

Takeaways

So, we did a survey of the week, where we asked:

1. Should we do it again?
2. What did you like about hack week?
3. What didn’t you like hack week?
4. How would you explain why we have a hack week, to an outsider?

All respondents thought we should do it again. The overall themes for the second question was feeling free to create and explore on company time. The most memorable response, however, was:

Hack week makes engineers feel like they can live a little

The room for improvement responses included: more teamwork, that we should it more often (heh), and that we could make it feel more special.

So, thinking on that last bit and how we can improve: next time we will spend some more time curating ideas beforehand — in the hope that it might encourage teamwork, as everyone has a better chance to fully understand the different ideas on the list and how they might contribute. Also, to make it a more out-of-the ordinary experience, we’ll try and arrange some activities during the week such as a joint dinner, or maybe bring a jumping castle to the office. Or maybe not the last one, but you get the point.

So our key takeaways are: people liked it, and we will do it again!

Thanks for reading! ✨✌

Originally published at unomaly.com.