A stack for your hack

You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. ― Dr. Seuss, Oh, the Places You’ll Go!

I like this sentiment for hackathons. The stories of Dr Seuss have stuck with me, peeping out from time to time from the recesses of my lived and imagined experience offering gentle wisdom. Hackathons are about creativity.

Hackathons are great for stepping out of the practical constraints of day to day work.

It’s a time to see what’s possible from a fresh perspective and perhaps being able to try new directions when we’re back in our real worlds. It’s a space for imagination and experimentation.

Living well in that space is about getting in the arena and wrestling with the delight, triumph and tragedy of the unknown. It’s one of those creative tensions where what looks like winning is actually opening yourself to uncertainty. There’s no formula for that.

Like winning at life
The way to win at hackathons, and probably life too, is to tap into your creativity, curiosity and the sparks of ideas we all carry but don’t always acknowledge (or feel confidence to show). Notice a gap in the world, find a thing that makes you go “hmm” and go exploring. Build a team, find or create a safe space, stick together through the highs and lows and bring your creation into the world.

Tell the story, see who lights up.

Practically speaking, this is about as helpful as saying “just be yourself”. It’s true, but almost useless. “Just” is a woeful understatement of the courage and vulnerability it takes. Most of it you’re going to have to figure out as you weave your own life’s rich tapestry.

Practical success
So let’s get practical. There’s a classic saying that achieving success is about systematically eliminating the potential for failure. Also hard, also still quite vague, but getting more doable.

“think big, start small”

Ambitious vision, achievable action. Now we’re getting closer to something you can actually do. It’s a pithy way to say “bring your creative steak and, also, Rome wasn’t but in a day”. The journey of a thousand miles begins with a single step. Baby steps. Lots of them. Incremental gains.

Talk nerdy to me
Hackathons traditionally involve tech and, if you’ve ever tangled with tech — from writing code to setting up a new phone — you’ll know it can turn into an infinite rabbit-hole. Once Alice goes to Wonderland, it’s a long time before she comes home. You’ll need to keep the tech practical.

Typically you’ve got a short, high-intensity burst of time in which to go for it, unfettered by the structures and strictures of everyday work. Try not to create fetters for yourself. Too much complication, trying too many new things at once and getting distracted with things you’ve been itching to play with can easily lead to desperate rushes and sheepish presentations about what might have been… if only you’d had another 6 days, weeks… months.

If tech becomes the show rather than the stage, you’re going to struggle

Focus on the story you’re telling. The tech needs to be simple to use and helpful to your cause. By all means explore, give yourself 10 minutes or half an hour to try something that looks useful. If it’s not working for you in pretty short order, move on. Otherwise you’ll be working into the night.

Focus on just one or two things.

Lean in
I thought this was a creative space? Surely we should be exploring. Yes, but curb your ambition. Or rather, keep ambition in the vision, the idea, the story. Anything that’s not front-stage in that story needs to get right out of the way. Time is short, tech is fiddly and it’s easy to spend a long time getting a thing working that adds nothing interesting to your team’s presentation. More moving parts, more gotchas.

“Keep it lean” is easy to say, harder to do. Be generous, make some room to err — it’s all learning and will help you course-correct based on real experience — but stay on track. If your tech inspiration comes from someone’s blog, remember that not many people talk about the real hard things on the journey. If it plays nicely for you, use it, otherwise let it go.

When it comes to hackathons, there’s time, but time is of the essence. Work with urgency, not with haste.

Small batch sizes, fast iterations, constant deployments to a real environment. The essence of lean and agile. Keep it clean, but don’t be clinical. Allow yourself to cut corners, but don’t get yourself into a pickle that loses you your ability to change things, especially as you head into those feverish final hours. You’re looking for a sweet spot of velocity with just a dash of sustainability.

The hack stack
All well and good, but show me the money. What tech qualifies as simple and productive for a hack? I’ve spent two days at the DVLA Botathon doing my best to put my own advice into practice, so here’s the tech I started with:

For coding, I used Python/Flask/Requests. For me it’s a delightfully productive combination. It’s also familiar, which is one of the most important factors when you’re choosing your language. This isn’t the time for learning a new one. Whatever you choose, the number one thing is how fast can I go from code change to code running? Keep it under 5 seconds for each edit you make. If it takes more than 10, you’re into swampy friction land.

