Learnings From HACKAGONG

Last weekend, I participated in my first Hack-A-Thon activity ever, and placed ‘Top 10’ along with a couple of friends. We also were awarded the apparently afterthought prize ‘Most Unexpected Product’ for an Internet Controlled Fondue Machine. As a mid-career Electrical Engineer, who has been in the ‘Maker’ community most of his life, I thought I would share my experiences, and offer some suggestions on how to success in Hack-A-Thons, such as HACKAGONG.

I am not associated any way with the event, and have not spoken to the judges, but I did see a lot during the event, learning a heap of what to do, and what not to do.

About Me

Before I start, I should tell you a bit more about me, and why you should listen to me. As you might be able to see, I operate the Redshift Wireless startup, but this is not the first one that I have started, or worked for. I have seen some succeed, and others fail. I spent the first 13 years of my career working for a large organisation, and then a smaller organization, without changing employer – the organisation went from about 13,000 people when I started to about 230 when I left.

I love to build stuff. My second ‘C’ program was a graphical operator interface to control a 1,000 MW power station in 1991. I built a GPS tracking system for media helicopters for the Sydney Olympics. I built GPS tracking scooters for Hollywood with Maya integration, in 2001. I have built a collision avoidance system for gliders. I have built a two seat aluminium plane with my best friend, and taken it to Perth. Twice. I worked on Half Duplex Spread Spectrum Data Communication for my Uni Thesis back in 1994/5 – something that is now called WiFi. I am on the board of a Wireless R&D group in the USA called TAPR, who released one of the worlds first Open Hardware Licensed (The TAPR OHL), and which has been doing Kickstarter like campaigns since the 1980’s. And on the same weekend as HACKAGONG, a paper I co-wrote won best paper at an international Law conference! Closer to home, I have been quoted in *MULTIPLE* Senate reports in Canberra.

Observations on Hackagong

As much as anything, for me HACKAGONG was a marketing and networking exercise for Redshift Wireless – basically Redshift Wireless *IS* me, along with some freelancer Indian programmers. The whole idea was to build up my network and have fun.  It has been really successful at helping me there. To be clear, we did not win the main prize, or any of the category prizes.

One of the things that struck me about the event was the demographics of the teams. University aged people were obviously the highest proportion of the candidates, with fewer attendees as people got older. There appeared to be a couple of teams where a parent was involved, but generally teams were very young. If you look at the Top 10 and the winners, many of the winners had people with some life skills. Grabbing someone with life skills for your project will likely help.

Define Your Project

This is probably the most important thing – it is more than having a concise achievable, as will be described in a moment. It is what problem are you trying to solve, and how are you planning to do this. Develop the project, and validate it. Compare it to similar things, and prove to yourself why it is different, and why you should do it. You should be able to walk into the event with a plan of what you want to do, and how to achieve it.

Sure, you may not have a team when you turn up, or may need more team members. That is not a problem. Have a plan in mind! Be prepared to change the plan at a moments notice, but start with one.

Have A Concise Achievable In Mind

Some people might describe this as ‘What Problem Are You Trying To Solve’, but this is slightly different. It is more looking at the solution side rather than the problem side. For the Internet Controlled Fondue, this was ‘Turn the Fondue On and Off, and tell me how much power it is using”. We then wanted to build a GUI around a business model. The hardware and firmware were complete by 1PM on the first day.

A less well defined achievable would be ‘I want to make this remote control car do cool stuff’. Without a specific goal in mind, getting there will be difficult. You can start with this, but but you should try to define things as early on as possible – even before the event if you can. You may need to change direction once you start, but at least you have a starting point.

Know How You Are Going To Achieve This

This comes down to some skills that are going to be less developed in most attendees given the demographics – project management, people management, time management and deliverables management. As a general rule, people get better at these things over their career, at least until you turn 30 and become a grumpy old man.

This comes down to planning. Before you start your computer, think about these key tasks. What tasks need to be achieved, how long will they take, and who is best skilled at doing them. And if people run into trouble, or cannot make the event, who else can do those tasks?

I am sure that students and graduates will know all about the methodologies that can be used – although I recommend against trying to use a two week sprint on a weekend long event. Something as simple as giving responsibilities to different technologies to different people with defined deliverables.

Often this will be made easier by using well defined interfaced. In our project, we defined walking into the event that we were going to use HTTP GETs/PUTs for control and monitoring of the hardware, and had these fully defined by 11:30am on the first day. Once this was done, I could work independently of the software guys, finishing off the firmware.

 

Have Backup Plans and Stretch Goals

On the first day of the event, there were some challenges with the Internet. To a certain extent, these issues were evident throughout the weekend, depending on what you were doing. The eventual winners started off with one type of hardware interface, and found that it was not working reliably, and then moved to another device which worked a lot better. There were still challenges, but they managed to get their product completed in time.

