What makes programming at hackdays great fun?

Hackdays, events that bring many people from different backgrounds together to work on ideas, can be great fun for many reasons. But for computer programmers there is one particular reason it’s great fun.

Remember, the aim of the hack day is to explore an idea with other people, to see what is possible and hopefully kickstart the project into life after the hackday. You’ll probably end up building a prototype of the idea, to demonstrate how it works. The energy and ideas that are unearthed as people from different backgrounds work together is amazing.

[Note I’m talking about hackdays where a team gets together to explore a new idea. Some hackdays are about playing with a new technology, and those are different.]

Normally when computing programming, you have to think about the fact that your software will live on and hopefully grow and change. Other programmers will come in later and have to pick up the pieces and work out what is going on – and that includes you, looking at your work from a year ago wondering what on earth you thought you were doing. (There’s nothing worse after a long debugging session than discovering the moron responsible was you.)

To support that, we have come up with a whole load of professional “best practices” we follow when writing software.

  • Requirements
  • Architecture & Design
  • Modularity
  • Code Building
  • Commenting
  • Naming conventions
  • Data validation
  • Testing
  • Automated Testing (eg Unit Testing)
  • Continuous Integration
  • Source Code & Release Management

However, all that is because we expect our software to live on into the future.

Let me make a prediction now about the software you will write over the hackday:

“Most code written at this event while developing ideas will be rewritten from scratch or almost completely rewritten before it is used for real.”

With that in mind, can we come up with a list of professional “best practices” for programming at a hackday?

  • Just make the protoype work!

That’s it. Really. If you write a Unit Test at a hackday, you’re probably doing it wrong.

At one hackday, I did a site for finding dates at a festival. When you signed up there was a field to type your birthday in. During the final presentation, my team mate Sarah typed in a random string as she didn’t want to tell everyone her birthday. The whole site crashed; I hadn’t even bothered to write the error-handling code to deal with what would happen if users didn’t put in their birthday. Quickly, I told her to go back and put a real date in and it was fine.

I suggest you think about what will make an effective protoype – what will really get the idea across and impress others? At one hackday, we put together a messaging system for carers. We secretly found out the phone numbers of half the judges and organisers, and during our final presentation sent a message on our website. 20 seconds later 10 phones went off around the room as our message was texted out – a humorous and very effective demonstration of our idea.

So have fun!

This weekend I’ll be a mentor at this hackday in Pristina – looking forward to it!

[Photo by Oolong.]