Life’s Too Short to Hack Alone: My HackTM Experience

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.

The Pitch

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.

hacktm1

The Hacking

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.

hacktm2

 

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.

hacktm3

 

A few more hours of sensor-tweaking and dealing with the closer-to-reality environment and we were ready.

Sprint Review

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.

hacktm4

 

What I made of this hackathon:

  • Collaboration is more valuable than competition
  • What you learn/develop during the event is more important that what you exhibit
  • A hackathon is very different than a programming contest – understanding its context is the key to succeeding
  • If you’re not having fun, you’re doing it wrong
hacktm5

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.

 

Daniel Markovits

Daniel Markovits

Business Software Analyst

Daniel Markovits is a Business Software Analyst in 3Pillar Global’s Timisoara office with a background in software development. During his transition to the area of business analysis and development, he developed a strong affinity for agile methodologies and a passion for innovative approaches to product development.

Leave a Reply

Related Posts

4 Reasons Everyone is Wrong About Blockchain: Your Guide to ... You know a technology has officially jumped the shark when iced tea companies decide they want in on the action. In case you missed that one, Long Isl...
3Pillar Recognized as a Leading Experience Designer by Forre... Fairfax-based product development company named to its second Forrester report in 2018 FAIRFAX, VA (June 18) - Today, 3Pillar Global, a global cust...
3 Cloud Optimization Projects That Will Pay for Themselves i... AWS introduced 1,430 new features and tools in 2017, including 497 in the 4th quarter alone. This means that it can be a challenge for even the mos...
The Connection Between Innovation & Story On this episode of The Innovation Engine, we'll be looking at the connection between story and innovation. Among the topics we'll cover are why story ...
Go Native (App) or Go Home, and Other Key Takeaways from App... I just returned from my first WWDC. I feel like I learned more in a week at Apple’s annual developer’s conference than I have in years of actually dev...