A few weekends ago I attended the amazing Crimson Hacks Hackathon hosted on the campus of the University of Alabama. This was the first Hackathon event I have ever attended and had no idea what to expect, and my team members were in the same boat. This was a 24 hour MLH sponsored event where you had plenty of resources at your disposal for building what you wanted. Our team ended up taking 3rd place, as well as won a separate sponsored contest for “most disruptive hack”. A link to our dev post can be found here. Many unexpected things occurred within a 24 hour time span and I thought it would be good to reflect on the experience and try examining what lessons could be learned.
What We Did Right
Established MVP and Roles
The night before the competition we established exactly what we wanted to do for our project. We made sure everyone was on the same page as to what was going to be built and established what technologies where going to be used. Our project was to build a website in virtual reality and have the actual HTML generated on the client’s side, which you can imagine leaves room for plenty of features for styling and layout. If we set out to build all those features from the beginning for styling we would not have finished within the 24 hour time period. Instead we focused on the Minimum Viable Product. What does a website need to be a website? Styling is nice, but it sure isn’t needed to deliver content. We settled on allowing a user to be able to place images, text, and buttons in a column or row layout as our minimum viable product, leaving room in our JSON representation of the website for styling if we did get to that portion in the competition (spoiler alert: we didn’t). Once we had our MVP defined, and exactly how the user was going to interact with objects in the scene, we could properly define roles for everyone with exactly what they’re going to work on. As soon as the competition began, we knew exactly who was doing what and everyone could go full speed.
Well Defined Client-Server Protocol
If the product you’re building has 2 or more entities talking with each other (like our VR application and our server) it’s extremely crucial to formally define exactly when they’re going to be sending messages to one another and how that message is going to be structured. We ended up making a google doc and wrote out what the json would look like, commenting on each field within the object with what data it’s going to contain. We could then build an example website represented in the JSON we defined earlier to run tests against with the code we were developing. With the example website developed one person could work on taking it and writing a converter from JSON to HTML, and a different person could then be writing the code to convert was was being done in VR to JSON. Doing this kept developers from stepping on eachother’s feet the entire time.
Found A Freaking Good Tutorial On VR
This was my first time developing for the Vive so finding good tutorials on the technology was essential to being successful and finishing our idea. The kind of controls we were setting out to develop where not complicated, be it simply picking up objects and throwing/placing them around in different parts of the scene. A link to the tutorial we used here. The two things that made this tutorial good where:
- It’s in text and not on youtube. You can read through it as fast as you’d like instead of trying to seek through some video
- Plenty of code snippets as they go along for your copy & paste ninja skills.
Both these points have something in common, saving you time!
Places We Dropped The Ball
Not Researching Enough For Solutions Out There
When it comes down to implementation of your idea you need to do as much research as possible to make sure what you’re about to build hasn’t already been accomplished by someone else. The open source community today is amazing and makes finding what you need easy. One of our team mates spent part of his time writing his own C# Objects to JSON because we needed to have more control over what the JSON looked than what a general serializable solution we found would give us. After the competition was over we found a solution that would had saved him some time.
Not Defining A Demo To Work Towards
At the end of the 24 hours we felt amazing. We built a working project. We accomplished what we set out to do and it worked relatively well. Our first judge came up to us for us to demo and we fumbled. We didn’t know what to showcase first or how we were going to do it. As a result of this we ended up not getting our point across with what our product could do as efficiently as we could have. This would have been solved if we had created some user stories beforehand to build a proper demo.
Inadequate Clothing/Sleeping Materials
We didn’t all have warm clothes. Some of us didn’t even bring blankets to sleep with. The place was freezing. For 48 hours we suffered. Don’t do what we did.
My Advice
This is my personal advice addressed to individuals whose main purpose is to win the next hackathon they attend. Crimson Hacks held an amazing event with plenty of things for students to do to de-stress. Sponsors held talks at the event anyone could attend to learn about different technologies or programming languages. If your main focus is to learn as much as you can some of these tips might keep you from that.
1. A Time For *Assisted* Learning
A typical hackathon will allow for developers to form teams among themselves. Crimson hacks did this really well and dedicated a entire channel in their slack just to help people meet others and form teams. Working with others is an important opportunity that allows developers to share their knowledge with one another and gain experience in technologies they might not normally use. Having said all this, don’t go off the deep end and have your entire team try a new technology that not even yourself has worked with. I watched a team 11 hours into the competition have to scrap a large portion of their project because they invested time into some web technology no one knew anything about. Make sure when picking what technologies your going to work with, at least some one on your team has some level of experience with it to help out incase you get caught in a snag.
2. Seriously. Just Sleep
We get it. You’re a college student, which means your all too familiar with the creature that is the “all nighter” assignment. But hackathons are a different breed. This is not some essay you can just keep hacking away at till you hit your desired page count. Hackathons are a product you’re trying to develop which will be put in front of others to be dissected and have holes poked in. Having more doesn’t always mean better, especially when you keep adding barely functioning features while your half asleep. If you find yourself without knowing what to do next, go to sleep. If you find yourself staring at a bug for 30 minutes with 0 progress (and no one else can help), go to sleep. Tell your teammates to wake you up in an hour, or when they need you to do something. It’s amazing what getting a single REM cycle in can do for you.
3. Bring a Second Monitor
Everyone needs a second monitor when they develop. If you don’t think you need a second monitor your wrong. Also, they make demoing your product go much smoother.
4. Firebase It
I can not stress this one enough. This is most likely everything you need in a backend. If you’ve never heard of it please go check it out. It’s free and you can share your project with other developers easily. It comes with it’s own database and makes user account creation and sign in a breeze. If you need more functionality just create a heroku service that hooks up to your firebase project so everything is free and in the cloud. Firebase real time database allowed a socketed connection to be linked between our VR application and our server on the other side without having to worry about a single line of socket code.
5. Documented, Well Defined, Separated Tasks
This is good practice to begin with but I feel it should still be stated here because it will determine how well you can utilize the fact that you’re working on a team. If you can define tasks that are not only separate but can also be completed in whatever order you choose then you have the best case scenario. Your project becomes scalable to as many team members as you have separate tasks. Making sure everyone has something to do on the team is extremely important for utilization of the limited time that is given for development. Defining the messages that are sent between client and server can help separate tasks by allowing developers to write tests that simulate those messages coming in.
6. Expect Something To Go Wrong
After all the planning we did for our project and setting out everything that needs to be done with issues created inside of github, we still didn’t plan for everything. Two hours into the competition one of our teammates had some problems back home come up and had to leave. Unexpected events such as this one only stresses the importance of spending time on defining a MVP that isn’t overbearing and allows for extra features to be added on later.
