A wonderful hackathon for building terrible things
The Terrible Ideas Hackathon is a force for glory and joy
Last weekend, I participated in Auckland’s annual "Terrible Ideas" hackathon.
I went into it with no expectations, and came away in awe at just how creative people can be.
The background:
The only things I knew going in was a) that it was a hackathon b) based around the concept of ‘terrible ideas’. I had no idea what that meant in practice, but it was a “you had me at hello” situation — what more could I possibly need?
Truth be told, I’m still not entirely sure why the concept is to make something terrible, but some possible reasons are:
It takes away the pressure that comes with building a serious product prototype in one weekend,
It opens the door to far more creative projects than solving a problem does, if only because there’s more low-hanging fruit, and
It’s fun.
So let me take you through one of the most baffling weekends of my life.
Friday night:
The hackthon kicked off at 5:30. I met up with a friend who had gone to the same coding bootcamp as me, and we settled in alongside ~40 strangers to listen to an inspiring opener. Alas! Our scheming was short-lived, as we were told to make groups from people entirely new to us. I turned to the person beside me, and we soon attracted a small crew.
I’d come to the event with a pre-made list of terrible ideas, such as:
An app that links to the Fitbit API. If you sit for more than an hour, it starts adding bugs to your code.
A ‘breaking news’ site that contains only the most recent news worldwide, not the most important. It updates too fast for any human to read.
A browser extension that replaces words with their longest-possible synonym.
These inspired some laughs and excitement, but we were soon throwing around even more impressively bad ideas:
A reverse roomba to spread dirt and dust through the house.
Some kind of wearable that detects when you’re stressed, and calls your mother —
…Or yells at you,
…Or starts encrypting random files on your hard drive until you solve a maths problem,
…Or plays whale songs at maximum volume for 10 minutes.
A meetup app for slow walkers.
A digital jigsaw puzzle of entirely white pieces, which resets if you put a piece in the wrong spot.
A ‘reverse microwave’ that uses liquid nitrogen to make food perfectly tepid. Sadly, the gatekeepers of the liquid nitrogen weren’t available over the weekend, but the microwave did find its purpose later on.
A microphone that only amplifies ambient sound.
…All these, and a whole lot more. We didn’t write them down at the time, but quickly accrued dozens of ideas.
Finally, I suggested “surgery simulation by committee” — using a modified version of a robotic tattoo machine (a project one of the team members built last year) to slice up a watermelon, with cuts determined by the audience voting on an app. That team member understandably wanted to mix it up a bit, and he also happened to be the proud owner of a microwave, so we came up with… The Terrible Idea.
The Terrible Idea was essentially this: Mixology by community vote. We build a machine plumbed with various liquids (all technically drinkable!) and through a ‘Twitch Plays Pokemon’-esque style of audience participation, the machine would automatically pour new liquids into the drink, one round at a time, until the cup was full.
We gave it (and ourselves) the name ‘Mixer Mayhem’, with the very concise tagline of ‘Mixer Mayhem’s multiperson mesmerising modulated mixology microwave machine’ (MMMMMMMM for short).
We did some planning:
Hardware — We’d be using pumps, servos and clamps for the liquids, plugging the host laptop directly into the machine to send instructions on what to pour.
Software — We’d be using WebSockets, given the need to update the next drink to pour in real time. Since my day job skews to the backend, I was on this team, along with two other software engineers. WebSockets have been on my vague “would like to learn someday” list for nearly a year now, so this already looked like a great learning opportunity.
What's a WebSocket?
"The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply." ~MDN
In other words, WebSockets let you send and receive information very quickly, which was perfect for our use case. Why? Because we wanted people to vote for what should go in the drink next, and to prevent them from getting bored, we made each voting round only 15 seconds. Using WebSockets, we'd get the data instantly as soon as each person voted, letting us update a display of the votes and prepare the machine to pour the next drink.Saturday:
In my excitement the night before, I had gotten very little sleep. I scraped myself out of bed like a bleary-eyed barnacle and rode into town for the 9am start.
In the University of Auckland makerspace, we were greeted with Up and Gos, energy drinks, and breakfast muffins. A sight for sore eyes, made even better when one of our team showed up with armfuls of iced tea and juice. We needed empty bottles to attach to the machine, so it was time to get hydrated. Thankfully our neighbouring teams were happy to help us along with this project.
The morning started off with a discussion of software architecture. We used Excalidraw, a free online whiteboarding tool, to visualise options for how the app side of the project would be organised.
The WebSocket server was going to be hosting in a EC2 instance regardless, but we had two main options in how to structure the rest of the app.
What's an EC2 instance?
An Amazon EC2 instance is a virtual server in Amazon's Elastic Compute Cloud (EC2). You can use it to host data and run applications on the Amazon Web Services (AWS) infrastructure. In our case, it was going to host the WebSocket server that all the people voting (the 'front-end clients') would be connected to.Our options were:
Connect every front-end client to the WebSocket server, and handle the business logic on that server too (the business logic here was mainly the random selection of a drink, mapped to the probability distribution of the audience’s votes). The result of that business logic would be sent to a back-end client, which would turn this into a hardware-readable format and send it to the robot.
The WebSocket sends out all the messages it gets to all clients. These clients include the front-end clients (i.e. the users), but also a back-end client responsible for handling the business logic, which it calculates and passes to the hardware.
For the sake of isolating the backend logic, we decided to go with Option 2. This would never be feasible in real life because it would be a security nightmare (as everybody gets everybody else’s information), but for a hackathon, that was outside the scope of our concerns.
We also sketched out a data contract of sorts:
The front-end team were using TypeScript, but I was unsure how quickly I’d get used to it (having spent a total of one day learning about it 8 months ago), so stuck to JavaScript. I had to use a bit of TypeScript when touching the front-end code on Sunday and it wasn’t bad at all, so in retrospect I wish I’d a) used it from the start, and b) added the data contracts as types in shared code. This would have been convenient, as some properties ended up changing slightly as our requirements were clarified.
I’d set up a Git repo the night before, so we got to coding, while the hardware team split off to figure out how to pipe in the liquids.
At midday, all participants gathered for an important midday update. A representative from each team got up on stage, talked about their project so far, and asked for anything they needed — whether that be equipment or expertise.
Most people didn’t need anything. We needed valves for adding flavourings (but ended up using pipettes and servos for this). One memorable team needed someone to help with their tasers (I think throttled ones); they were building an electrified hoop to enforce 5 feet of social distancing, but unfortunately both the interloper and the person in the hoop were being tazed. Now that’s getting into the spirit of terrible ideas!
Some other things I learned over the course of this day were:
Git is not case-sensitive by default (there’s a configuration change you need to set by running
git config core.ignorecase false. Embarassingly, this was not to be our worst Git misadventure over the course of the hackathon.A hackathon is the ideal place to use ChatGPT for debugging or support: you’re likely working with technologies you’re less familiar with than usual, so quickly setting up templates is beneficial; there’s no proprietary or sensitive code; and the small codebase makes it easy to give enough context for a meaningful answer.
Converting code to serial and learning about ports was very interesting. Our team was lucky enough to have a more advanced software engineer (mostly working with the hardware crew), and when I got stuck on the serialport Node library, he explained how porting works with Arduinos.
Ports? Arduinos? What’s all this, then?
An Arduino is basically an open-source single-board computer that can be used to control electronic circuits. It has a microcontroller that can read inputs (e.g. sensors) and update outputs (e.g. LEDs, motors, buzzers). What it does is controlled by the program you write and upload to the board.
We needed to convert the drink decision coming out of the backend logic to a custom protocol defined in the program running on the arduino. To do this, we converted the data to serial format, so it could be transmitted to the Arduino board controlling the behaviour of our robot.I went home around 9:30, too tired to tackle large-scale features but content to keep ironing out bugs and tidy up the backend code. In the small hours, I wrote down my tasks for Sunday and went to bed.
Sunday
Sunday started at 10:00am, meaning (O luxury of luxuries!) I could sleep in. Of course, I had to stop off to get some all-important ingredients first; three ‘base liquids’ to be pumped in through the roof of the microwave (milk, Coke, and juice), and four flavourings (peppermint essence, lemon juice, tabasco, and soy sauce). These were going to be added using pipettes.
Back in the makerspace, we were all intent on our work as we raced towards the finish line: the cut-off at 2:30.
Due to some difficulties in allocating work we had quite a few software stretch goals done before our MVP, but our MVP did come together about an hour before the deadline.
Then we committed our changes… and it turned out two parallel streams of work, although they caused no git conflicts, interacted in a way that blocked the MVP from working. Oops. The last stable commit didn’t have all the functionality we needed, and the software team counted down our last few minutes in a haze of git regrets reverts.
What’s git?
Git is a software 'version control' system. It tracks changes in software code and other files, and allows developers to work collaboratively on a project by creating and branching off different versions of the code.
Normally, git is easy to use and 'losing' code is impossible. With the benefit of hindsight, our situation was mostly caused by communication issues and the stress of figuring out the state of shared code with such a tight timeframe.We probably could have untangled things with 10 deep breaths and 15 more minutes, but a deadline is a deadline. We filed off to hear the closing speeches — the software team with expressions that looked a lot like this:
Fortunately, the closing speeches pepped us right back up as we remembered exactly what we were here for. It was the terrible ideas hackathon! A chance to get silly, learn new things, and not just move fast and break things — but to move fast and break things with tasers.
As my FitBit recorded my heart rate dropping back down to normal, I took some time to reflect on what had gone well that day:
We were pretty good at keeping relatively modular, well-commented code considering the time crunch. Business logic bugs were found and squashed fast. We might have face-planted at the final hurdle, but we’d run a mighty fine race.
The two teams had worked well together while also being quite independent, and our hardware worked perfectly.
I’d learnt a huge amount, as well as getting a nice refresher on JavaScript and Node.
Last but not least, I was grateful to have worked alongside a team of funny, intelligent, hard-working and all-around delightful people.
After a quick clean-up, we set up our work on tables like a ‘trade show’ and started looking at each other’s projects. With our app no longer live, the people crowding around our booth used old-fashioned hands-in-the-air to vote for ingredients for the robot to dispense. The requests were inputted manually to the arduino’s code and we soon had our first completed drink, a tasty mixture of:
Coke,
Juice,
Milk,
Tabasco (x2), and
Lemon juice.
Astonishingly, one of our team members volunteered to drink this. The hero got a resounding cheer, then we dispensed with the voting and let people select their — still weird, but much more palatable — drinks. Peppermint essence and Coke was a fan favourite.
Exploring the other teams’ projects was a true joy: a testament to creativity, tenacity, and a willingness to embrace the terrible.
My favourite exhibit was probably the ‘emotionally needy appliances’. This included a voice-activated microwave that only worked with a great deal of flattery, a kettle with face-recognition that wouldn’t boil when you were looking at it (“a watched pot never boils”, after all), and best of all, two knife blocks: one that screamed when a knife was returned to it, and one that ‘ran away’ as soon as a knife came near it.
Other extremely fun concepts were an irrigation system that only works in the rain, a trebuchet that fires when you fall asleep, and funeral piñatas.
There were also a surprising amount of ChatGPT-enabled projects, like the karaoke machine that let you re-imagine classic songs based on a topic of your choice, or the impressively creepy ‘human’ that talked when you got too close:
…And of course, Mixer Mayhem’s very own creation, MMMMMMMM:
I can’t embed videos on Substack, but check out this video to see MMMMMMMM in action:
So! One weekend, 46 hours, six team members, one unforgettable project. How to wrap up such a multifaceted experience?
First off, I’m very grateful to the Terrible Ideas Hackathon and the University of Auckland for their time, energy and funding spent organising it in the first place.
Going into the hackathon I wasn’t sure why it was exclusively for bad ideas (though I was very much on board, if only for entertainment). Now I see there is a real freedom in embracing so-called ‘bad’ ideas — I think we pushed our limits more than we could have if we were making something, y’know, actually useful.
As for any lasting effects… there are two. First, I’m now very determined to make another WebSocket-based program; there’s a real-time idea I’ve been thinking about for a while, but now have more confidence to actually build.
Second, I’ve had an Arduino kit in my online shopping cart for the last month, tossing up whether to commit. The day after the hackathon, I bought it. And this weekend, I build my first-ever circuit on a breadboard.
Thanks, Terrible Hack!