The Future As Seen By Me In 2010

Well looky here, things one has scanned in eh. (ignore the photo, that's some guy that made some accounting software, not sure what became of him ;) MIKE RIVERSDALE is fuming. The expensive headphones he bought in Sydney three weeks ago have just died. His first reaction is not to randomly spill expletives into his coffee, but to use his iPhone to vent his frustration to his Twitter con- tacts, under the moniker Miramar Mike. "I will also put, 'What should I do?' It's a conversation. I'm reaching out to the people following me." The council predicts hand-held digital devices such as smartphones will rule the world in 2040. They already rule the life of Mr Riversdale, whose company WaveAdept helps businesses adapt - their computing sys- tems to allow staff to work from anywhere - and with anyone. In order of fre- equency, he uses his iPhone to tweet (1136 followers; 8363 tweets since joining), e-mail, make phone calls and use online services, such as checki

The Goldilocks of Hackathon Challenges

The six things every hackathon / unconference / barcamp needs are well known, namely:

  1. Suitable venue
  2. Convenient date / time
  3. Engaging ddentity ("logo")
  4. "Just right" Purpose
  5. Relevant people
  6. ALL the "Playdo"

You get all those ticked off and you have an event - my favourite bar, Saturday at 1pm-4pm, "HackMike 2018", "Increase Mike's Knowledge Of Diversity", you and me, and a load of knowledge and techniques ... see, that's an event. Or you could call it catch up with a buddy, but once you have the six items in place the only thing you're increasing is scale - how big and shiny do you want your event to be?

btw: it has to be ALL of the items, you can't have an event that doesn't tick off each item; and nor can you have an event that doesn't focus on each item to ensure the best you can get - it's a great way to split up your 'committee'/organising team ... plus a layer of logistics underneath each one.

"Just right" Purpose

Having organised a number of hackathons I have discovered that one of the traps for the inexperienced is to target the challenge / purpose of the event either too high or too low.

First some definitions that I use:

  • Purpose: the reason for the event existing
  • Challenge: an area someone would like the event to tackle
  • Project: what a team ends up working upon

Let's take the Purpose first - this is tied up in the event's Identity. A good purpose is present in the naming of the event, the tag line of the event, and it is expressed in any logos and design elements of the event. The Purpose is the reason the people want to come along to the event.

Good purposes:

  • Save One More Life
  • Free Up Peninsula Transport
  • Creating Healthier Kiwi Homes

Bad purposes:

  • Use Government open data
  • Collect Ideas To Help Agency X
  • Fix The xxx ICT System

So what makes a "good" purpose and what makes a "bad" one - level and desired outcome. If the purpose is way too woolly it can be akin to giving people a blank piece of paper and saying, "Go on, get creative" - it can be done of course, and some people love that, but most of us need a little guidance a few hints as to what on earth we are here for.

As for outcome the best are purposes that explicitly state an outcome that benefits all concerned, most likely a wider community, or even the whole country. And when you have that defined audience, pop it into your purpose - "Save One More New Zealand Life". If the purpose obviously serves just one party then it will feel out of balance - you will know when this happens as you send a disproportionate amount of your time discussing IP ownership, access to internal systems, how the event will be PR'ed/spun, and how are to be technically constrained.


If we move on to Challenges they also come under the "level" criteria, but even more so.

Just like Goldilocks and the three bears we have "too hot", "too cold", "just right", or perhaps you prefer, "too soft, "too hard", "just right".

Challenges that are too high level, ones that don't really have an immediate outcome that would be of benefit to someone, make for "bad" challenges. However, don't throw them away as they almost invariably end up making a great event Purpose. Whilst "Free Up Peninsula Transport" maybe too high for a particular challenge it makes for a good overarching theme to the whole event.

Challenges that are too low level are just bloody awful. These are the "We have a problem API x and need help re-developing it to ensure we can do blah blah in the future". These are challenges that don't belong in a Hackathon as they are BAU for an organisation who is likely to have an IT Department and/or the money to get on with it and solve their own damn problems. And if they don't then sure, ask for external help ... but be aware it's the bread and butter of a tech person's life so don't expect it to be free.

And then we have those that are "just right". My rule of thumb for these is if you can discuss such a challenge with 3 different parties and they quickly "get it", and can come up with wildly unrelated potential projects to resolve it then you're on the right track. If the creative juices are engaged as you discuss a challenge, if people gravitate to it with ideas, if people say, "Oh yes, I have that problem" then you're on the right track.

But remember, not too many challenges - even if they are "just right" one can have too much porridge and that'll just make everyone sick.

I thank Dascha Elliot for the initial inspiration for this article

I help people, organisations, and agencies that need to engage with communities in order to solve hard problems - I do this using the hackathon framework. Contact me if this is you.


Popular articles

The Future As Seen By Me In 2010

Knowing good info from bad - how do we?

How To Facilitate A Barcamp/Unconference

The 3 C’s – Communication, Consultation and Collaboration

Web/Enterprise 2.0 is SaaS+ AND can only live on the Internet