Whodunnit?

Recently, I have been watching far too many murder mysteries on the television, so forgot to write an editorial. Some are more serious than others. We have several episodes of Midsomer Murders [IMDB-1] saved, which we dip into from time to time. This long running series is a typical ‘whodunit’ (pronounced “Who done it?”) [Wikipedia-1], where someone is murdered near the start and you spend the next hour or so trying to decide who the murderer is. Over time, the series resorted to adding more and more murders and the plots became more and more silly, leaving you guessing what ridiculous plots twists may come next rather than trying to remember who died and who the murder might be. Other murder mysteries are available. A whodunit is very different to a thriller, in that the former goes backwards and forwards in time, filling in clues, while the latter usually moves forward in time, ramping up the sense of suspension. One encourages you to guess who is responsible while the other makes you wonder what happens next. I suggest both types of narrative crop up while we write or run code. Many other types of fiction can happen too as we attempt to create software.

The ACCU conference talks are now showing up on YouTube, giving me even more to watch instead of writing an editorial. Matthew Dodkin’s talk [Dodkin22] encouraged us to expect the unexpected and think about what happens next. He talked about dolphin and bat detectors, requiring long deployments (months). You chuck them overboard in a remote location and wait, meaning you can’t easily monitor remotely – and go back and get them later. This necessitates the need to minimize and handle failures and keeping a log of what happened somewhere accessible is useful. Matthew talked about various ways to ‘handle’ problems, including an error handler which does nothing, in effect ignoring problems, or sits in a while loop doing nothing. He also mentioned asserts and said you should “disable them in production code that needs to keep running, unless you are extremely confident about what happens next.” Furthermore, he suggested using ‘what happens next’ as a useful thought-experiment for designing all your error handling functionality. In order to avoid any further plot spoilers, I’ll say no more but leave you to watch the talk’s recording. Other ACCU conference talks are available.

“What happens next?” fits the thriller genre better than a murder mystery, though the advice to leave accessible logs does chime with a crime investigation. When we try to figure out what went wrong in code, logs are often a first port of call. Of course, they tell us what happened previously rather than what’s up next. Writing useful log files is a bit of an art form. Chris Oldwood has spoken and written about this on many occasions. In an article for Overload, he claimed log files rarely contain anything helpful and suggested ways to do better [Oldwood15]. His 2019 conference talk encouraged us to avoid the stream of consciousness style of logging, and add a little structure [Oldwood19]. Writing a stream of consciousness ‘story’ is one thing, and can be cathartic; however, trying to read it might not be so easy. James Joyce’s Ulysses is often cited as an example of this style of writing and many people, myself included, who try to read it, give up. I lost track of who the characters were, and lost the plot, if there really is one. Wikipedia quotes an example on its ‘Stream of consciousness’ page [Wikipedia-2]:

a quarter after what an unearthly hour I suppose theyre just getting up in China now combing out their pigtails for the day well soon have the nuns ringing the angelus theyve nobody coming in to spoil their sleep except an odd priest or two for his night office the alarmclock next door at cockshout clattering the brains out of itself let me see if I can doze off 1 2 3 4 5 what kind of flowers are those they invented like the stars the wallpaper in Lombard street was much nicer the apron he gave me was like that something only I only wore it twice better lower this lamp and try again so that I can get up early

Many log files read like this. Don’t get me wrong, a tumble of word associations and ideas can be fun. I recently reminded myself of the ‘lyrics’ to Eat, Sleep, Rave, Repeat by Fatboy Slim. The words tumble and you only partially follow what’s going on.

And then this cat walked in
You know, not like a cat
Like a feline cat
Like a real, like you know
Like
You know what I’m saying dog
Like cats and dogs
It was raining

Logs can aid us in detective work after the fact if they contain the right clues. If we can debug code, which wasn’t the case for the bat and dolphin sensors, we can watch things play out in real time and that can take time too. Finding the best place to put a breakpoint is important. I’ve lost hours deep down inside a call stack when the problem was actually somewhere completely different. In some ways, this ends up like the tumbling lyrics or stream of consciousness style of writing. It’s very easy to lose the plot. Always time-box debugging and try to find more efficient ways to work out who or what ‘done it’, like writing a unittest if you can. Sometimes a program crashes and gives you a useful core dump. This so-called post-mortem analysis tells you where to start looking and is often way quicker than stepping through every line of code. Silent Witness anybody? [IMDB-2]. You can also use diagnostic tools on live code in order to figure out why strange things are afoot.

Before ever running the code, you might use a compiler along with static analysis tools. When faced with a wall of errors, it sometimes takes some investigation work to find one offending line. Have you ever resorted to a binary search taking smaller and smaller chunks of code out until you find the cause of the problem? Maybe you tried ctrl+Z to undo code until you got back to a clean state, or maybe you used version control? Hurrah for small commits between changes, otherwise you may have a very large search space! Playing detective is part of programming and leaving yourself a trail of easy to follow clues is a good idea. For unscripted languages, you can lean on the compiler to find problems and even code usage, by changing a name or type and so on [Feathers04]. Scripted languages may seem like another genre, but often don’t have much of a plot either. However, the interpreter and static analysis tools can also help you avoid a potential crime scene.

