We had a table-top version of Gorf at our student house in Canterbury, way back in 1987. Its arrival had been heralded for weeks, and when my housemate Mark finally brought it through the door – with help as these things were heavy – we did little else but play it for the whole of the winter term.

Looking at the video, you’ll probably laugh at how primitive the game is – my children did anyway. But Gorf was cutting edge when it was released, and even in 1987 it was still unusual in that it was one of the few games to “talk”. The voicebox in our battered version was very inconsistent, which only gave it an added piquancy as every now and then it would bellow unintelligible robotic pronouncements and then fall back to silence. A bit like some people I’ve worked with really.

Now, not only does Gorf look terribly dated (even I didn’t watch all 4’29" of the video) but I bet it’s really easy! There were very few buttons to have to remember, but at the time it still took us weeks to master. The thing is no one minds that now. It was a perfectly good game at the time and I bet most people who played it look back on it fondly.

It’s the same with application design – sometimes we get a bit too caught up on designing for the future when actually it’s plenty difficult to design something good for today. I’m the first to admit my shared guilt in this as there have been times in my career where I’ve over-designed for re-use.

Re-use is no bad thing – we rely a lot on reusable components when building our applications – but it shouldn’t become an end in itself. The important thing is for users to be able to use your application as soon as possible, and it might be worth sacrificing some design options to achieve this. Better that than it lying for months / years in development whilst you try to make it fully generic. If it has a longer shelf life because of some of the re-use features you put in then that’s a great bonus – but you should think of it like that – as a bonus.

Why does over-design happen? I think it’s a combination of a couple of factors.

Software developers that grow in to designers want to generalise things. It’s more pleasing to think that not only does your application make a good e-commerce tool, but with a bit of configuration it could also be a perfectly serviceable missile-tracking system.

The other consideration is that, as a designer, you’ve probably spent the last couple of months prior to development convincing your manager that you need to build a framework as it will save development costs later. Designers love to code nearly as much as project managers love to be seen saving money. Again, I’ve nothing against frameworks – we have a few ourselves – but these days I think they should be developed after you write the first two or three apps rather than before.

Software obsolescence is inevitable – even for classics like Gorf. It’d be a shame for software you’re designing to become obsolete whilst you develop your framework before anyone has had a chance to use it.

Finally, a plug for my favourite London bar, Fluid in Smithfield where you can play on working table-top and stand-up 1980s vidoegames (sadly not Gorf) and as if that weren’t enough, it’s a great chilled-out venue to enjoy a few drinks.