The goal of a post-mortem is an opportunity for a team (or the broader organisation) to learn as much as they can, in a relatively short period of time, about how people normally perceive and perform their work. This is because the people involved were in their normal work when the incident happened. Questions should focus on the ways that the organization prevents this sort of event from happening all the time, not by asking what allowed this singular event to happen.

Over the last year or two I’ve been on a bit of a kick of reading the original sources for several common CS (or other) topics. You’d be surprised about how many ‘oft quoted’ concepts don’t have the origin you’d expect.

There is an old joke:

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter.

Which I found at the above quoted ‘guppylake’ website¹. However, when I found the CSCW ‘92² scan of the same article the quote itself is missing (and the text differs in other slight ways as well). All other references to the quote drastically postdate both of the previous references.

Code review and CI/CD are one the few practices with actual empirical support.

Meta Comment

This post was written in reply to a specific post discussing removing code reviews entirely.

If you set your HTTP proxy to theoldnet.com with port 1999, and add an exclusion for web.archive.org, then all your web pages will come from 1999, via the Wayback Machine. You can pick a different year by changing the port.

Example

$http_proxy=theoldnet.com:1996 no_proxy=web.archive.org curl http://nintendo.com

Source

LeoPanthera. (2024, January 19). Comment on ‘Surf the web like it’s 1999’ [Comment]. Hacker News. https://news.ycombinator.com/item?id=39058806

Recusal motions for judicial bias were unknown at common law in England, and none would exist in federal courts until 1911. There was no standard of appearance of partiality, and none would exist in federal courts until 1974.

Source

Reginald Alleyne. (2003). Arbitrators’ Fees: The Dagger in the Heart of Mandatory Arbitration for Statutory Discrimination Claims. 6. page 35-37

“The Annotated Turing” by Charles Petzold ¹

Many of us have learned about ‘Turing Machines’ or ‘Turing Completeness’ but have never actually read the motivating text and explanation. This is a phenomenal book that goes through paragraph by paragraph the paper “On Computable Numbers” ² by Alan Turing in a rigorous way explaining the concept intuitively and completely. Not only does it explain the text, but it also gives enough background so that one could understand and follow through the proofs themselves. It is well written and clear without feeling like a textbook. It is divided into fours sections:

I recently read “The leprechauns of software engineering” by Laurent Bossavit ¹. The book goes through a few myths about software engineering and then traces how those myths entered the public consciousness. It was well worth reading for anyone interested in research based software engineering practices. It was primarily useful on how to verify about claims rather than the claims themselves. While I’ve heard of most of the myths - I also heard about them as myths rather than as true claims. It reminded me a lot of “Making Software” ². Core Insights:

People pay attention to high value communication channels. These give them information about the job, hobby, etc. Since people pay attention to these channels, they get used more. Eventually they get used for something more borderline or inappropriate for the communication channel. When this happens people stop paying attention to the formerly high value channel and shift to new locations. Eventually the original channel is useless. Rinse and repeat for the new communication channel.

I recently watched a video on mistakes investigators make in accident investigating. It was worth watching but because its video it is difficult to skim or remember. This blog post is to make it to write down what I learned in a textual format to make it easier to find and remember later

This is the video:

The three mistakes were

When a piece of code is first written it easy to maintain quality. However, several things contribute to loss of quality.

New and unexpected requirements may happen. This may violate the initial layering rules. New people may join. Newer people know less and then make more local changes. This results in global invariants becoming local invariants.

Chesterton’s fence is a curse here and one of the reasons that documentation is so important.