Algorithms and their others, or disciplining ‘algorithm studies’

Canny commentator and provocateur Prof. Paul Dourish has a relatively recent piece in the journal Big Data & Society concerning the fashion for ‘algorithm studies’, the definitional wrangling that has ensued (i.e. people arguing over what the word means) and some proposals for what he suggests is an alternative approach

“which might put aside the question of what an algorithm is as a topic of conceptual study and instead adopt a strategy of seeking out and under- standing algorithms as objects of professional practice for computer scientists, software engineers, and system developers.” (p. 9)

Dourish proposes a kind of Foucauldian STS-style strategy for sketching out what Doreen Massey might call the ‘geometries of power‘ of specific instances of what gets called algorithms, and what kinds of power the idea of ‘algorithm’ does or doesn’t have in those (for want of a better term) institutional assemblages.

The article is an incisive and authoritative overview of the contemporary interdisciplinary debates around ‘algorithms’ and deftly outlines the frictions and tensions between the current fashion for ‘algorithms’ and the other terms that may or may not be important to the study of the phenomena we mean when we use that word. In this case Dourish offers some discussion of (software) architecture, automation, code, (big) data structures, and programs. This is a really thoughtful exposition of the stakes of the debate and a level-headed attempt at moving on the discussion. Useful interlocutors (to my mind) throughout are Alexander Galloway and Adrian Mackenzie, references to whose work are present at key points in Dourish’s discussion. This is a really clear article and probably should be an essential read for those concerning themselves with ‘algorithms’.

A really important point, which isn’t often considered, that Dourish makes very clearly is that:

One reason that an algorithm can be hard to recover from a program is that there is a lot in a pro- gram that is not ”the algorithm” (or ”an algorithm”). The residue is machinic, for sure; it is procedural, it involves the stepwise execution of one instruction followed by another, and it follows all the rules of layout, control flow, state manipulation, and access rights that shape any piece of code. But much of it is not actually part of the – or any – algorithm.
…

An algorithm may express the core of what a program is meant to do, but that core is surrounded by a vast penumbra of ancillary operations that are also a program’s respon- sibility and also manifest themselves in the program’s code. In other words, while everything that a program does and that code expresses is algorithmic in the sense that it is specified in advance by formalization, it is not algorithm, in the sense that it goes beyond things that algorithms express, or even what the term ”algorithm” signals as a term of professional practice. (p.4)

I suppose the one point of caution I’d suggest is that while excellent, Dourish’s article highlights to me the narrowness of the discussion – the relative closeness (and perhaps closed-ness) of those involved and the ways in which ‘discipline’ (and I suppose, then, ‘authority’) might thereby becoming enacted. Indeed, following Dourish’s strategy it might be (ironically) interesting to chart the forms  of ‘professional practice’ through which ‘algorithm studies’ take place. The list of people and institutions Dourish acknowledges at the close of his article offer a possible starting point…