In their case, they had not had the opportunity to work with the backup technology before, but managed to get things done. I on the other hand had similar issues with the hardware, and decided to supply my own internet to fix the issue via my phone. As a backup, I also went home rather than staying overnight so I could pick up backup hardware should it be needed.

On one my failings is that I did not have a stretch goal.  I completed my hardware and firmware work, and really did not have too much to do – I worked on some business type work for the Web Site, but in general all I could do from then on was support my team mates and assist other teams as needed.

 

Be Familiar With The Technology Before The Event

Whilst mentoring or talking to other groups, what I found in a number of cases was that they were using technology that they had never tried before. Whilst a Hack-A-Thon is a great way to learn, you will probably be more successful if you have spent some time on the technology before the event. This way, you are spending precious time to develop rather than learn. Using several unfamiliar technologies together is a recipe for disaster.

I met with one person who was really struggling with two new pieces of technology from an area outside his discipline, and he had no idea where to go next. He was out of his depth, and then having some issues with the technology misbehaving too. In that case, I looked at what he was trying to achieve and realized that an experienced engineer could spend a week to try to achieve what he wanted. In the end all I could suggest as a backup project, which allowed him to move forward.

You will not always get the chance to deal with the technology beforehand, but if you can, do it. Technology such as the Meta augmented reality glasses are in short supply, and the Spark modules arrived the day before the event, but there are generally ways you can get up to speed.

 

Marketing

Let’s face it – we are mostly builders, not marketers. But to be successful you need to sell the idea, and that takes marketing. In our case, we knew that Electric Hot Water was going to be a really low engagement product. The only time most people think about it is when there is none left, or when the bill comes in – and in either case it is a negative experience. Being able to demonstrate heating large amounts of hot water become problematic, particularly since most hot water heaters store hot water for a period of longer than the hackathon!

So we decided to make the product fun and engaging, using Chocolate Fondue rather than hot water. It gave a heap of advantages to us. It permitted us to engage with the judges and organizers in a way that would not have been possible otherwise. And it became a tool to create some buzz on social media.

Marketing also looks at the size of the potential marketplace, and what drives those people. These are things that are valuable in planning an execution. We actually surveyed people at the event asking  them about hot water. Most people had no idea how much they paid, but knew it was too much. This research can be fed into judging.

The Video

We were asked to produce a three minute silent video ‘with no edits’. The idea was not to waste time. If I was to do this again, I would make sure I had a lot more time to spend on the video, and use it as a tool to explain the concept whilst I was presenting. If this meant bringing in another team member, I would do it. I am not sure what the organizers would say, but having that extra person working on the creative parts can help.

 

Be Interdisciplinary

The most successful projects were ones that crossed functional areas. The winner had Internet Of Things, Cloud Software and 3D Printing. Most of the IoT projects contained 3D printed elements – I think we were the exception rather than the rule not using 3D Printing. In our case there were legal and safety reasons not to, which should have been explained to the judges. Going into different areas extends the reach. The more successful META Augmented Reality projects looked to be the ones that joined the real world with AR – where there were subject matter experts with technology experts. Our Top 10 project was the same.

Judging

The Judging process starts several hours before the finish of the event. Managing this process can be interesting. One strategy is to stage releases of your product, with development continuing but with a demonstrable project at any time. Another is to decide that the event finishes when the judging starts. What you do is up to you.

One thing I would recommend is researching about the sponsors and the judges. Know what each company does, and what they do. Read the bios of any of the judges if possible, and find out what they are interested in. One of the things I heard from the HACKADAY Prize judges was that so few had researched their interests – and those that did performed somewhat better. This is like studying for a test.

Work out how to present to judges. If you have time, storyboard your pitch. One thing I have seen a lot in business that detracts from things is when one person is giving a pitch with a plan in mind when a colleague buts in and reveals information at the wrong stage. Many times, the pitch is actually a story and conversation with a logical flow. What is the problem you are solving, what have you executed, and then give a demo of the solution. The order can change, but the plan needs to be there.

During judging, manage personnel properly. Make sure that there is always enough people at the project to totally demonstrate the product. If not, make sure no one is there – it gets embarrassing when you have to say to a judge that you would love to demonstrate the software but have no idea how.

Self-Evaluate

Before you show off what you have done, pitch the idea to yourself. Assume you are a smart person without a huge amount of background knowledge – how would you rate your project. Then look at the judging criteria, and ask yourself what your execution is like. What can you improve to make things better. Judging your own project, while not ideal, does permit you to ask yourself the right questions.

The next stage might be to ask for someone one a nearby table, or one of the volunteers to look at your project and provide feedback. Of course, they might be on deadline, but sometimes there are people who would rather do anything other than coding, and pointing out issues with your entry might be just the distraction they need. Since the judges tend to be older, it might be wise to make sure older people are asked the questions

Judging Criteria

See if you can work out what the Judging Criteria is going to be. Various contests have different requirements. In some, such as the Hack-A-Day Prize, had openness as a criteria. People that published their designs got higher marks than those who did not.

