Ouroboros

Hackathon registration built by organizers, for organizers.

BACKGROUND

TAMUhack is a student organization that hosts Texas' largest intercollegiate hackathon at Texas A&M University every year. For 24 hours, 500+ students from across the country gather at Texas A&M to build prototype applications, and get free food, company merchandise, and potentially win big prizes.

PROBLEM

Until I joined the team in 2019, the TAMUhack team handled this large event's registration process manually:

  1. Thousands of applicants submitted applications using TypeForm
  2. Applications were manually reviewed by team members through Google Sheets
  3. Acceptance emails were written and distributed using MailChimp
  4. Students who showed up on the day of the event were allowed entry if they were on a list

While this had worked for previous iterations of the event, the projected headcount for the 2020 event was approximately 700 students, not including sponsors and team members. In addition, the organizing team was hoping to get statistics on how much food was consumed at each meal during the event, and company workshop popularity metrics.

SOLUTION

I led the effort to design and develop Ouroboros, an easy-to-deploy registration system designed with organizers in mind. Since its creation, Ouroboros has been used multiple times by different hackathon groups and has processed over 4,000 applications.

A screenshot of the TAMUhack 2020 status page. According to the status page, the user's application is incomplete, and should be submitted by December 5, 2020.
Status View
  • Keeps applicants informed of their application status and upcoming deadlines
  • Updates dynamically on deadlines without the need for manual intervention
A screenshot of the TAMUhack 2020 application form. Questions on the form include gender, prior hackathon experience, shirt size, and a request for a resume.
Application View
  • Gathers required data from applicants, including name, date-of-birth, and resume
  • Form validation notifies applicants of missing or improper data entry
A screenshot of the Ouroboros admin panel, showing the various aspects of the system that are modifiable.
Admin Panel
  • Only accessible to allowlisted administrators
  • Gives complete control over the system configuration and enables data exporting
  • Keeps a record of actions performed by administrators to maintain accountability

IMPLEMENTATION

I had 3 main priorities that were fundamental to the design and implementation of the registration system: extensibility, maintainability, and reliability.

Extensibility

TAMUhack is not unique in building a dedicated system to handle the registration process. The same task has been attempted again and again by various hackathon organizations across the country. However, the primary difference between Ouroboros and other hackathon registration systems is its initial and continued emphasis on configurability. Anything that could be considered specific to our event was abstracted into a variable or database table for others to modify.

Ouroboros is intended to be a general, minimal solution. The needs of the TAMUhack organizing team in 2020 aren't the same as the needs of other teams in the future. These events are constantly evolving, and it was immediately evident that every aspect of the system needed to be designed so that it could be built upon if someone else needed something specific or didn't want to include something.

A screenshot of the TAMUhack team's version of Ouroboros.
Ouroboros @ TAMUhack 2021
A screenshot of the TAMU Datathon team's version of Ouroboros.
Ouroboros @ TAMU Datathon 2020
A screenshot of the Hacklahoma team's version of Ouroboros.
Ouroboros @ Hacklahoma 2021
A screenshot of the TAMUhack team's version of Ouroboros for HowdyHack.
Ouroboros @ HowdyHack 2020
A screenshot of the KleinHack team's version of Ouroboros.
Ouroboros @ KleinHacks 2021

To enforce modularity and extensibility, I chose to use Python as its implementation language and Django for the web server. Python is renowned for its approachable syntax and shallow learning curve, making it an excellent choice for teams trying to get things done. The Django web framework takes an opinionated approach towards building software, forcing developers to comply with its constraints in exchange for out-of-the-box functionality that could easily be extended by other teams or future developers.

A screenshot of the TAMUhack QR code scanning application, codenamed 'Rattle'. The screenshot has two dropdowns to configure rapid scanning.
An example of Ouroboros' extensibility: our QR code scanning application, used to record when applicants got food or attended workshops.

Maintainability

Ouroboros was started in February 2019, roughly one year before I graduated. I wanted development and improvement of the project to continue after my departure from the university, so ensuring that it could easily be handed off to others was critical. This meant including documentation, using familiar technologies (another determining factor for using Python), and teaching future tech team members how the application worked when it was my time to leave.

Since my last commit on April 17, 2020, the TAMUhack team has added 1,430 lines of code and removed 49 (at time of writing). The team has also configured the system to work for two more events since my departure completely independently.

Reliability

The registration process for a hackathon is arguably the most important process in the entire event. It gathers resumes to share with sponsors (which has a direct implication on fundraising for future years), facilitates day-of logistics, and represents the professionalism of the organizing team to both applicants and corporate partners. Any software that claims to handle such an important process effortlessly needs to be rock-solid in terms of reliability.

To that end, every feature developed for Ouroboros was built using a test-driven development mindset. Every feature that needed testing was tested on every change. Code that failed tests was not allowed to be deployed.

To make sure that our system was always available, I built an automated continuous integration pipeline that deployed the system to Google Cloud Platform every time a developer made a change. By automating the process, I made sure that whatever changes we thought were ready for launch were launched instantly.