For source code, an open Github repo is a must. It’s a great way to showcase your work and makes it easy to use a panoply of free services on the web. You’re unlikely to need version history, so this is very much about tooling and, importantly, connecting your code to a deployment platform.

CI/CD is your friend, but only the kind that takes 10 minutes to set up from scratch and then works seamlessly for you. No ifs, no buts, no fiddling with yaml. Set and forget. A hands-free workflow from git push to public deployment means everyone on your team can use what’s being built, in real-time. This is particularly helpful when it’s time to start collating material for the final presentation. You’ll still be head down in code, so it means someone else can take that on, because everyone in the team can access it.

The darling platform of hackathons is Heroku. This platform seems to have maintained a remarkable product discipline over the years. It’s an incredible piece of technology design. It’s remarkably simple to configure and use and there really isn’t anything out there that can touch it.

Bad design is frustrating, good design is pleasing, great design is the one you didn’t even notice.

I gave myself half an hour to try Google Cloud Run, which came close, but no cigar. Yet. I’d like to give it an honourable mention though. The experience of connecting Google Cloud Build to Github using the marketplace app was good. It auto-detects a Dockerfile in your repo, builds a container image and pushes it to a private registry. Nice. Unfortunately, I couldn’t find a way to “just get Cloud Run to pull the latest container every time”. So I went back to Heroku.

I now had code, repo, CI/CD and a deployment platform that I could iterate from my laptop using git, with a 60-second turnaround to live. In total this setup took an hour or two, including experimenting with Cloud Run on GCP. I never had to touch it again — win.

Botathon APIs
For this hack, we used image recognition with the Google Cloud Vision API and were kindly granted access to the DVLA Vehicle Enquiry Service API (VES) so I had a little extra work to do to make sure we could handle the DVLA API key and GCP service account key properly, not exposing them in public Github. Secrets are secrets. Hackathon or no, treat them with respect.

Cloud Vision was astoundingly good. The fidelity of text recognition was excellent and, other than tweaking a few I->1 and 0->0 character substitutions, I was able to get accurate numberplate recognition built in a couple of hours with a little help from regex. In this case it worked better than finding and integrating an off-the-shelf ANPR service.

The VES API did sterling work. Easy to access, it provided clean Json key-value data, delivering reliable responses right the way through the hack. It did what it said on the tin and we were particularly thankful for the support from our DVLA hosts in getting us access in a couple of hours. Cracking work.

To top it off, we were able to build a Google Assistant voice experience in the final hours, using Dialogflow. We even got some laughs by adding a touch of Welsh slang, which was a nice bonus.  Here’s a video demo:

If one thing stands out clearly for me from this hack, it’s the impressive amount you can achieve with scarcely a hundred lines of code. When marvelous API services are just an http call away, it takes only a sprinkling of integration to build something quite fabulous.

Conclusion
If you haven’t tried a hackathon, I recommend the experience. There’s as much to be learned from the ideas other teams come up with, and their approach to developing tech and ideas. It’s hard to come away without being inspired, enriched and changed. It’s not always an easy experience — creative endeavours usually have a messy middle — but I reckon you’ll be glad you tried it.

And you don’t have to be technical. If you’re comfortable working with someone who is, these are often the strongest partnerships. This was beautifully illustrated by a team of civil servants from diverse organisations who, althought they hadn’t met before, were able to build an impressive idea and demonstration of delivering services with Google Assistant that had real-world potential. Inspiring stuff.

If you’d like to check out what our “team Keneth” produced at the Botathon hack, here are the links:

If I’ve piqued your interest to try a hackathon then great. I hope you have a transformative experience, whatever you create. I don’t think I’ve ever been to a hack that hasn’t challenged me and moved me forward in some way. Thank you DVLA for an excellent event.

In the words of Dr Seuss,
“And will you succeed? Yes! You will, indeed! (98 and 3/4 percent guaranteed.)”.

In the words of Kelsey Hightower, “may the demo gods smile on your hack”.

Good luck and enjoy the process!

Comments

Add a comment

Your comment will be revised by the site if needed.