Sometimes you learn the most by playing a game.
Brighton, 2007
Still somewhat fresh from an eight-year stint as CTO in a local games company, I was working as a contractor, handling 2nd line desktop support for the Trust I am still employed in today. It was to be a stopgap, something to keep a roof over my head while scoping out where to go next. I hoped at the time to jump into another startup, there were and still are many to choose from in the city I work in and the contacts I’d cultivated in those eight years were telling me of all sorts of possibilities I could go for, some local, others further afield. The day job in the datacentre was a depressing place to be, there was a lot of animus directed at the IT department from all quarters in the Trust and despite all the money spent on NPfIT, ‘they’ (and it was very much a ‘they and us’ kind of mentality) were getting impatient at the ongoing lack of progress. Much of the work we did could be handled remotely, however I generally preferred to get out of my chair and go fix the problem in-person. Often as not the problem had been poorly described in the ticket and some important nuance of the issue had been overlooked, this was my justification for doing this, I also got to meet a lot of cool clinicians at work. While poking around at the problem, the clinician hovering over my shoulder waiting for me to finish, would unburden themselves of all the IT woes they were experiencing. Some of these issues I could happily just fix, there and then (grr, printers!) but most of what I heard was beyond my scope. These complaints were often phrased as ‘Why can’t (system/technology/device) X do Y. or Why do I have to have eleven applications open to run a clinic? Or, most heartbreakingly, if only this (system/technology/device) did X, we could achieve this ‘really-amazing-new-thing’ and save hours or create better outcomes for patients or make an important part of that service work smoothly. If it had been just one or two of these instances, I might have been fine finishing up my contract, turning back to the games industry and finding a new company to help build and succeed. It was instead, depressingly frequent. A few of these clinicians, took the time to educate me on how the NHS did things and how disjointed and frankly half-arsed some of the multi-million pound programmes appeared to be. Coming from where I did, it horrified me; professionally, as a user of the NHS and as a taxpayer.Reader, I got angry. I continued (carefully and cautiously) asking questions and looking for myself, the picture never improved, I kept waiting for the other shoe to drop, I must be missing something right? No. Part of me wanted to shout and scream, but that would have been counterproductive. Anyway, I’ve always been the type to try and fix things, so I stayed. And I promised myself I wouldn’t leave until it was fixed. I still carry that anger mostly it just simmers now.
London, 1989
I got my first proper IT job at the end of the eighties. I was really lucky and didn’t yet know it; I worked for Reuters. We were the best paid, best trained and even better, best led IT workers in the city. Reuters had caught the wave when the City was deregulated post-big bang and by the time I joined they were the biggest game in town for financial data and market news. They spent billions (1990’s billions at that) on the infrastructure to deliver their products, I joined a team of over 400 shift workers, all employed keeping the golden geese happy and delivering eggs. We had a mantra, drilled into us pretty much from the outset. It leant on Reuters’ journalistic roots: - First, be accurate. If we published data, it absolutely had to be correct, 100%. Second, be timely. When we published data, it had to be actionable and immediate; microseconds count. Third, be reliable, day on day, week after week. We had to deliver the above, consistently.
There were (and presumably still are) all manner of technologies deployed to deliver on this mantra. Some, simple and robust. Others, exotic and bleeding edge. I can’t detail any of these here (Still under NDA!) but I can talk to how the human processes and procedures we developed and deployed to deliver on this, worked. (Sometimes called the 8th layer in the OSI stack, or more crudely, the meat layer) Kaizen, Lean, Six Sigma, ISO9001. Anything that could give us an edge was eagerly consumed and deployed. The business we were in was and still is ruthlessly Darwinian, we were constantly chasing marginal gains, adding extra 9’s to the sigma (Six Sigma was in our view, a bit lightweight; we managed seven and eight sigma for many of our systems routinely)Despite the very formal team structures we had, with crystal-clear operational responsibilities and authority to act (we had a lot of ex-Royal Navy types who worked there) there was also a complementary flat structure when it came to how these marginal gains were identified and deployed. Simply put, if you found the problem, it was yours to fix. No passing it up the line or handing it off. You did it. It didn’t matter if it was a mess someone else had made or if it was outside of your normal responsibilities. You did it or made sure it got done. It was a heady place to work, it has spoiled me for working anywhere else since. It wasn’t perfect by any means, but for the time, it was bloody close. It’s one of the sources of my ongoing anger. I want to be chasing the same marginal gains in the NHS, I want us to be chasing down that next 9 rather than lurching all over, as we contend with God knows how many years of legacy systems, uncommunicative silos, balkanised organisations, and the all too frequent ‘not invented here’ attitude I’ve heard more than I care to recall.
Brighton, 1999
‘Why isn’t the queue running out the door?’ I said to the recruiter. I was at a job fair standing at a desk where the job advertised was as a game tester. I handed my freshly printed CV, full of Reuters’ earned IT certifications that ran to a whole page at this point. Totally unsuited to the role I was applying for. There was, however, a small section at the end in ‘interests’, that hinted at my PC and console gaming obsession. ‘Someone will call you later, we’re well busy’ the recruiter replied. I’d left the City after rather a horrible year. 1998 was my personal annus horribilis. I won’t detail here, but I was still in a rough place, a year later. I’d escaped to Brighton to join my brother and spent the following summer partying and forgetting. The money was running out though. A job was needed and I was bracing myself to join one of the regional bank offices or worse, American Express. I was spared this fate. Someone did indeed call. I had a job testing games, 48 hours later.
‘Can you ask them if they’ve actually read my CV?’ this was to the QA lead. Four glorious months of late nights, pizza deliveries and sweaty geeks, playing and testing games. (Dungeon Keeper 2, if you’re interested.) I’d just heard one of the directors walking past, bemoaning the fact that they’d lost the third person who’d been hired as IT manager, on their first day. He didn’t quite run away screaming, but he did walk rather quickly. Ten minutes later, they’d read my CV and I was hired on the spot as the fifth full-time employee of Babelmedia. I was back in the saddle. Well, sort of. They couldn’t afford an actual saddle. The company had been founded about nine months prior, an offshoot of a game development studio. They’d launched a game that was actually pretty good, but it had failed on launch due to some pretty dire QA issues. It got panned in the games press and disappeared from sight, shortly after. Smarting from this, a new venture was run past the CEO; to create a company that got QA right. Especially where language QA was concerned (they call it localisation testing). Some favours were called in from around the industry and they raided the local universities for European native linguists and games players. Babelmedia started in a converted flat on Western road and in the first five months it went gangbusters. The fancy new office behind Hove station a few months later was their first expansion and the expansion never really stopped. We doubled the size of the business every six months for the following six years. Keeping up with this kind of expansion, from an IT infrastructure and services perspective is a tall ask. Part of me still wonders whether I should have run screaming too. With a budget and resources allocation that can charitably be compared to a couple of used Marmite pots, a ball of second-hand string and a bag of stale Murray mints, I barely kept ahead. The demands required that I pivot from my corporate thinking to one of extreme creativity, I didn’t sleep a lot for the first two years, but I really didn’t care. I was having too much fun.
In those six years we grew to a company that operated in three continents. We had major offices in Brighton (Hove, actually), Delhi and Montreal. A recording studio in London, sales offices in Los Angeles and Tokyo and several thousand employees, when all the translators and freelancers were counted in. We were one of the major players in the games-services sector, our client list read like a who’s who of the major games industry companies. We even got a feature written about us in Edge magazine, a singular honour. One of our biggest coups was being hired to create the first app certification platforms for mobile phone games. This was before iPhone, so it was mostly Nokia phones. We designed the certification process for both Vodafone and Sun Microsystems (the makers of Java). Certification of software is a process that is most often used in closed software platforms. The certification processes that we were used to prior to this, were those used by the major console players; Nintendo, Sony PlayStation and Microsoft XBOX. It works like this. Let’s use Sony as an example. You’re a development studio and you want to develop a game for PlayStation. OK, Sony will sell you a licence (after some due diligence) to develop a game, they’ll issue you with a Software Development Kit (SDK) and you also get to buy some special PlayStations designed for developing games and probably a few of the PlayStations designed for testing them. Part of the SDK is a phone-book sized document called the TRC (Technical Requirements Checklist)The TRC is your bible, therein you will find all of the do’s and don’ts of how your game shall work. You want to use a particular UI element? there are rules for that. You need to make a particular kind of call to the graphics engine in the console? Rules for that too. You get the idea. When you’re done developing (probably a few years later) you tell Sony, ‘Hey we’re done!’ Can we release the game already? They will book your game into a slot, for compliance testing. This is often done well in advance; you don’t want to miss the holiday season rush. They will take your finely honed and hopefully well-made game and during that booked slot, put it through a series of exacting tests, to make sure you really did follow the rules in the TRC. If you did, then yay! The game is released for mastering and disc duplication and hopefully, on the shelves in time for Christmas. If you fail compliance testing, however. Oh, my. Well, the next available slot is in six months. Too bad. We hope you do better next time. What do you mean, the marketing is already done? Sorry, can’t help you there. Sounds horrifying, yes? I’ve seen it happen. Grown men crying, the whole shebang. What does this have to do with the NHS I hear you ask? What’s all this games industry waffle for, and why would we want to have such an objectionable process for our software? It’s bad enough as it is! I’m getting to that. And yes. I really do think we need such a process in the NHS.
Brighton, 2024
QA is such an important thing in the games industry, delivering a finished, polished and compelling product that will sell, calls for the highest possible standards in software development. Every element of the game is gone over thousands of times, every possible player nutation is agonised over, the user experience honed to a fine edge, with hundreds of expert eyes looking not only for errors, but also ways to improve and optimise it. Imagine the kinds of amazing healthcare and clinical applications we’d have in the NHS if the software we acquired, had some form of minimum set of standards applied to application design, UX and usability.
This is the rest of the reason I’m still angry. I’ve seen how good software is developed and deployed in other industries and it’s not like there isn’t the talent for it out there. Standards are needed, good ones too. The process above is a worst case scenario, I’m not saying that we copy the Sony example slavishly, but a certification process and compliance testing for NHS applications that told developers, these are what you have to do. Nothing less will suffice; it won’t get in if you don’t. If we did this, I might think my work here is done, and calm down a bit. Where to begin though. It’s fine having standards but if no-one pays much mind to them, then why bother? I don’t have all or even any of the answers, necessarily. I’m here to learn. I’d like to contribute to the ongoing discussion about what we should be doing. What does good look like? How do we define and refine our standards for the clinical informatics we commission, develop and use. I do strongly believe that we need a set of common, enforced standards for these systems and perhaps, one day even better; common systems and platforms in use across our whole service.
Join us
If you want to hear more about Simon’s amazing story, please do register and join us at the Let’s Talk Digital Conference 2024 on the 24th of October. Sign up here.
Simon Latimer
Simon is a Systems manager in University Hospitals Sussex where he’s worked for the last 17 years. Prior to this he was a City of London banking IT consultant that found the NHS after mucking around in the games industry for a while. He’s held pretty much every job title that has ‘IT’ or ‘Computer’ in it from trainee to CTO. Still a keen gamer and in more recent years has extended his nerd credentials by taking up D&D.