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

High Availability and Automatic Failover in Hadoop Hadoop in Brief Hadoop is one of the most popular sets of big data processing technologies/frameworks in use today. From Adobe and eBay to Facebook a...
How the Right Tech Stack Fuels Innovation – The Innova... On this episode of The Innovation Engine podcast, we take a look at how choosing the right tech stack can fuel innovation in your company. We'll talk ...
The Road to AWS re:Invent 2018 – Weekly Predictions, P... For the last two weeks, I’ve been making predictions of what might be announced at AWS’ upcoming re:Invent conference. In week 1, I made some guesses ...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...