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

How to Manage the “Need for Speed” Without Sacri... The pace of innovation today is faster than it has ever been. Customers are much more active and vocal thanks to social and mobile channels, and the c...
Determining the First Release The first thing you release needs to put the solution to your customer's most important problem in their hands. Deciding what the most important probl...
The Art of Building Rapid (and Valuable) Proofs of Concept Clients and stakeholders want results. They want assurances that their investment is well spent and they're building the right product. The software d...
Are You Doing Stuff or Creating Value? You can put a bunch of stickies on the wall, create tons of JIRA tickets, and commit lots of code, but are you creating value? Is the work your produc...
Costovation – Giving Your Customers Exactly What They ... On this episode of The Innovation Engine podcast, we delve into “cost-ovation,” or innovation that gives your customers exactly what they want – and n...