Hackathons Make More Sense Than You Think
Join the DZone community and get the full member experience.Join For Free
“to make good software, requires lots of thought, trial and error, evaluation, iteration, trying the ideas out on other users, learning, thinking, more trial and error“
What he misses is the fact that most of the time hackathons do not have the purpose of producing ready-to-ship solutions. If you look at it from a developer’s perspective, a hackathon is nothing more than a demonstration of one’s skills and abilities, applied in a context of a platform or toolset – with a limited amount of time to think of an appealing solution.
My first hackathon experience was the Kinect Code Camp, that was held at the Microsoft campus in Redmond, WA. Me, Adam Kinney and Rick Barraza – a team of three developers (Adam and Rick obviously with more experience than me), were supposed to think of a solution that would demonstrate what the Kinect for Windows SDK could do, all in 24 hours. We , obviously, not the only team there.
As the event came to an end, I realized that it was an amazing experience. Here are just a few of the benefits I gained from the above said event:
1. Communicating with people who have more experience than you – that is a perfect case where I was able learn as much as possible. My train of thought was not even close to that of people who build tens, if not hundreds of projects that target various types of users. I was able to see how a lot of my initial ideas were not as good as I thought, and I learned as much as I could to improve my skills and development practices.
2. Thinking quick – with every minute counting, we didn’t have too much time to dedicate to planning a solution. And although this is not something that you could apply to day-to-day products, fast thinking might become handy when you need to quickly build a solution that will serve as an addition or a bug fix to an existing product. When a client requires a quick stock viewer by the end of the day to keep track of the latest trends, you won’t have hours to write the design document.
3. Envisioning concepts – we were building a proof-of-concept product that was designed to connect Windows Phone and a Kinect-based application. Obviously, there were bugs. More than that, an hour before demonstrating the project we built a list of things to do to make sure our server and client applications wouldn’t crash, since we were aware of cases where the whole communication flow will break. Could we fix it? Of course, but it would take some time and we didn’t have it. The solution crashed anyway, right before our demo (we managed to fix it, though), but we got it working again and the presentation went great. The solution we created was not even close to being perfect, but it demonstrated a working concept that is quite exciting.
4. Keeping the focus on a task – again, with critical time constraints, there wasn’t much time we could dedicate browsing social media and/or news outlets, if at all. We focused on coding, testing, and coding again. We needed something that worked and there was no time for entertainment.
Dave also mentions:
“[software development] It's not an art where you can observe the creative process, because that goes on inside the creator's head.”
This was, again, proven wrong during the Kinect hackathon. It is extremely interesting to see others people code and test their products – I was able to see what tools other people use and what approaches they have to organizing their solutions and the development environment. That goes as learning baggage for someone who is still a developer that codes for fun, like me.
PS: Hackathons are awesome.
Opinions expressed by DZone contributors are their own.