Hackathons can be a good change of pace for us developers because they force us to experience software development in a different way. At our day jobs we often work on a feature for weeks, because it needs to meet complex requirements that are often subject to many unknowns and last minute changes. But a hackathon can make it possible to implement not just one feature, but an entire prototype, or minimal viable product, in a day. It depends on how the hackathon is run, and just as much on preparation of the teams.
If your team has the right skills, or at least has researched in advance how to implement various moving pieces (for example, OAuth authentication using your chosen programming language), then a hackathon can give you a concentrated dose of accomplishment you often don't get at work. But if you approach a hackathon unprepared, and have to research those technologies as you're trying to use them, you will just spin your wheels. You might waste that day just scratching the surface of technologies you may or may not ever use. (I doubt that most projects started at hackathons ever get worked on again.)
Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari. More pictures from SheHacksATX are in my photo gallery.
At SheHackATX, a women-only hackathon that took place on April 26, 2014, teams had not been formed upfront. Developers were matched with projects at the beginning of the hackathon. Each project was a woman-run startup (most of them local to Austin) that needed programming help, such as to add some features to their app or website. In the morning, developers wrote down their preferences of apps to work on, and the owners picked programmers they wanted on their team. Hopefully everybody got at least their 2nd or 3rd wish.
Since the teams were formed on the spot, they could not coordinate and learn complementary skills in advance. So it was all the more impressive that half of the teams were able to accomplish the tasks that startup founders wanted in the the time provided (from around 12 to 7 pm of one day). Those startups were Girls Guild, Groove, Yoga Recipe, and Bound Round. In my opinion, they were successful because their founders were able to correctly estimate tasks that might take about a day, and went with small'ish, manageable enhancements for their applications; nothing grandiose.
An example of that would be Girls Guild, a website that matches girls who want to learn hands-on skills (e.g. chocolate making, jewelry making, leather working or photography) via apprenticeship, with "makers", i.e. experts in that area. Both the makers and the apprentices are girls or women. One of the features Girls Guild founders wanted to have added to their app had something to do with being able to delay a payment until another event occurs (the details escape me). They also wanted ability for a maker to schedule interviews with a prospective apprentice through the website, as opposed to a manually emailing back-and-forth. The Girls Guild team succeeded in implementing both features.
Girls Guild and Hearth teams at work. Sitting at the table, left-to-right: Bethany (developer), Diana and Cheyenne (Girls Guild founders). Standing behind them, the Hearth team: Nari and Monisha (developers) and Florence (founder). More pictures from SheHacksATX are in my photo gallery.
Bound Round coders didn't have time to implement a 3D spinning globe (in Javascript, I guess) that the owner wanted, but they implemented a zoomable map that shows different levels of info depending on the level of zoom. Quite impressive for such a short time. Yoga Recipe wanted to integrate their website with Facebook, Twitter, and Instagram; "integration" meant ability for yoga instructors to share the "recipes" (sets of instructions for yoga classes) on social media. They succeeded with Facebook and Twitter. They also implemented ability for yoga teachers to put together playlists for their classes using Spotify.
My team also did well with our application, Groove. More about it in the next blog post, where I'll talk about what we did and how we did it, highlighting the obstacles that a programmer might experience during a hackathon.
Some other startups set their deliverable for this hackathon to be not code, but ideas. The founders of Our Desired Future and Hearth came here with just some ideas for their websites -- some better hashed-out than others -- and asked for technical advice on how to best implement them. Our Desired Future wanted to put together a series of multimedia presentations to tell interactive stories about water usage and water resources of Texas; in case of Hearth, what the owner really needed was to winnow down a number of her eclectic ideas about promoting volunteering through gamification, to something that could serve as minimum viable product. The result of her brainstorming with her team was a landing page for the website. In the process, one of the people on her team concluded that her calling in life was product management. So in these two last cases the product wasn't tangible; the real product was refinement of initial notions into more concrete ideas.
Posts
