Metova developers are passionate about coding. In fact, we like to believe we are among the best in the world. When we heard about the annual MoDEV Hackathon at CES (Consumer Electronics Show), we decided to test our mettle.
The hackathon had several sponsors, but the Travel Channel and Amazon Web Services (AWS) stood out to us. Travel Channel wanted to reward the best app that compliments, improves or extends their Cities app. Amazon Web Services prizes were to be awarded to the most innovative business model. AWS felt like a natural fit given that we rely on their services for most of our infrastructure. And, well, who doesn’t like to travel?
The Competition
Our team’s idea for the CEA MoDev hackathon was Travel Log: an iOS app and Ruby on Rails API to automatically create an organized photo album mapped by geolocation data, building a travel scrapbook you can share with friends and family. Instead of manually building photo albums, everything happens behind the scenes without interrupting the user’s vacation. The app integrated with Amazon’s Payment Advertising API and Affiliate Links to provide a source of revenue, allowing our team to pitch to AWS’s judging criteria.
After eight grueling, curse-word-inducing hours, we presented Travel Log to the judges. Each team was given only two minutes to display and explain their eight hours of hard work. Dave Lane, our VP of technology, started by giving the high-level overview of the app and its integrations with sponsor APIs and was followed by Beverly Massengill, a lead developer, who showed off the iOS app.
The Results
The Amazon Web Services sponsor awarded the Metova team second place and $2,000 in AWS credit. Second place? What happened? We’re better than that!
What Went Right
Technical Preparation
From a development perspective, we were ready. Having heard about the sponsors of the CEA MoDev hackathon beforehand, we were able to plan out what we wanted to build to appease the judges.
We had Lucidchart mockups ready to lay out every screen for the iOS app. The entire team reviewed the screens twice, agreeing on layouts and the general app flow. We also made a prioritized list of features in the event that we ran out of time to implement everything. This documentation helped guide decisions throughout the day. DL helped to ensure that the team follow it and repeatedly yelled “will this matter when we demo?!”
We’re also no strangers to Ruby on Rails, having implemented dozens of APIs and user-facing Web apps for our customers. We have a Rails template to set up the basic components we need in every app, ensuring we wouldn’t spend time building extraneous things that weren’t part of the core application. App-agnostic features like login and registration were ready to go within moments of the CEA MoDev hackathon starting. We also took the time to set up a web server for the event ahead of time, knowing that anything outside of actually building the app would put our awesome feature list at risk.
Communication
Metova requires that developers work together to solve day-to-day problems and use pair programming techniques. Add in our past experience as a hackathon team (we held an internal hackathon to select our CES team), and we had plenty of confidence in our ability to communicate and execute. Everyone knew what they would focus on, so divvying up tasks was a non-issue.
Prepare Yourselves
Knowing that equipment failures or problems could be detrimental, we took what supplies we thought could help: two devices to act as Wi-Fi Hotspots, a backup battery/charger, wall chargers, a couple of Ethernet cables and Thunderbolt adapters, a power strip, extension cords, extra iOS devices, USB cables, and a knife. We used almost everything we brought. The knife was only brandished once or twice to intimidate other teams, all in good fun. Having placed only second, we will need a bigger knife next time.
Bigger is Better
Having a larger group enabled us to get more done than we expected. We likely would not have received a prize from Amazon without implementing the Product Advertising API and Affiliate Links. This took DL a couple of hours and was his only code contribution, but we wouldn’t have had the time to implement that along with everything else with just four developers.
What Went Wrong
Presentation is Everything
We were not well prepared from a presentation perspective. The presentation mattered more to the judges than implementation. We expected the hackathon to be similar to some of the Nashville area hackathons, where developers have more time to present their apps and judgment is not based on presentation alone. At the CEA MoDev Hackathon, presentation was paramount, as no one touched our app or even saw it outside of our two-minute display. Unfortunately, we spent the entire eight hours coding, leaving little time dedicated to focusing on the actual presentation. The last hour was spent fixing things that we didn’t even get to show off.
Future improvement: Have a self-imposed early code stop (30-60 minutes before the actual code stop) in order to properly prepare for the presentation. Record the video aspects of the presentation prior to demo time, speak over it, then save time for a practice run to get timing down. Playing the video as a guide for the presentation will ensure we have time to cover everything and that no unexpected crashes occur during the demo (we had no crashes but experienced network slowness).
We Did Not Understand How We Were Judged
One of the sponsors we tailored our application for, Amazon Web Services, was originally supposed to award the “most innovative business model.” The morning of the hackathon, this was changed to “the top three finishers.” Actual judgment appeared to focus on integration of the SNS service as it has a straightforward use case for many types of mobile applications. We had no plans for SNS, but made extensive use of other AWS services. Taking a moment to understand what was most important to the judge could have helped us win 1st place for AWS.
Future improvement: Talking with the judges will allow us to see what they’re really looking for in projects or presentations. We also need to be more flexible in what we are willing to do adjust to changes in our understanding of judging criteria.
One Does not Simply Connect to the Network
Network connectivity sucked. WiFi was fine until the teams started coding, and then quickly became unusable. We expected this and had a WiFi Hotspot with a strong 4G signal that we turned on as soon as the hackathon’s WiFi went down. This was a nice stopgap, but eventually began performing poorly as well. Thankfully, the hackathon had wired connections and switches that they made available for every team by the afternoon.
Future improvement: We need to bring our own wired switch and try to get that hooked up from the start. WiFi tethering on our phones only worked prior to everyone else getting the same idea. So many WiFi Hotspots (presumably running on the same channel) caused intermittent connectivity and slow service.
Y U No Provide Good Presentation Equipment?
The equipment provided for us to use during our Presentation was lacking; there was no good way to display a mobile app on their projection screens. The A/V guy was thankfully knowledgeable enough to find workarounds and spent time with DL to practice setting up for the demo. We also needed a physical iOS device instead of an emulator so we could take pictures as part of the demo. To do this, we used Reflector (a replacement AirPlay server) to display the iOS device’s screen on a MacBook Pro, which was then hooked up to a projector.
Future improvement: Next time, the team will practice presentation setup in a conference room and bring along any equipment that would be nice to have during setup.
Code Problems
The team came across issues with the login/registration APIs. We were into the second hour before the problems were completely sorted. This should have been working within a few minutes. Since login/registration APIs were taking a while, we implemented an iOS registration screen. Ultimately that just took a few minutes, but it wasn’t necessary for the presentation so the time was wasted. When there were problems, it felt like everything else stopped. We did hit a point where we recognized that we had things we could test while some of us worked on hairier issues. Everyone had at least one freak-out moment over something inexplicable/frustrating/surprising during the last hour. Those types of reactions can be paralyzing, causing us to lose the few precious remaining moments needed to clean things up.
Future improvement: We will improve our Rails template or make a generator so login/registration APIs require no special setup. Pacing ourselves during the last hour of future hackathons and cutting out some features will give us more time to focus on presentation. Most of the surprising problems that came up in the last hour could have been glossed over or ignored entirely in the demo.
What We Learned
Our takeaway from the CEA MoDev Hackathon is that we always need to keep the event’s presentation and judging criteria in mind. Our first mistake was not adjusting for judging changes. Talking to the judges themselves may have given some insight into exactly what they expected from our apps. That leads into our second mistake: focusing solely on the code and just digging in and building something instead of thinking about how to best present the idea. Although our application was almost feature-complete and actually useable, many presentations were little more than PowerPoint slideshows, and many of them used dummy data with little complete functionality. As with everything Metova does, we evaluated ourselves according to our own standards. We fell short, but through reflection and examination of the facts, we have learned from our failure and will overcome.
The Hackathon Team with their prize.
Michael Eatherly, Dave Lane, Riley Mills, Beverly Massengill, and Seth Beech
Image from GoModev’s Twitter
