Check out this gem of an email that I received the other morning from a high profile, and well funded, US based startup to whom’s software as a service I subscribe to:

Yesterday morning we had a major server outage affecting our 1.0 customers. We completely lost one of our database servers. The day was spent rebuilding and restoring everything we possibly could.

There were a handful of accounts that the restore completely failed on. Yours was one of those accounts. We have exhausted all available avenues for restoring the account data with no positive results.

Quite simply, I find this astounding! I would have thought that should have had a mirrored/clustered database server, and at the very least held an offline backup of my information. Obviously not.

In my previous life prior to YouDo, I spent countless hours with auditors going over BCP and DR plans, and countless hours making sure we’d avoid this kind of screw up ever happening to us. I used to hate it. Really hate it.

But now I’ve been on the receiving end of what seems like an inadequate disaster recovery plan, and can relate to the pain that our customers could feel – it’s going back near the top of my agenda.

Time: My Precious

March 31, 2008

I’ve mentioned a few times now how hard you have to work when you set up a new business.  So it stands to reason that you really have to plan your day and prioritise effectively.

I used to hate the daily commute to and from work, but now I have grown to love it.   It’s pure “me” time – without disruption, in my iPod cocoon on the number 23 bus!

In the mornings I use this time to plan what’s ahead for the day, prepare my first five or so emails for the day, and also to get a download from Roger, our now UK based developer.   The Blackberry Curve is an awesome gadget and with Google Talk, I can choose to be connected anytime I want.

In the evenings, I use the bustime to quickly check-in with everybody and get an update as to where they are all at.   That helps me have a good think on it overnight, ready for planning the next morning.  The evening commute is also a great time to tidy up that inbox.  I’m still trying to maintain Inbox Zero!

Since I’ve gotten into the habit of spending 30 minutes at the start and end of each day I’ve noticed that my days really do seem to be more structured, organised and productive.

Make the investment in yourself and your time.  It’s well worth it.

Phew! It’s been quite a while since my last post and I’ve been busy busy busy.

The IT market is really tight at the moment if you are looking for worker bees, so when you find good people you need to accommodate their needs. Also, as a founder of a startup business, I’m always keen on keeping costs down. So I thought we’d give remote development a shot. Six developers, one of them the other side of the world. The bulk of them working in their “comfortable” development pits they call home.

It’s working!

There’s certainly no substitute for face-to-face interaction, but distance and space away from others certainly has its perks. It gives headspace to get stuff done. But the communication is incessant:

  • we use continuous integration techniques to not only ensure ongoing code quality and confidence, but also to see what progress we are all making
  • we make gratuitous use of instant messaging
  • it’s mandatory we gather round our group IM, Campfire
  • we document things as we discuss them on our Wiki
  • we like the telephone
  • we meet up every week, or when we need to

Depending upon where we are at in the project, sometimes these constraints actually help build better software. It forces you to write certain things down you might haven’t otherwise. You have a good audit trail. It enforces a little more rigour.

But at other times it can be tough. Particularly with the knarly requirements that only a good old whiteboard session can solve. But that’s when we meet up face-to-face.

It’s certainly not for everyone, and you need a certain breed of developer for this to succeed, but remote development can work.

We truly are a global marketplace.

After Webstock 2008

February 16, 2008


Webstock 2008 is now over.   The brainwaves have subsided and the hangover ended.   A massive thanks should go to the Webstock team for organising what can only be described as world class event.
Whilst many would have seen some of these talks or content before (especially the podcast nuts) – there’s simply no substitute for taking two days out to talk face-to-face with some of the most respected dudes in the business.  You get two days to let it all soak in – and you get to see many angles over the course of the conference.   It was a great investment of my time.
Here’s some of the stuff I got out of Webstock 2008.
  • Tags and Taxonomy.   Free tags are like leaves.  A gazillion of them, but eventually they all fall off the tree, rot, and end up feeding the tree’s structure (the taxonomy).   Tags are for quick learning.  Taxonomy is long term.    A great session from Peter Morville.
  • Continuous Integration, Release and Ops Management at Flickr.   It was great to hear from Cal about how the Flickr team run their shop.   Talking to him post conference, I found out Flickr has about 2,500 servers!!  Yikes!  In short, they do everything to make their lives easier, make them more agile, and to reduce risk.  You know, things like continuous integration, continuous deployment to “pre-production” servers, release flags (i.e. flags in the app to turn functionality on/off – to reduce branching), running tests on their software every hour, and building a whole plethora of “one-click” tools to manage all this stuff.
  • Achieving Flow.   There was one diagram that Kelly Goto put up, which really hit the nail on the head as to why people get in the flow.  See my (keynote) scribbling below:
  • Primal Software Development and Managing Design.   I really enjoyed Michael Lopp’s presentations. Fascinating to hear that at Apple, they start their product process with 10 pixel perfect mockups, which they then reduce to 3, then to 1.   Also – a key take away I got from his sessions was that you can build software many times, but you only build culture once.  Go check out his blog, particularly this post – which captures nicely his first presentation.   
  • How good design helps tell the story.    Jason Santa Maria showed a great example as to how design helps to augment the story, and how the transition from print to web often loses this.  In short, give your site some “context” sensitive design.  If that kinda makes sense?
  • Blending the real world with network data.  Tom Coates gave a great presentation which really opened up my thought processes.  In short, the web is not so much of a collection of web pages, but more a massive collection of data that manifests themselves as web pages (of which is only one form)!   Your product is not your site! (it’s the platform).  And once your size of data gets too large, forget hierarchies – they will collapse under the weight.
  • Eloi vs Morlocks.   Remember that our users are Morlocks and that we, the Eloi, must make their lives as miserable as possible.   Seriously, though, this was a great presentation by Damian Conway, who rightly advocates that we must remember that most internet users are just like Grandma.  So design for them, not us.
  • Feel their Pain.   The brilliant Kathy Sierra says that we need to actually experience the pain our users feel so that we can “mind read” them.   Seriously.  There’s  theory that it will more effectively trigger our “mirror neurons”.   When you’re usability testing, look at peoples faces.  It’s the feelings that you’re after!  Another great tip when building your help.  Document exactly the questions your users ask in the usability sessions. Exactly how they ask them.
