Blame In Software Development

“Blame” is one of those words that we need to be careful around. On the one hand, it has a clear dictionary definition that we all agree on. On the other hand, it has an emotional set of associations that conjure up all manner of unhappy memories of stern teachers and parental figures that make use of the term highly constrained.

In most professional environments today, it is unusual to hear the word “blame” tossed around. In fact, the most common usage of the term is its negation: “Nobody is to blame here” or “we’re not here to assign blame.” It feels like every incident retrospective includes some variation on this sentiment.

Yet we all know what “blame” means. It is an assertion of a cause-and-effect relationship between one or more actions or decisions, and some undesirable outcome.

In software, we have a whole host of euphemisms for assessing blame: “incident report”, “retrospective”, “root cause analysis”, and I’m sure there are many more terms at our disposal. All of these terms have the same meaning. It is a process for assessing what decisions or actions led to the undesired outcome, who made those decision, and why. In other words, we are assessing blame.

The Commit Log

Assessing blame is an important need for any organization. As evidence, let us look at one tool used for assessing blame: the commit log.

In a source control system, we have a complete record of every single change ever made by everyone who has…