Attending HackTM was much like writing this article: in the few hours before both, I didn’t know what I was going to do or how I was going to do it.
When it came to the HackTM kickoff, I didn’t have a team or a project idea, and was realizing that my programming skills are fossilized, to say the least. I’m a Software Business Analyst, so I figured that my best chance at success was to come up with an idea to pitch that would hopefully catch someone’s interest.
Brainstorming is easy with no limitations; I managed to put together a short list of items that I feel strongly about: snow, sports, and technology. Coffee did the rest.
I said to myself that it had to be short, “easy,” and telling: “…we’re going to build a Snowboarding Trainer. We’re going to do this using four Force Sensors placed inside the two boots, and an ElectricImp for data gathering and processing. We’ll then instruct the rider to lean left, right, forward, and backward in order to maintain balance while riding on the snowboard’s edges…”
That “we” I kept mentioning during the pitch turned out to be a group of 3 students from Electronics and Telecommunications with strong electronics knowledge and some programming skills that were way better than mine. I was more than happy to have a team. This was the first value increment I drew from this event (Yes, I was set on running this show the Agile Way).
I had already asked a colleague to lend me the sensors and I already had the ElectricImp micro-controller, so we were all set. We were going to receive the sensors on the second day, so our team spent the night after the kickoff getting to know each other, planning the project, and doing the scaffolding.
Morning arrived and with it, our sensors! Our imagination broke loose. For a brief moment, we were derailed by trying to define a solution that was far beyond our target MVP. We had to hold back our thoughts and focus on what’s important: read the data from the sensors, develop the planned scheme, and do the wiring.
The single most important problem we faced was reading the sensor data – we were receiving chaotic inputs and we didn’t know the reason why. When playing around with new hardware/technologies, even the simplest problems can cloud your path; however, when you’re surrounded by tech-savvy resourceful mentors and participants, it’s easy to carry on. The advice that saved us came from a mentor who immediately spotted the missing piece in our circuit schematic.
We had our first demo-able POC (Proof of Concept) early in the evening.
There’s a temptation to stop working once you reach a demo-able state. There are transparent improvements that can be made, which won’t have a direct impact on the demo solution. But in our case, these made all of the difference for the presentation. Had we not spent the night calibrating the sensors and improving our code, we wouldn’t have been that enthusiastic or confident in our solution.
The next morning, before pre-judging, we spent time on marketing activities. Imagine this post without any photos – that’s how I saw our solution. The bow on top came in the form of a real snowboard.
A few more hours of sensor-tweaking and dealing with the closer-to-reality environment and we were ready.
It helps to know the jury’s rating criteria and what they place value on. Try to mitigate the risk of a non-working product, even if it means descoping your presentation. In a three minute demo, there’s no time to get into many technical details, so prioritize the ideas you want to share and rehearse.
What I made of this hackathon:
We live in an age where technology has opened a boundless spectrum of possibilities. It’s our role to make sure that innovation comes with a true sense of value that will enrich people’s lives!
P.S. – Stay tuned for “Snowboarding Trainer v2.0,” a wireless, snow-ready prototype.