All in all, a brilliant conference.   
Thanks Webstock Dudes! 

Balls. Line. On.

October 22, 2007

I’d previously posted about my experiences in starting up our new business, which is going terrifically well.

I’d mentioned that flexibility kicks ass, and it really does.  But the last few weeks I’ve been experiencing another side.  And it’s one you rarely experience as a corporate “employee”.

We’ve got a couple of important project deadlines in the pipeline, and when you have a vested interest in them (i.e. it IS your business) you kinda treat things a bit differently.   You simply cannot afford to drop the ball.  As a startup business, your balls are well and truly on the line.  So we’ve been working a few ‘late ones’ to make sure everything goes real smooth.  That’s why I’ve been “dark” for the last couple of weeks.  It’s all progressing really well though, so we’re very confident all will go very well.

Startup businesses are great fun, and immensely rewarding, but remember that they need a lot of bloody hard work and commitment.   But it’s de facto.  Whilst I’m working real hard, I’ve never enjoyed it more.

I’ve had a fantastic Labour weekend with my family – my weekends and public holidays are sacred (and you should never sacrifice your family time),  but first thing tomorrow morning it’s straight back into it.

The coffee shop will be happy to see me.


I’ve just finished reading Freakonomics.  It’s a great read, and don’t be scared off if economics ain’t your cup of tea.

I won’t spoil it for you, but it answers questions such as:

  • what have schoolteachers and sumo wrestlers got in common?
  • how is the Ku Klux Klan like a group of real estate agents?
  • why do drug dealers still live with their mums?

It’s really good fun, and  if anything, makes you take a slightly different approach to “conventional truth”.

Now, my fellow techies,  we all know that IT does not have the best of reputations.  According to these surveys the project failure rate is about 50%, if not more.  That’s pretty abysmal.

The conventional truth is that projects fail because of:

  • poor planning
  • poor project management
  • poorly defined requirements
  • lack of user buy-in and involvement
  • over ambitious technology
  • and there’s probably a few more (feel free to add)

After reading Freakonomics, I thought challenge the conventional truth about what influences IT project success – let’s call it Geekonomics!!

I’d love to see some stats/evidence to prove/disprove the following hypotheses (some of which I think maybe true, some not!):

  • Developers using Mac have a higher project success rate than developers using PCs!
  • Bloggers are involved in more successful projects than non-bloggers
  • More caffeine intake equals more project success
  • Less time in meetings means a bigger chance of a successful project
  • Less management of (bloody) Gantt charts results in more successful projects
  • Locking down internet access at work decreases the chance of project success
  • Giving your employees “free” broadband increases the change of project success
  • “True geeks” deliver better projects

and finally,

  • the success of a project is inversely proportional to the size of the papertrail it leaves behind

These are just a few to get you thinking.  It’s a bit of fun – but you never know!  Go on, feel free to add some more.  And if you know of any stats around them, then please do let me know.

Unsung Heroes

June 29, 2007

According to Wikipedia, emigration is “the act and the phenomenon of leaving one’s native country to settle in another country”.

Having being a “Pom” (Prisoner of Mother England, apparently) living in New Zealand for the last 10 years, I often get asked “are you here for good?”

I think that New Zealand is a wonderful place and I think I will always have a base here, but the kind of people my family and I are (well, at least my wife and I), we always want to broaden our horizons and see what this wonderful planet of ours has to offer. It would be a shame not to. Emigration is not in my vocabulary.

But that’s me.

For every person I know like myself there are as many that are as content to stay in the same place, doing the same job, drinking the same beer at the same pub, in the same seat. They’re as happy as me. If not more. And happiness is a good benchmark of success. The world needs both types of people (plus more). It’s a kinda Ying and Yang thing.

You have to respect that.

An organisation cannot live with rock stars alone. It needs the steady eddies to keep the “lights on”.

So often these people are overlooked, and they shouldn’t be. They are often the foundation of your organisation. Rarely noticed, but when they’re not there the whole house starts falling to pieces.

Please. Don’t forget them. They’re the unsung heroes.