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.


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.



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.

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.



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

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

3Pillar Recognized as an Experience Designer In Report by In... Fairfax-based product development company named to its second report in 2018FAIRFAX, VA (June 26) - Today, 3Pillar Global, a global custom softwar...
Why You Need Automated Testing to Reach DevOps’ Holy Grail Automated testing is required to reach DevOps’ Holy Grail - continuous deployment. Despite what you may have seen in Indiana Jones and the Last Crusad...
AI, Chatbots & Natural Language Processing: The Present... For this episode of The Innovation Engine podcast, we take a look at what the future of digital healthcare may hold for both patients and providers. W...
Should You A/B Test? First of all, what does A/B testing mean? A/B testing starts when you want to be sure you're making the right decision. Simply put, A/B testing is c...
Change Blindness in UX There is a strong discrepancy between the amount of information being transmitted and the amount of information our brains have the capacity to proces...