Hackathon Strategy: Rapid Prototyping with Django

Find a Team

In the ideal scenario you can bring a team to the hackathon and have some buddies who'd like to go with you. Specifically you're bringing a group of people that may consist of co-workers, colleagues, or classmates.

Some hackathons have limits on team size, which often seems to be about four. The most balanced team that Yeti brings is a front end developer, back end developer, designer/web developer hybrid, and a product manager. I think it's probably pretty obvious why, but this ends up making quite the good group. The only surprise here may be the product guy, but ultimately he's the one that can help direct wireframing, the demo, and can give the most compelling presentation at the end of the competition.

Idea Generation

Generally a hackathon is focused around developing an application for a certain industry or a certain theme. Usually you know this topic in advance and may even be the reason why you're choosing to attend.

Best case you can meet up with your team at least once before the hackathon starts, hopefully the week before it, so anything discussed stays fresh in your mind. This meeting is where you discuss what you know about the competition, what they might be judging the competition on and throwing out any possible ideas for what you should hack on. There's no need to come to a final decision or agreement, but best to just brainstorm anything you can think of.

When the hackathon first starts, it's usually lasting for at least a couple of days. After the introduction talk the first thing your team should do is get to finalizing an idea. Now you should have all of the rules and guidelines laid out, which hopefully leads you to choose one of the ideas from your brainstorming session or something inspired by it.

It's important to pay close attention to the judges and what they're judging on. Depending on the contest they could be rewarding more novel, fun, and creative ideas OR they could be looking for an idea that can be monetized and solves real world problems.

Demo-First Wireframing

The goal is not to create a full-fledged, fully functional application in only a couple of days. Ultimately you're just showing a demo of your application at the end of the contest, along with a pitch that can play up what you've created.

The designer and product manager should get going right away on creating wireframes for the demo. This helps narrow down the feature list of the application to what's important to show and will describe what screens need to be created. This lays out a great blueprint for every team member to start hacking on right from the get go.

Data Modeling

The back end developer should get started on modeling the data needed in the application. Using Django's ORM this should be a very, very quick task if everything previously has been done. If you're also using South, Django's database migration tool, it will also be extremely easy to change the schema at any time, without losing any dummy data you've put into the database.

The front end and back end developer should then agree on this database structure so that everyone's on the same page. A front end developer, who is thinking more about UI/UX may have some input/insight just from looking at the data plan that the other developer has set up.

Django Admin CRUD

Awesomely, the Django Admin comes out of the box when creating a Django Application and creates a CRUD (Create, Read, Update, Delete) interface that anyone can use right away. If you're a bit more experienced you can use Mezzanine, which helps give your admin a nicer look and feel as well as some extra convenient features.

With an admin up immediately, even the product manager can start entering any kind of data needed for the demo. This gives the product manager, who may have some extra bandwidth at this point, an ability to be helpful without any database knowledge. He's responsible for the demo so it's important that he can make sure all of the dummy data is of good quality.

Prototyping

Django Views

If you're creating a web application Django Views are the easiest way to go with creating your front end. You can, right away, use the Django ORM to pull out information from the database and use the user authentication built into Django if you need to demo anything involving signup, login, and permissions.

Since Django has its own templating language, which is decoupled from the python code and business logic not only can the front end developer work on it, but the designer will more than likely be able to help out as well. With multiple resources on it you should be able to pump out some UI that looks and works great for a demo.

Tastypie APIs for Mobile

Django has a great REST API library called Tastypie, which hooks right into the Django ORM. If you're developing a mobile application then it will be very easy to get APIs up and running that allow your application to pull down data from the server as well as create or edit existing data.

Without having to worry about data communicating back and forth it is very easy to get a powerful data-driven mobile application up and running for a hackathon. This gives you more time to focus on the front end of the mobile application and the important business logic on the server.

Polish & Pitch

The last leg of the competition involves wrapping up your application to show to the judges and pitch your idea. At this point, hopefully you have everything generally working and major graphical assets from your designer implemented.

The designer should move on to creating some assets and a layout for the product manager's presentation, while the product manager is working on the content. The developers should be thoroughly testing the application, fixing any bugs, and implementing any other cool UI/UX features or design assets that are left.

The one thing you should never try to do is implement a last minute feature. The temptation will be there, but there is a high probability of the team rushing and breaking the application. The last thing the team wants at this point is to have the demo fail in front of the judges. It's better to relax, take a breather, and focus on the demo and presentation rather than continue coding right up until the end.

Sleep