At the beginning of every semester, the University of Pennsylvania hosts a 40-hour hackathon called PennApps. While I didn’t feel confident enough about my hacking skills as a freshman to compete, I started doing hackathons this year. After winning an award from Yahoo! for best mobile hack at PennApps fall 2012 and finishing in second place overall at hackRU fall 2012 (a hackathon hosted at Rugers), I felt pretty confident about my abilities to come up with a viable technologically challenging product in a limited period of time.
I, along with Jeff, Teddy, and Ashu, wanted to create an iPhone app called Merge that facilitated meeting up with your friends for impromptu events like dinner or lifting. Teddy’s an excellent UI guy, Jeff’s a rockstar iOS developer with strong industry experience, and Ashu also had strong industry experience with Python (which we wrote our backend in). I saw myself as the most versatile coder on the team and a good people manager to boot.
We’d sat down before the hackathon and planned out the logistics of the app. We had wireframes of each screen, we all knew the general and specific details of the idea, and we agreed on the exact set of features we should have.
And yet, by the time that our 1pm demo came around, our app wasn’t finished. We had to demo an incomplete app. Also, we’d wanted to make the top 20 teams, and we’d wanted to win one of several sponsor prizes. In my eyes, we’d failed at reaching all of our goals.
I think that the problems we encountered were universal ones that other people can learn from. Here are what I think these problems were and how we can avoid them in the future.
At a hackathon, every minute counts. You need all the time you can get to fix bugs, polish features, and pitch to sponsors. However, our team was not able to attend all of PennApps. Jeff missed about six hours of hacking due to fraternity commitments, and Ashu missed a couple of hours due to a model UN meeting.
I don’t mean to imply that Jeff and Ashu made the wrong choice, or that they should be shamed, or that they didn’t contribute to the team. Both had conflicts that they could not avoid. However, it is undeniable that the missing man-hours would have really helped us complete our project. For the future, our team will let all clubs and organizations know far ahead of schedule that we will be completely unavailable for that period of time.
On the topic of using every second to its fullest, our team walked into PennApps extremely confident that we’d make the top 20 demos. How couldn’t we, after all? We had a solid team, a stellar idea, and mental toughness. Unfortunately, this confidence became our downfall. I’m convinced that we didn’t work urgently enough until Saturday night / Sunday morning. We didn’t foresee any technological challenges — it’s an iPhone app with a custom API! — so we definitely trod along at a comfortable pace. As a result, when we did run into unexpected problems and kicked up the urgency level, we didn’t have enough time to compensate.
Our mentality should have been that of the underdog, not the pampered white horse. There were over 100 teams competing at PennApps, all of which had rockstar teams, great ideas, and energy drinks. We should not have let our arrogance cloud our vision. Hell, I wrote the exact same thing in the Daily Pennsylvanian about PennApps fall 2012! You must move rapidly and diligently.
In retrospect, I don’t think that our team’s idea was best-suited for a hackathon. It was a solid idea for an actual application in the app store (and we had many people over the weekend tell us that they would use our app if submitted), but hackathons aren’t all about marketability.
Successful hackathon ideas are both technically challenging and impressive to the everyday person. This year’s winner, Inventory, combined the technical challenge of RFID scanners with the layman’s allure of an intelligent backpack. (Hell, the idea was so beautiful that my students at M&TSI last summer designed and executed the same idea, albeit less gracefully.) Last year’s winner, JAM, had these two features as well — the technical challenge of music transcription and an awesome demo that blew the crowd away.
Electioneering, my team’s app at PennApps fall 2012, combined the technical challenge of data mining with the layman’s allure of political comparison. DBIDE, a hack that I made with a different team at hackRU fall 2012, was extremely technically impressive, and that by itself projected us to second place. However, Merge wasn’t anything super impressive technically speaking. Moreover, as Mish Awadah put it, “I personally love the idea, but your problem is that it appeals to technically inclined people like ourselves. It’s going to be hard to capture the general public.”
My teammates and I agreed that a better way to come up with a clutch hackathon idea would be to take a look at the various API prizes being offered, using those as inspiration. Indeed, some of the best hacks were hacks that utilized sponsor APIs. This is because external innovation is much easier than internal innovation. In the business world, this is why large companies acquire start-ups; in the hackathon world, this is why top teams use sponsor APIs to hone and focus their stream of ideas. Every hacker knows a million ways to improve the world; however, since sponsor APIs are tried and true, using them to spark the idea generating engine increases the ratio of strong ideas to weak ones.
As a final point, using a sponsor API lets you spend more time making an impressive hack and less time hand-rolling your own technology from scratch. Remember, time is valuable!
Familiarity with the technology
As implied earlier, Jeff knew only Objective-C, Ashu knew only Python, Teddy knew neither, and I knew some Objective-C and little Python. Admittedly, the Python was not a hindrance for me. Since I’m fluent in Ruby, I was able to pick up Python on the fly with little hassle. (Think of it like a native Spanish speaker learning Italian or Portuguese.) However, while my iOS knowledge helped me debug a couple of things in Jeff’s code, such as consistency in our hand-rolled TimePicker, the brunt of the iOS work was still up to Jeff. He essentially wasn’t able to sleep because we were relying on him to construct the mobile app.
For the future, our team should use technologies that two or more people are fluent in. I would like to see this solely because it would allow for us to cycle in our sleep, thus using all 40 hours to code. Hypothetically, Jeff could have coded the iOS part for 4 hours, then napped for 4 hours while I took over. Ashu and I essentially did this for our Python API, and it worked very well.
Moreover, we ran into some serious issues integrating Facebook into our iPhone app. Despite the fact that Jeff and I had both used the Facebook SDK before and we had both acknowledged that it was hard to use, neither of us had thought to practice with it before PennApps. As a result of our collective short-sightedness, we lost precious hours trying to make things work.
I love my team and everyone on it. I look forward to working with them again; they’re all great, talented guys that bring something different to the table. However, I think that we suffered from confirmation bias as a result of our Electioneering hack. We didn’t think that Electioneering was done well or an especially good idea, so we kind of assumed that we’d just kill it out of the water with Merge, a more marketable idea with a prettier UI. It turns out that we definitely missed some things that hindered our extrinsic success at PennApps.
At the end of the day, though, what’s important is the intrinsic success that we derived. Not only did we encounter obstacles we’d never seen before, but we all learned a LOT about the nature of hackathons and how we can become better programmers as a result. Even though I said that we’d failed at meeting all of our goals for PennApps, that doesn’t mean we failed. I suppose that, to quote Jim Lovell of the Apollo 13 mission, this was definitely a successful failure of a weekend.