Though I’m not a software developer or tester, I often test software in my unsophisticated way and I do about three lines’ worth of coding from time to time if I really can’t avoid it, and my all-time best friends and collaborators in my work are testers and developers.
And I encounter this problem every day that, for example, a client complains about the mysterious and undesirable behavior of the software, and then the first step towards the solution is that the tester tries to reproduce the error, which isn’t necessarily easy, and which often brings up several questions: is the client’s situation so special or unfortunate that no-one else experiences the problem? Is it perhaps the case that the problem only occurs if there’s a full moon and there are exactly 24 users trying to do the same thing at the same moment and the stocks of the company dropped 2 percent that day and the cousin of the CEO gave birth to twins? Is it perhaps the case that the bug is not a bug at all, and the software is supposed to work like that? (But who is to say how things are supposed to work?
Questions abound, and there are often no comforting answers. And I often see and experience the frustration and desperation a tricky software error can cause, but I must admit I’ve never so far thought of software testing (and development) as a deeply existentialist act and a never-ending search for meaning.
When in fact it’s exactly that – we’re standing completely alone in the face of the unknown, a basically hostile, unknowable and meaningless world (problem) and though we know (we think we know) how everything should be, things are usually not the way they should be, nothing is simple, and the solution (if we’re lucky enough to find any) is often just that the software only works when there’s a waning moon, there are only 23 parallel users, the stocks are rising and the cousin of the CEO gave birth to a daughter; or in a worse case it’s just that this is how it works, this is how it always worked, this is how it will always work, and life’s cruel, anyway.
Perhaps I would never have realized this philosophical dimension of my everyday reality without this novel, so I’m glad I read it. Partly because from now on, I’ll always see software testing and development as a more exciting, more romantic, more adventurous, more heroic, more tragic, more meaningful activity, and partly because this is a good novel.
As you can guess, the main characters of the novel are a young and very determined tester, Roberta, and a developer, Ethan, who team up to catch an evil bug that always appears at the worst possible moments then disappears for weeks, that sometimes gets tantalizingly close and sometimes retreats to a hazy distance, as if mocking our hapless adventurers who are out to get it. The quest slowly reaches epic proportions as the bug starts to threaten the sanity of the characters and threatens to ruin the company.
There’s a fight against time here (because the investors want to go to market with the software as soon as possible but they can’t do that because of the bug), there are sexual and other tensions among the characters, there are malevolent enemies with scornful smiles on their face who can hardly wait for Ethan to fail – so this story could well turn out to be a Hollywood-style romantic action movie. It doesn’t, though.
Like I say, this is a pretty dark existentialist novel which also explores the topics of human vs. machine, analog vs. digital, existing in time vs imperfectly capturing individual moments of time.
The scariest part is that it’s perfectly understandable how a supposedly simple bug hunt slowly leads to ruin, to mania, to withdrawal from life, to panicky, all-night attempts to find the culprit. And the fact that the enemy is not in the physical reality but in the hidden circuits of a machine doesn’t make Ethan’s struggle less desperate.
The main story is, by the way, set in 1984 – which probably has a symbolic significance, too, but I was most taken by the idea that programmers in 1984 were already struggling because they had no idea just what the hell their predecessors wanted to achieve with their code. In my naivety, I thought this must be an issue of the 2010s but apparently this problem is eternal, and every single line of code has always been just an attempt to interpret and use the lines of code that came before that.
And the death of human relations is perfectly understandable, too – a human relationship is also a game of life (a topic which deeply fascinates Ethan) – it dies or lives on depending on the surrounding conditions. And what goes on in the circuits of the computer can have very real consequences, even if the software in question isn’t a high-tech tool responsible for the safety of airplanes or nuclear power plants but only a boring little database management application.
Books, my ego and entropy 