I’ve spent a lot of time coming up with analogies for what I think we’re trying to do: Ways to make it easier for people to comprehend where we are and where we’re trying to get to.
If you’ve followed my postings here (the new version of blogger says that this is number 590) then you’ll have seen many – the recent ones about fruit machines in Las Vegas and the older ones where I’ve probably talked about Kennedy’s “go to the moon” speech in the sixties or the Microsoft Office hook.
Last night, I came up with another one; one that I think makes it a lot clearer for me. It stemmed from me wandering around the subject of sim games as I was writing about the Copenhagen Consensus. I remembered that I’d bought a book the other day, Masters of Doom, that I hadn’t started. Doom. You remember that – the world’s greatest first person shooter at the time. The one where if we hadn’t had it, we wouldn’t have Halo or Half Life or any other related title.
When Doom first came out, it wasn’t long before “mod files” appeared – files that allowed you to change the shape of the game, the graphics, the sounds, the locations, pretty much whatever you wanted. To use a car analogy, you had a chassis and an engine, but everything else (if you were smart enough) was up to you: you could add different doors, change the seats, put a sun roof in, whatever.
I want the central infrastructure in government to be the equivalent of the Doom engine. You get the core pieces that drive things, and you get to make up the scenery – you get to install the WAD files, using some helpful tool sets that we’ve designed for you, or some others that different people have designed. I think we’re quite some distance from this, but I think it’s a useful analogy – for those who are video-game literate anyway (I’ve got another analogy coming about Burgundy wine, but I’ll leave that for another time).
The thing that I think is the blocker – the thing that is different – is that Doom knew what it was up to; it knew that it just had to worry about the graphics files and the sound files; it knew where they were and it knew their format. Noone tried to change the rendering engine in Doom so that it had to use one piece of code for walls and another for doors. Everything was data driven.
In the world of government IT, we haven’t abstracted the data from the engine and we have several engines. There’s something here that I believe would be useful to explore. How many engines do you need? One to make payments, one to receive payments? One to print content to the screen and another to print content to paper? One to process eligibility and one to grant entitlement? How many really? Do you need two to make payments or three? Or 12? or 120?
Doom has sold however many million copes (and I expect I’ll find that when I read the book, but I’m guessing all the versions together have probably hit 100 million or so).
We need our Doom engine equivalents. Things that are so obviously good at what they do that other people strive to copy them (e.g. Half Life) but adding their own features and capability – but that not too many people copy them (i.e. enough for healthy competition, enough so that everyone makes a margin but not so many that your decision process takes longer than it took to create the engines). But, most importantly, people can take their data (in the correct format) and add it to the engine and get what they need. They can’t change the engine (they can’t make it put doors where walls are supposed to be or vice versa), but they can capitalise on everything the engine does simply by customising the wad file.
If we could take website design forward this way I think we could all solve the accessibility, download speed, metadata standards and other issues that we have. And focus on what the gamers really show up for – the content.
