Why did I bother writing +F? There are already plenty of fully-featured, freely-available Spectrum emulators for more or less any platform you care to think of. Indeed, I remember using a perfectly playable one on the Commodore Amiga as far back as 1994 or 1995 (ZXAM by Antonio J. Pomar Roselló), so it’s hardly a novel idea.
I did have a little twist which I wanted to add, which at the time I started writing didn’t appear to be available in any other emulator, namely the ability to play games across the Internet. (It turns out that RealSpec claims to do this and more, but I haven’t tried it.)
More than just that, though, it was probably inevitable I would end up trying this sooner or later. Much like mountaineers are reputed to climb mountains “because they’re there”, or lovelorn teenage boys write dreadful and embarrassing poetry, the chances of a programming geek with a fondness for 80s gaming writing an emulator are rather high. (Given I’d already written a Chrome plugin that uses CSS to emulate Spectrum loading borders, it’s safe to say that I’ve got form.)
So Mr. Nerdy-Nerdy has a warm, fuzzy feeling about his pet project, you may be thinking. Very good, move along.
And to a certain extent, you’re right. There’s nothing novel about +F and I certainly wasn’t planning to blog about it. Indeed, if I was just a programming geek by night, I probably wouldn’t have, but I’ve actually also been a programming geek by profession for the best part of two decades. When you do anything for that length of time, you run the risk of it becoming an overlearned skill, something you don’t necessarily need to devote much conscious thought to. You learn all manner of techniques and best practices from the people you work with, you learn your own lessons, pick your favourites, and you’ll also probably tend to adopt and fit in with the way that your team works.
Combine that with time pressures and shifting requirements, and it can be easy to go through the motions and forget why you do things the way you do them. Best practices only become so because they have been shown to provide benefits, but it’s easy to forget this and slip into something of a ritualistic mentality about the way you build software. If our code coverage metrics hit the magic number, we make sure the digits of our release number don’t add up to thirteen, and we sacrifice a chicken, the software gods will smile upon us and our release will be successful.
With +F being a personal hobby project, and me being answerable to nobody but myself for its success or otherwise, I wasn’t subject to the formalities of software development which I’ve become used to in my day job. I could completely freely choose which ones to follow and which ones to ignore. It’s fair to say that there was a fair amount of unwarranted bravado about the choices I made, an air of it can’t be that complicated (wrong), I do more difficult things than this every day (wrong again) and I’m old enough to know what I’m doing (even more wrong) about my approach.
The result is the catalogue of gaffes, goofs and prat-falls you’re going to read about in this blog. I will, of course, make the odd diversion into the simultaneously mundane and fascinating details of emulation, but what I really want to get across as I write is that there really are good reasons why we do things the way we do, and if we lose sight of that then we are bound to repeat the mistakes of the past.
That does sound rather heavy and fatalistic, but the flip-side is to realise that yourself and others have already done the hard work of figuring out how to do software well, and it’s that note of encouragement I hope you take away with you.
I hope you find my writing enjoyable.