For the duration, I believe this blog is going to move in a slightly different direction than it has in the past. I’ll use this oddly titled post to explain what that means and why that is. By the end of the post, the title won’t seem so odd.
In terms of my career, I’ve often moved fairly orthogonal to the wider test industry. I have found that there’s value in that but I’ve also found that there’s only so long you can sustain being a cultural gadfly. I’m one of those people that feels the testing industry is in most danger from its own practitioners. I’m also one of those people that feel many of the most vocal advocates for testing are actually doing more harm to the testing discipline than help.
I could be very wrong on all that. But that is how I feel.
In terms of the blog, and coupled with the above feeling, I have more and more often felt like I’ve said all that I have the capacity to say right now in the arena of quality assurance and testing. Or, at least, I have little more to say that differs from what everyone else is already saying. That’s been one of the key conceits of my blog: to not just sound like every other tester out there.
At some point I do want to undertake a historical revisit of my various posts and perhaps update them with what I’ve learned, as a way of keeping myself not only intellectually curious but also intellectually honest. For now, however, I’m going to take this blog down a path that is slightly orthogonal. What this means is that the blog will likely become a bit of a vanity project and that, of course, entirely risks losing any readers.
Oddly, I find I’m (maybe?) okay with that for now.
But let me explain what I’m going to be doing since it is related to the wider themes of testing and development that I’ve talked about for many years now.
Grue: The Z-Machine Project
I’m going to create a series of articles under the category of “Z-Machine” and that category name is indicative of what I’ll be doing. Specifically, I’m going to work on creating a working emulator of the Z-Machine and an interpreter for zcode programs that will run on that machine. This means I will be building an Interactive Fiction interpreter. Depending on your age and/or nostalgia factor, you might better know “interactive fiction” by the name “text adventure.” (Fun fact for nostalgia retrogamers: the term “interactive fiction” was likely first used by Robert Lafore.)
The Z-Machine was originally created by a company called Infocom back in the late 1970s to play their adventure game Zork on microcomputers (which were the first “personal computers” with a side evolution into “home computers”). Eventually this Z-Machine was used to play a lot of adventure games created by the same company throughout the 1980s. Starting in the 1990s, after Infocom was acquired by Activision and effectively dissolved, hobbyists reverse-engineered the Z-Machine and adventures have been created for it ever since.
The project will be called Grue and you can read up more on the concept of a “grue” in this context, should you find yourself curious.
But … Why Do This?
Awhile back I wrote my testability series. And in that series, I showed how it was quite easy for bugs and bad design decisions to crop up in even the simplest of examples. But that was very much a toy example to demonstrate some points. The Grue project will be quite a bit more illustrative because, in the end, I do fully intend to have something that demonstrably works.
There are a couple of interesting challenges to this project.
It became clear to me that the Z-Machine Standards Document — which is essentially the requirements — is probably one of the poorest written specifications I’ve ever seen. To remedy this, a document was created — “The Z-machine, And How To Emulate It” — which somehow manages to be even more poorly written and gets a few things wrong to top it off.
Eric Lippert started a “How to Write a Z-Machine”series but he chose OCaml as his language, which pretty much no one uses seriously, and left the series entirely unfinished. There’s good stuff there but, on the whole, it’s not really useful. Gerben Castel did an excellent “Discover Rust with Zork” article but that was more about learning Rust than the implementation of a Z-Machine. There was a Z-Machine Preservation Project that aimed to provide an “implementation that is easy to understand maintain and extend.” In the end, the project was ported from Java to Scala — zmpp2 — which didn’t do much for the “easy to understand” part.
In the end, I found nothing out there really useful to help construct a Z-Machine beyond the open source implementations that you can find on GitHub or GitLab. And those implementations are often incomplete, certainly with regard to supporting the Z-Machine specification. So that’s where this project comes in: an attempt to create just enough of a Z-Machine emulator and interpreter to make sure I understand how the thing actually works and to where I can create a working implementation. This will, in turn, be something that I can share that is (apparently) unique in terms of being available.
Along the way, I’m curious to see how I can test this thing as I go through developing it. This helps me be a student of my own craft. To be an effective tester, I often have to understand the theory of error and categories of error when people engage in creating complex things, like software. This helps me understand why it’s hard to build software — not just at the common sense level, but as an actual practitioner. The fact that I will be dealing with a less than ideal specification also matches a lot of what I tend to deal with in my professional capacity.
Who Is the Audience?
I hope this project will be of interest to various audiences. One audience might be software developers in general. Another audience might be a more specific band of developers who would be interested in learning how to create a Z-Machine emulator and interpreter. Yet another audience might be testers who, like me, believe you have to understand the development craft from the inside out in order to be the most effective tester you need to be in our industry. This includes engaging with developers on design and, more particularly, on testable design.
For those who want to join me on this journey, it could be a lot of fun. The adventure begins in the next post where I’ll talk about the programming ecosystem I’ll use for this.
