Lessons from the Hackathon at the 2016 AT&T Dev Summit

First things first: If you’re going to a Hackathon it’s best to get your team together in advance to establish roles and hash out a concept. Many hackathons have themes, so it doesn’t hurt to prepare accordingly with a decent idea. And it’s good to get a mix of skills and personalities. Team Luxoft led by Jim Darrin settled on the It Can Wait category for the 2016 AT&T Dev Summit Hackathon.

Jim Darrin, Kris Knabel, Roman Pohorecki, and Yuri Brigance

Making a concept

Our concept was pretty simple: make a product to stop texting while driving. In case you need to know about the dangers of driving while texting, I recommend Waren Herzog’s heartbreaking documentary about about the problem, “From One Second to the Next.

In 2012 AT&T had an entire hackathon devoted to ending texting while driving, with a $20,000 grand prize going to the Rode Dog app. Rode Dog barks at you if someone in your group spots that you’re texting while driving — not exactly a real solution. There are other apps out there; Google Play shows dozens of apps related to putting your phone into drive mode.

It’s obviously a big problem that needs solving.


The technical difficulty is detecting whether a phone in motion belongs to the passenger or the driver. GPS signals aren’t precise enough, and you can’t expect the driver or passengers to always let the app know who is who. There are some farfetched ideas, like Apple’s patent to visually recognize a driver in a moving car. Meanwhile Cellcontrol has neat windshield mounted gadget that detects driver and passenger zones, but it costs $129.

Our team wanted to create a cheap and automatic solution to prevent texting while driving.

With all this in mind, we grabbed an Arduino board with Bluetooth and theorized it could be plugged into the car’s ODB port, which is usually found near the driver’s steering wheel. With a little bit of modulation, the low energy bluetooth signal would form a 3–4 foot bubble near the steering wheel. Once the bluetooth bubble was activated, all we needed was an app that could connect to the bluetooth signal and then disable distracting apps. Every time you’d pick up the phone and move it towards the steering wheel our app would run interference.

We named our app Odysseus, after the sea farer’s experience with The Sirens. The Sirens were notorious for tempting sailors with their singing towards a rocky demise. Odysseus desperately wanted to find out how the sirens sounded without crashing his ship. So he ordered himself lashed to the mast after pouring wax into his sailors ears. Temporarily deaf, the sailors piloted safely through the deadly straights while incapacitated Odysseus listened to the tempting songs. Today psychologists call Odysseus’s actions a commitment device.

Odysseus’s prediction of his future behavior is known today as a commitment device.

Day 1: Building Odysseus

We arrived at the Palms Casino on January 1st, 2016. After the big crowded kickoff in the main hall, and visits to the vendor booths, we found more categories to compete in: M2X API, AT&T Data Rewards API, and the Intel Edison Board. The two APIs looked useful because they could be used monitor and reward good driving habits. The Intel Edison board offered a $5,000 best-of prize, so we decided to give it a try.

getting the work done

The Edison board proved tricky to setup in beacon mode. Yuri and Kris agreed the equivalent Arduino was better, faster, and cheaper to work with for this concept. By the end of the day the Edison board finally cooperated, making the nearby phone go into Odysseus mode.

The M2X API was recording the interactions between the Edison and the phone, and we could send out data rewards based on good driving. Finally, Kris and Yuri built a website which would allow you select which apps would be affected by Odysseus mode. I put together the presentation and we got some rest around 1am.

The Intel Edison Board and the phone in Odysseus mode
The website for toggling apps, the AT&T M2x API recording, and AT&T Data rewards sending data bonuses

Day 2: Judging

At 11AM a panel of judges came by and gave us 3 minutes to present. Everything worked well and we were relieved to be done. We decided to relax at the casino with some drinks. In hindsight relaxing wasn’t the best idea. More on that later.

By 4PM we knew we were in the top 20. Out of 120+ teams that felt pretty good. We grabbed our gear and went back to the main hall to present on stage. Here is where ran into trouble.

The stage was packed, and teams ready to present were milling on the edges. Kris had to power up the Edison board, set it to beacon mode, and then test the connection with our Android phone. Several Edison boards appeared on the list, all broadcasting the same ID. Kris tried setting a unique name to avoid this problem, but it wasn’t broadcasting correctly.

So minutes before our presentation we realized we could not demonstrate the phone going into Odysseus mode near the Edison beacon.


Luckily we had a presentation on hand and Yuri jumped on stage and walked the crowd through the slides. Check out the video:

Video of Team Odysseus presenting in the top 20

Yuri did a great job and got good applause, but we hung our heads when our hardware demo refused to work. We thought we had blown it. Nonetheless our concept was tested earlier by the judges, and the codebase was validated. In the end we placed 1st place in the “It Can Wait” category, which netted our team $5,000.

A high five and the winning check

Lessons Learned

We came away from the hackathon happy that our idea actually worked and that we placed 1st in the It Can Wait category. We could have improved our odds with a little more preparation. Presenting on a crowded stage in under 3 minutes is a completely different experience than working from our quiet and technically predictable workspace.

Alternatively, we could have used a backup hardware solution with the trusty Arduino. Clearly these are some 20/20 hindsight musings here, but take it as a lesson when competing in compressed time frames. It doesn’t hurt to be over prepared.

Here’s what we learned:

  • read the rules before arriving
  • target specific categories to maximize cash winnings
  • ask for free hardware from vendors
  • stress test your product before going on stage
  • have a backup
  • create a slideshow presentation in case all else fails
  • find out the circumstances of a stage presentation
  • rehearse your presentation

See you next year AT&T Hackathon!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.