There’s often more to coding than just the source code. As mentioned, if you’re kind to yourself, you’ll be using version control. Not only does that help you undo any changes that broke things, but also keeps track of who did what, when. Unless you use git lie squash on the commits, of course, or change a username to ‘deleted’ when they leave, which is not unheard of. Many have a ‘blame’ command that displays which line was changed by whom and when. If you’re trying to solve a coding crime, this can be useful. I’ve heard it claimed that blame might be a bit of a negative frame of mind, and ‘praise’ might be due sometimes. That’s fair – not everything coding is problem fixing and troubleshooting. Sometimes, it’s actually fun. You may be using some kind of work tracking system too, perhaps Jira. Jira, in and of itself, is fine. Left to my own devices, I’d use a simple Kanban board or just a TODO list, however keeping track of what needs doing is the important part. And yet many people complain about Jira. It is configurable, which, again, in and of itself is fine. You can even write stories, or epics, which is nice. But, and this is the reason for most of the complaints, Jira can be configured to a point of pain or even left on its defaults, forcing you to add various fields and tick many boxes to move a story through to the finale. Once a process becomes onerous, people get inventive and find work-rounds. If coding ends up as a form-filling Kafkaesque nightmare, and I don’t mean the distributed event-streaming sort, I mean the writer Kafka’s bureaucratic nightmare world. More screaming than streaming.

Sometimes ‘whodunit?’ doesn’t actually matter. What’s more important is how you are going to fix it. Fix the problem, not the blame, as the saying goes. Sometimes we may never find out whodunit, but that’s OK. What’s important is how we move on. It’s all too easy to get caught up in gossip and rumour, or follow a hunch down a rabbit hole. If you’re trying to release code or fix a bug, you need to keep your eyes on the prize and avoid being distracted (too much) by other things, like most of the UK government resigning or tweets about the C++ on Sea conference. Many places I have worked at use the pattern of ascribing the blame to the last person who left. As soon as someone starts asking “Who on earth wrote this code?”, then reply is “So-and-so, remember them?” You are supposed to then say “So-and-so who?” and concentrate on the task in hand. The culprit isn’t important, rather making progress is. Knowing who is responsible won’t stop a repeat performance. You might end up in a non-fiction version of Groundhog Day [IMDB-3] with variations of the same thing happening over and over again.

Sometimes ‘who did it’ really does matter. I often try to look up a source for a quote and find various conflicting suggestions. It’s good to be able to reference a source for a variety of reasons, but if you can’t, you can’t. If you can, you can leave clues for readers to follow, so they can draw their own conclusions. Some theorems, physical phenomena and computing ideas are named after the person who invented them, for example Pascal’s triangle, the Higgs boson or the Liskov substitution principle. We do sometimes find that names are misattributed though. I was told about the Rutherford experiment at school, and later learnt he was the supervisor and the experiments themselves were performed by Geiger and Marsden [Wikipedia-3]. You could argue that science or knowledge is more important, but if someone’s name is associated with an idea making them more well-known, this might skew our understanding of history, particularly if they didn’t do it. In effect, this rewriting history is a lie. I already told you what I thought of git squash to rewrite history! Misappropriations happen, though we can strive to avoid making things worse. And it’s lovely to ensure you credit someone if they have contributed or helped in some way. So, thank you to all our writers and the review team.

We’ve considered a few styles of fiction, and though programming isn’t really fictional, it is a creative process and it may involve stories or actors (of Carl Hewitt et al’s formalism, rather than thespians [Hewitt73]). Sometimes real drama is involved if you have a prod outage or other catastrophic failure. Sometimes the code you are using seems somewhere between fantastical or a farce, littered with ‘Here be dragons’ or ‘Wtf?!’ comments on the way.

References

[Dodkin22] Matthew Dodkin, ‘A Year In A Rainforest: Engineering For Survival’ from the ACCU 2022’ conference, available online at: https://www.youtube.com/watch?v=Zua4twRU2VU

[Feathers04] Michael Feathers (2004) Working Effectively With Legacy Code, Addison-Wesley

[Hewitt73] Carl Hewitt, Peter Bishop and Richard Steiger (1973) ‘A Universal Modular Actor Formalism for Artificial Intelligence’ IJCAI, available at: https://www.ijcai.org/Proceedings/73/Papers/027B.pdf

[IMDB-1] Midsomer Murders: https://www.imdb.com/title/tt0118401/

[IMDB-2] Silent Witness: https://www.imdb.com/title/tt0115355/

[IMDB-3] Groundhog Day: https://www.imdb.com/title/tt0107048/

[Oldwood15] Chris Oldwood, ‘Terse Exception Messages’, Overload, 23(127):15-17, June 2015, available at: https://accu.org/journals/overload/23/127/oldwood_2110/

[Oldwood19] Chris Oldwood, available at https://www.youtube.com/watch?v=O6NJgcK6K7g

[Wikipedia-1] Whodunit: https://en.wikipedia.org/wiki/Whodunit

[Wikipedia-2] Steam of consciousness: https://en.wikipedia.org/wiki/Stream_of_consciousness

[Wikipedia-3] Geiger & Marsden experiments: https://en.wikipedia.org/wiki/Geiger%E2%80%93Marsden_experiments

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.