By Kirsty.Cooke
Taking part in a hack day? As we have recently emerged, triumphant but tired, from a pretty successful hacking event, the FusePump team are pleased to present this handy guide for hackathon victory…
1. Know your client
The FusePump Hackathon was carried out in partnership with an existing client, Chain Reaction Cycles. (We used their data to come up with a new digital marketing solution for them.) This meant that a few hackers were already familiar with the basics – what they sell, what their business model is like, and what their needs might be. Those lacking knowledge of the industry struggled more: trying to quickly get to grips with a whole market isn’t easy, but should be your starting point in any hackathon.
2. Read the brief… carefully
Carefully peruse whatever documentation you are given. Even if you believe you could not be more familiar with the client, the data set, the available technologies and the format of a hackathon, there is no harm in double checking the scope of the task to ensure you are meeting the right criteria and know what is expected of you.
3. Work within your time limit
Set mini deadlines and try to prioritise tasks. Most hackathons are over in the proverbial blink of an eye (ours was over in 24 hours) and you need to set aside time to come together as a team near the end and tie up any loose ends (as well as time to eat, sleep, and step away from your monitor). Good time management and timely submission of materials may also count towards a better ‘score’.
4. Operate as a team
Our Hackathon involved everyone in the company, with teams made up of everyone from PHP developers to account managers. In a team event, it’s a good idea to have a leader who candelegate tasks according to people’s strengths – rather than have the team try to work at everything together. “But don’t be afraid to ask for team members’ help,” said one FusePump hacker. “This way you are more likely to make the solution look fantastic, but also have it built on time and to a high standard.” Our winning team actually set up an issue-tracking system to keep them on track.
5. Acquaint yourself with the judges
Becoming chummy with them is ideal, but we’d settle for vague familiarity. It’s handy to know what the judges are like as well as what they are looking for. Our judging panel was comprised of Rob Durkin (our very own CEO), Rich McKnight from Chain Reaction Cycles (a client) and Matt Baileyfrom Performance Horizon Group (a partner). So we had to demonstrate working knowledge of our own company platforms, the client’s data and needs, and the wider performance marketing industry. Basically, there was no room to hide.
6. Focus on building a minimum-viable product (MVP)
Once you pick up your tools, you should think about building something that works. Live demos are always risky, but a demo that actually works will have a far greater impact on judges and audience members. Spend time on the functionality you know you’ll need, and don’t waste time on extra features that nobody will see. “Prioritising features is just as important as thinking of them in the first place, but it’s much more difficult,” commented one hacker. “Write down all the features you want and then throw half of them away. Perhaps start by laying out a story map, to get your thoughts organised.”
7. Remember: the pitch is as important as the product
It’s great to have an impressive working demo, showcasing an innovative solution to a relevant client challenge. But there’s no point in making something brilliant that nobody realises is brilliant, because the pitch hasn’t been properly prepared. Think about the key things you want to communicate, and in what order – the features, the benefits, the costs, the challenges, the business case, and so on. And only use your best ‘speaker’ if they have a good understanding of the overall project.
8. Don’t spend too long making things beautiful
We all want to deliver polished products backed by well-architected, high-performance code (and a battery of unit tests). However, trying to cross every ‘t’ in a 24-hour hackathon is a risky approach. The judges might overlook a button in the wrong place. They probably won’t delight in seeing a demo of a login page (even if it’s the prettiest login page ever made). This applies to back-end code too: you don’t need to build a fully-configurable system from scratch.
9. Research APIs and frameworks before you start
So you’ve decided to build a great new integration with a third party site. Do they have an API? How does it work? History is littered with great ideas that didn’t quite work in practice: make sure your idea is technically possible before you start. Is the API going to make your life difficult, or does it offer features that might save hours of development time?
10. Start with the end in mind
There’s been a lot written about the benefits of top-down or bottom-up approaches to software design. One thing to be really clear about is what you’re trying to make. Our coders suggest you might want to think about methodologies like TDD or BDD in order to make sure you’re always working towards the right goal.
11. Don’t reinvent the wheel
Wheels already exist! When time is tight, you need to make use of out-the-box solutions. Get a head-start by reusing code that other people have written. You don’t just save time in the writing of code: you save time designing it and testing it too. Use frameworks like Bootstrap and Zend, and remember PaaS and SaaS. Stitching together some third-party platforms in a new way might be the simplest way to develop an innovative new idea, and will certainly reach the market a lot quicker.
12. Don’t forget version control
Everybody makes mistakes. Version control means you can forget they ever happened. Hacking doesn’t mean slacking: you’re free to work on what you want, but don’t leave your tools behind.
13. Take a lot of breaks together
You don’t want to get bored of looking at the same thing, and it is scientifically proven that regular breaks help boost productivity, creativity, and the likelihood of top marks. Moreover, team lunches helped us galvanise our project groups, so we worked better together.
14. …but don’t eat or drink too much
Binge-eating Papa John’s Pizza on the Thursday evening may have left some of our hackers feeling too full to code. And, while beer is a terrific social lubricant and master key to the unlocking of great ideas, we do not advocate over-indulgence.
Join our TechMeetups London Hackathon #TMUhack @London, United Kingdom
