Four Tips for Building Hackathon Demos
Simple ways to help you deliver results when you’re under a tight deadline.
--
Hackathons are a buzzword, and while you always hear about the advantages of building a product quickly, there’s not a lot of conversation about what it takes for a team of developers to build a successful demo in a short amount of time. From my experience, here are four things that successful teams do to create working software in 24 hours.
1. Setup your computer environment before the hackathon.
If you’re going to use cloud hosting, set up the account and any required software before the hack starts. Pre-determine what kind of source control you’ll use. Give your team a code name and use that for namespaces. The last thing you want in a hackathon is to waste the first half of the time setting up your system.
2. Make assignments clear and transparent.
It’s crucial that your team members know at all times what he or she should be working on. Draw a high-level architecture diagram of what the team is making, and then ask each team member to write his or her name next to the pieces they’re building. This helps keep the entire system visible to all team members and helps each team member understand what others are working on.
3. Separate your code based on the developer.
Building something in 24 hours is all about working in parallel, so don’t get hung up on consolidating files. If you’re using a common framework, lock that in upfront (see tip #1), but plan to keep your classes and customizations separate from others’ work. Front-end developers shouldn’t be afraid to have their own CSS or JS files. I know this goes against many developer’s instincts and best practices, but at 5 AM you’ll all be exhausted, and the last thing you want to do is waste an hour tracking down conflicts or overwriting a teammate’s work. Always remember there will be plenty of time to refactor after the hackathon.
4. Write a script for your product demo, and prioritize all development around that script.
Hackathons end with a live demo where your project will be shared publicly for the first time. So make it count. Having a team member write out a user journey that will act as the product demo is a good way to keep structure around your idea and prevent it from ballooning out of control. The user journey also acts as a focal point for prioritizing what will actually be built. If a feature is part of your idea but not in your demo, don’t build it. If you can’t build all the features in your user journey, then eliminate them from the story or create a static mockup showing what will happen.
Best of luck, I look forward to seeing what you build.
