First the advice, then the backstory
Unlike those recipe sites where you have to scroll past lots of backstory and unrelated personal trivia before you get to the actual recipe, I’m going to give you the advice first.
It’s just this: in a hackathon, simple and working beats complex and non-functional.
The demo you build should be all about showing your main idea in action. The user should be able to go to your site or launch the application, use it to perform the intended task or achieve the intended result, and there should be a clear sign that the user succeeded at the end. That’s it. Anything else is gold-plating, and you don’t have time for that in a hackathon, whether you’re allotted an afternoon or, as in the case of StartupBus, three days. On a bus. With lots of interruptions.
Once again, I repeat my best hackathon advice: simple and working beats complex and non-functional.
Want to join StartupBus Florida?
It’s not too late to register to register for StartupBus Florida, which departs Tampa on the morning of Wednesday, July 27 and arrives in Austin, Texas on Friday, July 29 with surprises aplenty in between.
While on the road for three days, you’ll build a startup and its supporting application. Then on Saturday, July 30 and Sunday, July 31 in Austin, you’ll present your startup and application to judges in the semifinals (Saturday) and finals (Sunday).
Need more details? Email me to find out more!
Want to register? Go to StartupBus.com’s Apply page, select Florida, and use the invite code JOEY22.
And now, the backstory…
Here’s a story from a hackathon where I applied this principle and impressed the judges enough for them to make up a new prize category on the spot.
In 2017, GM (yes, the auto manufacturer) held “Makers Hustle Harder” hackathons in a handful of cities to see what people could build on their Next Generation Infotainment (NGI) SDK for in-car console systems.
They held one of these hackathons in Tampa at Tampa Hackerspace. and I offered to help Chris Woodard work on his app idea. I did that for most of the day, and with a couple of hours left, I came up with a goofy idea that I could whip up in very little time.
A little technical background
The NGI SDK made it possible for developers to write apps for the in-car infotainment consoles located in many GM vehicle center dashboards, like the one pictured above. The SDK gives you access to:
- An 800-pixel high by 390-pixel wide touchscreen to receive input from and display information to the user
- The voice system to respond to user commands and provide spoken responses to the user
- Data from nearly 400 sensors ranging from the state of controls (buttons and the big dial) to instrumentation (such as speed, trip odometer, orientation) to car status information (Are there passengers in the car? Are the windows open or closed?) and more.
- The navigation system to get and set navigation directions
- The media system to play or stream audio files
- The file system to create, edit, and delete files on the system
- An inter-app communication system so that apps can send messages to each other
With the SDK, developers could build and test apps for GM cars on your their own computers. It came with an emulator that lets you see your apps as they would appear on the car’s display, simulate sensor readings, and debug your app with a specialized console.
The hackathon
I arrived at Tampa Hackerspace that morning, and it was already abuzz with activity:
Outside in the parking lot were 3 NGI-equipped GM vehicles provided by Crown, a local auto dealer. Two of them were Buick Lacrosse sedans…
…and one was a GM Sierra truck:
The NGI team were there to answer our questions and help us install our apps onto the in-car console to give them some non-emulator, on-the-real-thing testing.
I performed a “smoke test” on my test app, Shotgun (an app that takes a list of names and randomly decides which one gets to “ride shotgun”) early in the morning on the Sierra’s console…
…and I have to say that there’s nothing like the feeling when your code runs for the first time on a completely new-to-you platform.
My main reason for being there was to help out Chris Woodard (whom I knew from his Cocoa / iOS programming Meetup group) on WeatherEye, his app that provides live weather reports for your planned route as you drove. When we completed it early in the afternoon, I ran a smoke test on it, and it worked as well.
With a couple of hours of “hacking time” left, I came up with a silly idea and coded it up: a timer for the game classically known as the “Chinese Fire Drill”. Here’s how it worked:
- Four people get in the car, close the doors, and someone starts the app. They’ll see this screen:
- When everyone’s ready, someone in the front presses the start button.
- If any of the doors are open when the start button is pressed, the players will be told to close all the doors first:
- If all the doors are closed when the start button is pressed, the game begins. The screen looks like this:
- Players exit the car, run around it once, return to their original seat, and close their doors.
- The game ends when all four doors are closed, at which point the time it took them to complete the drill is displayed:
(If you’d like to see the code, I’ve put it in a repo on my GitHub account.)
The app wasn’t pretty, but that’s not what hackathons are about — they’re about getting your idea to work in the time allotted. Remember: simple and working beats complex and non-functional.
I found an available test vehicle, three other people to playtest the game with me, and two camera operators to record video of a test runs. We played the game twice, and we were giggling all the time. Fitness Fire Drill (I decided to not call it Chinese Fire Drill, as the term comes from an era when “Chinese” was used as a pejorative adjective to mean sloppy, sub-par, or amateurish) was a success!
Everyone who built a project presented it at the end of the day to the panel of judges, and the organizers saved Fitness Fire Drill for the very end — it got a lot of laughs.
In the end…
My wife Anitra was flying out early the following morning on business, so rather than stay for the hackathon dinner and judges’ results, I high-tailed it home to have dinner with her. Before going to bed, I noticed that Chris had sent me an email telling me that Fitness Fire Drill won the “Judges’ Fetish” prize (a category they’d made up just for my submission), something I wasn’t expecting!
From that outcome, I learned what I now call the First Rule of Hackathons: simple and working beats complex and non-functional.