Extreme Hacking: A Recipe for Success in Hackathons

Hackathons are usually one- or two-day-long coding competitions where developers pitch an idea to solve a real-life problem and build a working technical solution. Despite lack of sleep, I personally would enjoy participating in hackathons as it gives me some quality focused time to develop some of my ideas into prototypes or products and also to network and collaborate with a few bright minds. It is a great space to play around with some technologies that are on my to-try-out list.

The typical mindset in a hackathon is to be ad-hoc, creative, and spontaneous while aligning to some pattern that would help the team find the critical path in taking the idea to a showable product and reduce the disproportionate amount of time spent in areas which are not necessary.

The focus on the critical path will enforce effective utilization of short time and parallelization of tasks. As an avid cricket fan, this is why I draw parallels between a hackathon and a T-20 game!

ThoughtWorks is renowned for adopting Agile practices in software development for the past 25 years and I have been with ThoughtWorks for nearly 6 years. The more I work on Agile, I realize that Agile is not just for long-running projects but can also help a lot when you have to start from scratch to achieve a specific goal in a very short amount of time. Well, hackathons are one of these kinds of project, aren't they?

Deriving from my hackathon experiences, here is my take on why applying Agile practices would be the secret sauce in your recipe for a successful hackathon and how it will help your team to take your amazing idea to a working product that you can showcase.

Agile Software Development

Let's quickly revisit the values of Agile software development.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Extreme programming (XP) is an Agile software development framework and the most suitable for hackathons since XP revolves around simplicity and building what is needed for today rather than for the future.

Agile in Hackathons

Agile in itself is not a prescribed set of rules. If a small team with a good timeline decides not to pair and work on pull requests, that is also Agile. In Agile, there are no compromises, but only "what makes us productive, if we follow it." Framing certain structures and guidelines around hackathons can help a team in winning is the larger motive of extracting the essence of Agile into hackathons.

Roles:

The roles of the members in the project team for a hackathon is very simple — all of them are expected to play all the roles whenever needed. Since the number of people in the team is going to be very less and the idea of the hack was conceived collaboratively, everyone in the team will be the product owners/customers, analysts, designers, developers, testers.

Inception:

Inception phase in a hackathon is where,

1. a problem statement is defined, and 
2. potential solutions are brainstormed.

Innovation is given the primary focus as it will make the hack stand out. The aim here is to be "practically creative" without thinking too much about the implementation barriers or technology constraints. The team must be clear on the "elevator pitch." The various factors that help to funnel out envisioned solutions are cost, scaling, marketability, sustainability, ease of use, etc.

In one of the hackathons, we proposed a VR-based experience for users to visualize and navigate hotel rooms premises while booking. The winning edge was the ease of capture of the experience of the rooms using the camera in phones with the help of an Android app.

MVP/MSP:

The team now decides on the Minimum Viable Product (MVP) — the set of features that are needed for the product to be released in the market. If the time given for development in the hackathon does not seem to be enough for building the MVP with the given team size, the team has to decide on the Minimum "Showcasable" Product (MSP). MSP is more like a proof of concept that will focus on the "X"-factor that is associated with the idea which will give you the winning edge.

Release planning:

The team then carves out the features and tasks with finite well-defined boundaries. The important thing to keep in mind here is to ask the question — “Is this able to be demoed?” every time a story is written. No fancy project management tools are required — just a few sticky notes or an Excel file should be more than enough as the stories are not going to be detailed out.

Release planning involves identifying the lean critical path — to solve the dependencies to achieve the MSP at the earliest and laying out the order in which the stories are going to be played. The focus is generally to allocate minimum time on the boilerplate features and to focus more on the innovation that the hack is going to bring out.

Parallelizing the work is the key component and a hard-and-fast rule of everyone should play every role could put creativity a challenge. If the team has same "required" skillset, it will be fully effective.

Iterations are generally a week or two weeks long in Agile projects. It is very important that the team members have frequent checkpoints hourly or once every two hours and keep highlighting the blockers they are facing. This will help you reach a "showcasable" state every two hours which is very critical as you will have mentors who track your progress and help you refine your idea.

Iteration 0:

This is the project setup phase. The team decides on the technology stack for the hack. The "cool" factor and the relevance to the use case are the primary deciding factors. It is not necessary that all the team members must pick up all the frameworks/tools that the hack is going to use. One can feel free to confine themselves to a certain part of the hack — for example, the frontend or services to expose the required data in the form of APIs, etc. In this phase, the technical architecture/information flow is designed at a very high level and the required VCS repositories are set up. The deployment strategy/ final showcase strategy is also decided by the team.

Development:

Developers, with the help of coffee, go about developing their product and take checkpoints frequently on the progress of the hack, and whether they are on the track of completing the MSP within the given timeframe. While it is important that the code is modular, it is sometimes okay to write some pieces of dirty code — but please make sure that it is simple, understandable and extensible. Working code has higher precedence over clean code while hacking.

Testing:

Developers generally do not write any tests during the hackathon and there are no specific tester/QA roles in the team as the primary focus is on getting the working product out in the stipulated time. Testing is usually done by the team members themselves — at a very high level to check if the "happy path" scenarios are working as expected and each feature is compatible with the rest of the system. It is critical that frequent check-ins are done and the developers are syncing code between them and running the full application regularly.

Final demo:

At the end of the hackathon, all the teams that participated showcase their product to the judges by explaining their problem statement and the working technical solution.

The activities in the lifecycle are derived from my experience in hackathons and the lifecycle is just my recommendation as it has helped me nail a few of them. As quoted in the movie Enemy, “Chaos is order yet undeciphered,”  and I hope this structure would help to decipher the chaotic parts of the hackathon and yet let everyone have fun and take home a lot of lessons, and prizes most importantly.

A few winning moments...