I did see the Judging Criteria sheet briefly after the event, and the process made a lot more sense once I saw the headings. One word stuck out at me. It was EXECUTION. But I will get to that in a moment.

If I were going to judge a competition like this, I would likely use something like the following:

• Concept
• Execution
• Feasibility
• Future

Concept is the idea itself – what are you trying to do, and why. Is there a problem you are trying to solve. For a video came, this is the idea behind the game. For hardware projects, this is the capabilities of the hardware. Think about what the judges will be looking for, and how to explain your concept to them.

In my mind, Execution is probably the most important thing. Concept is just an idea – execution is how you met the goals. Have you actually met your goal of producing something? The judges don’t really need to know that you wanted to put in extra three graphs on the UI, they want to know what you have working now in this section. Sure, they would love to know how you want to extend this given the time, but what have you managed to deliver.

In this respect, a fully functional basic interface may well be better than a poorly designed and partially implemented advanced interface. The judges know your limitations on time and know there are probably lots of things you could add. Have some vision, but concentrate on what is there now. You need to be able to tell a story with the User Interface.

Feasibility includes how likely the thing will be to perform well in the marketplace. Are your financial numbers reasonable? Are there major limits on the success of the product? If you develop for a very small proportion of the community who then needs to purchase some expensive hardware then this is likely to have a lower feasibility than something with a large market, low total price and low competition.

Know what the next stage is for the project. Is it a once off, or is it the start of a new business. Either are acceptable answers, but you need to be able to provide an answer and a bit more information. Be certain of yourself, and be able to articulate a vision.

Preparing for the Top 10 Pitch

If you think you might make the Top 10 it makes some sense to prepare before hand. In my case, I typed up my presentation at 5am on the Sunday morning before heading in for another day of cool hacking. In this presentation you have about three minutes to define the product, describe what you did to solve it, making the case why your project is special. The person who does this pitch really should be the person who can best talk about the product and think on their feet.

In three minutes you cannot get bogged down in the details – it has to be a high level overview. If you look in the photo I have a folder in my hand – on top was typed notes that I mostly did not need to use.

What I found looking at some of the pitches is that some people were not able to concisely describe their product or what the base problem was. The products who won tended to be the ones who were better at marketing their products [Hey, there is that word again!].

When asked questions, take very careful note of not only what the question is, but also what is driving the question. Some people have the innate ability to zoom in on a particular area where you or your presentation are week, and ask questions based on significant knowledge and experience. Work out how to deal with these questions – do not get flustered, but take it as the opportunity.

Probably the worst case would be if a question has issue with a core foundation of the product. If this is the case, and you don’t have a suitable answer, saying ‘That is an interesting thought – we will look into that further before we release onto the market’ might be better and permit a question that you can answer well.

Financial Basics

If you are using this as a pitch session, be prepared to be asked about financials. I will not go into too much detail, but there are a few facts that people should know:

• As a consultant, you can only ever effectively get paid for about 1000 hours work a year, after annual leave, sick leave, long service leave, public holidays, marketing, periods without work etc. That means if you want to be paid $120k, you need to be bringing in $120/hour. Any expenses such as office expenses are additional.
• If you make a retail product, expect to get about 40% of the retail price, or even less. Therefore, if you want to sell a product for $50, you need to sell it to wholesalers for about $20. The cost of the product including all expenses – support and marketing included must come into the $20
• Many many many Kickstarters go broke not charging enough. In some industries, charging more actually increases sales

Sometimes there are alternative ways to charge for your product. Paying by the month can work for you

Have Fun

The biggest advice of all is to have fun. The event is not designed to be horrid – it is designed to make you want to arrive early, and never leave. They provide food, drink, showers and T-Shirts so that there is no reason why you would ever need to leave the event, until they security kicks you out at the end. But be careful with the fun – I think I came close to breaking my leg trying to deflate my ‘Most Unexpected Product’ prize

More Information for people who love Embedded…

For those software people wanting to interface to hardware, there are some interesting resources available in PodCast form. I would personally recommend Elecia White’s Embedded podcast, and Chris Gammel and Dave Jone’s The Amp Hour. The former is more from a software person who wrote ‘Making Embedded Systems’ for O’Reilly and who knows that ‘motors can catch fire’, and the latter is more from a hardware perspective. Both are great at helping you know at least what you don’t know. At least with Embedded, go back to the start and listen to every one in order.

Anyone wanting a piece of fiction about hacking software and hardware should probably read Andy Weir’s The Martian. It is about to be made into a major Hollywood movie!

And if you want to find more about me, you can check out the following Web Sites – Radioactive Networks, The Crazy Engineer and Redshift Wireless. Redshift Wireless  ‘Makes Almost Any Air Conditioner Smart’, by replacing the Remote Control with a WiFi based device. Please contact us if you know anyone who might be interested.