Fast feedback, avoid frameworks, re-evaluate regularly - lessons from a hackathon

Last weekend I gave up all claims to a social life, and took part in my very first hackathon.

Q. What's a hackathon?

A. It's an event where teams form to build rapid software prototypes that showcase a new idea or concept e.g. for a business, or for community development. The event takes place over a very short period, normally a couple of days.
This weekend the theme was building mobile applications using HTML5 and the Cloud. Ideas were presented on Friday evening, attendees formed teams, and teams built working prototypes to present on Sunday. There were a mixture of developers, designers and marketers taking part.

I chose to join a team porting a great iPhone app called Opuss to other mobile platforms .

The teams hard at workAn Opuss UI sketch

The weekend went well. I got out of it exactly what I'd hoped for in terms of new expertise, contacts, and inspiration.

Nevertheless, there were some hard lessons so I've summarised a few:

  1. Focus on feedback
    Some commercial software projects focus on delivering 'potentially shippable products' - things your user can use straight away - at the end of a cycle of work.

    Forget that.

    Focus on delivering a product that can generate feedback. For example even if your users will need login accounts for your application to be viable, don't build functioning login won't learn anything about your idea from that.

  2. Forget frameworks
    I'd done my research, the best approach would be to use the Sencha Touch framework to build our app, and to use PhoneGap to package it and deliver it to say Android.


    Learning Sencha Touch proved a big task, and it would have been much faster and simpler to write raw HTML, CSS and JavaScript. Use the simplest technologies you can, even if they aren't strategical for building a well-designed program that is maintainable over the long-term.

  3.  Re-evaluate regularly
    If it's been a long-time (a few hours) since you delivered a new version of the prototype and got some feedback, then stop. Think about why. Think about whether you can simplify what you're working on now, or even whether you really need to do it all. In our case, we could have abandoned Sencha Touch much earlier, and abandoned connecting to our servers API to logon and get a session ID etc.

All of these lessons probably aren't surprising to read. They could have come straight out of a Lean Startup text. It was a great reminder of principles I thought I had already taken to heart though.