Sunday, May 18, 2014

24 Hours of Le Google (GovDev Hackathon)

1:30 AM - After two-thirds had gone to bed or given up

24 Hours of Le Google

I would imagine it's similar for most budding developers.  Their first endurance hackathon is an eye opening experience into the world of professional software development.  It's more a la Formula 1 than nerds (me included) lapping between their computers, pizza slices and empty Red Bull cans, as mainstream media or even my own pre-hackathon imagination would depict.  So what might you expect?

Off to the Races

Enter Galvanize Denver, the venue of 24 Hours of Le Google (GovDev Hackathon), registration booths manned with pre-printed name tags, free Google swag (t-shirts and water bottles), staff in matching orange shirts, Google colored race banners streaming the ceiling, catered breakfast, and in the main room... the horse and pony show.

Teams arrived with matching computer terminals, small tables packed with 27 inch Apple iMac's paired with 27 inch Apple external displays.  The most impressive team having four such stations all packed into a small table.  Many teams were split into 'pit' duties, the UX guy, the backend guy, the frontend guy, the mobile guy, the project manager ('guy' in the general, non-pejorative or exclusionary sense... some of these 'guys' were gals).  The air of competition was apparent. No one was too friendly or too talkative, they were all there to win.

Leading up to 'go time', there was a parade of who's who in state tech and Google big-wigs.  Talks from the CEO of this, the CIO of that, and the COO of the other, all sharing their ideas of why this was an important race and why what we were doing was furthering private citizen/sector involvement in making government more efficient.  They sold me, I was excited to be part of it (and still am).  After the talks came the challenges:  take this data, make it public and understandable to the layman; take these horrible relics of bureaucracy (repetitive paper forms), digitize and streamline them so that they're easy to complete on a mobile device and pass the completed product to all affected departments to streamline coordination; and finally, take this paper-based donation and dissemination program, make it mobile and seamless.  The last two challenges having to do with disaster response and preparedness, the first challenge dealing with government expenditures and transparency.

We Had no Idea

What started as a team of three (@FindingFixes, @ScottSkender, and I), had no idea the complexity of the tasks we'd been presented with.  We chose to take the challenge of making government expenditures transparent.  It seemed straight forward. Take these CSV files with a half-million line items and make it understandable to Jane and Joe Doe.  Create a filterable dashboard with charts, include map integration, and toss in a few Google API's to meet the minimum requirements.  Much to my surprise, our little laptops didn't like CSV files with a half-million lines.  They were too big!  And taking legacy data formats and converting them into usable content (like converting to JSON or importing into a PostgreSQL database) was more difficult than anticipated.  After 3.5 hours of hacking away (and getting nowhere), one of our members decided it was time to call it day.

And Then There Were Two

I'd had had it with this 'big data' challenge, it was more than I had bargained for and was a touch outside of our team's technical savvy.  So my partner (Seth Musulin) and I started on another challenge that seemed to compliment our technical chops.  The inventory management challenge to track donations and dissemination of donations.  It was to be a CRUD app of donation items, victims, and the donation items they'd been given (that's the superficial view of it).  After 3.5 hours of getting nowhere on the first challenge, having created a database table and an app that CRUD's donation items in the first 30 minutes felt like a huge accomplishment!  We felt as if we'd made a massive accomplishment... until we started understanding what else was needed. hahaha.  Now that our app can take in donations, we need to CRUD people, then we need to checkout these donations to people, then allow staff to search for donations by location, item type, donor, etc.  Easy enough, right?  Unfortunately, that wasn't the hard part.  While doing all that took our team of two until 1AM (having started at noon), we now had to make it work seamlessly from a user experience point of view... and... it had to look good.  But it was 1AM and having seen other teams nearly complete with some super-sexy, ultra functional, and utterly seamless apps... we knew there was no way we could get it done it time.  So my partner and packed our bags and called it a day.  Considering two-thirds of the original competitors had already left, I feel like we hung with the best of them... although our app surely didn't.

Lesson Learned

These guys take endurance hackathons seriously!  They plan teams where each person is a well-oiled, integral cog in a finely tuned software producing machine.  They don't play around.  They know their strengths and they avoid spinning their wheels on tasks that don't fit their skill-set.  For future endeavors, I'll be part of larger team with varied disciplines and I'll stick to what I know.  While it was a great opportunity to learn some new technologies, like Apache Solr (for fulltext and location-based search), and JavaScript location services, it was certainly not the venue to 'learn' if your intent was to finish and possibly even win.  That said, I'll do it again, and again... and again!  It was a great time, but certainly not what I'd expected.

No comments:

Post a Comment