On Friday I judged at a hackathon called hackidc. It made me think. We saw many great teams building interesting things. However, I noticed not all of them had a clear idea what they are trying to solve, or had a working piece of software. So since most of them were technical teams with great understanding of tech, I decided to share how I think a team in a hackathon should work in order to achieve great success. I will use the OSI model that most of the attendees would be familiar with.
The physical layer is connecting the real world with what you are trying to solve. Basically, you are trying to solve a real problem issue, and find the correct market fit. The main thing you need to do before you can build anything is define what problem you are trying to solve.
The data link layer is where you collect data and link it to the problem you are trying to solve. Without data, it will be very hard to understand the problem landscape, and solutions tried by others. In this layer, research and information should be collected, reviewed and shared.
In the network layer you handle the team network and route work between the members. For example, assign one member to the frontend work, another will do the backend, and one will be assigned the presentation work. Sharing the workload is crucial for delivery and working within time stretches.
Transport layer handles all the integration between the various components. Having a working end-to-end product is the main goal of this layer. This is one of the most critical layers to achieve and the sooner we get there the faster we have a working product we can polish. This is one of the main points teams fail at.
This layer handles the communication between team members, setting expectations, and meeting agreed upon view the team is going to share. Having a unified vision will be the basis of the presentation layer, and a demo, if there is one.
The presentation layer is where the magic of taking the teams thoughts and vision is presented and shared with viewers, judges and other interested parties. The presentation layer along with the transport layer are the most two critical layers. The presentation should be clear, direct and describe how the real world problem defined in the physical layer is solved, the technical level, and on the user level. It should provide vision, and growth opportunity.
The application layer is how the team connects all the dots, and how the product that was build meets the end-user use case. In the layer the teams gives a demo, lets users play with the product and collects feedback. This layer is basically go-to market. There will be bugs, and issues, but the basic, minimal viable product is ready to ship.
It has been a real pleasure to see so many talented young people trying to solve interesting challenges, and do so in a very interesting ways. I hope this write up will help other teams trying to deliver great products in hackathons.
Taking it to the next level, the method outlined above is probably true for any MVP a team is trying to build. I really believe looking at such a structure might help build good software, and deliver quality software at reasonable delivery times.