Release Early, Release Often (even if it’s shit to begin with)

Yesterday, we had a “code jam” at Osmosoft Towers, with the aim of releasing, at 6pm GMT, a polished and usable version of “MediaWiki Unplugged”.

MediaWiki Unplugged is a web application you run locally (in your browser), that downloads content from a MediaWiki, allows you to edit it and sync’s back. The idea, a collaboration between Globant and Osmosoft, is that you’d use this when your Internet connection is flakey or absent, or just to give you a bit of breathing time when composing edits. We did it and the results are here: http://mediawikiunplugged.com – the hashtag is #mediawikiunplugged.

from genglebiennes flickr stream

from genglebienne's flickr stream

Here’s the ‘ting – it’s a bit shit. I mean, it works and everything, but it’s not something that we’re really PROUD of. This is a problem for some. For me, this is one of the progressive things we’ve done for a long time and, in my opinion, should set the precedent for how Osmosoft functions as a team. MediaWiki Unplugged might be rough; however, it is new, potentially very helpful and, fundamentally, THERE.

There’s a principle in Agile Development, which Google Code appears to have taken as its motto – “Release early, release often”. This is a scary thing for many people creating new things – there’s always something that can be improved or a problem to fix. The “sensible” way to release new things is to keep them hidden from view until they are polished to a perfect shine, then release to a triumphant fanfare in the form of a press release and flurry of feathery tweets. Sadly, this expectation of great consequence will turn out unmet, the carefully composed press release will go uncited and the tweetstorm will fail to materialise.

To mitigate against this disappointment and optimize your chances of making a big splash with your new stuff, I suggest you instantly adopt the practice of releasing early and often. Here’s why:

  1. Other people might not care about the things you think they care about; and there’s a good chance they won’t care about the things you care about. When you’re developing early-stage stuff, this is really important – you give out your product and everyone starts to use it in ways you hadn’t imagined, they put up with the things you thought would kill the experience and they complain about things you’d overlooked. Get your stuff out there earlier, with your hypotheses in your head, and watch and learn as people surprise you.
  2. If you let out something you’re not proud of (a software fart, perhaps), it gives you one helluva motivation to sort it out. There are few things more stimulating than criticism or the fear of criticism.
  3. You’ll do a better job next time. The eternal feedback loop has commenced and it feels hard. That’s because you’re learning about what shape your things need to be before people will love them. You’d pay people thousands of pounds for this kind of information in the controlled laboratory of market research.

Back to MediaWiki Unplugged then: my ears are open. As are the ears of everyone in the Osmosoft/Globant team. Roll on the next version.

from genglebiennes flickr stream

from genglebienne's flickr stream

[Globant CTO Guibert Englebienne took lots of photos and posted them to Flickr, along with a video of Jeremy talking about MediaWiki Unplugged as a TiddlyWiki application, another of himself talking about the day; he also set up a tumblr for the day]

Advertisements

One Comment

  1. Posted May 14, 2009 at 2:13 pm | Permalink

    Sounds like it was rather fun. So tell me, why is it ‘a bit shit’, exactly?