This is the beginning of the essay "Behind the Blip: Software as Culture
(Some Routes into “Software Criticism,” More Ways Out)" from Matthew Fuller's new collection of essays, Behind the Blip: Essays on the Culture of Software. For a pdf version of the entire essay along with supporting materials from the book (388K), please click here.

Software Criticism?

There are two questions which I would like to begin with. First, what kind of critical and inventive thinking is required to take the various movements in software forward into those areas which are necessary if software oligopolies are to be undermined? But further, how are we to develop the capacity for unleashing the unexpected upon software and the certainties which form it?

Second, what currents are emerging which demand and incorporate new ways of thinking about software?

One of the ways to think about this problem is to imagine it as a series of articles from a new kind of computer magazine. What would happen if writers about computers expanded their horizons from the usual close focus on benchtests and bit-rates? What would happen if we weren’t looking at endless articles detailing the functionality of this or that new version of this or that application? What if we could think a little more broadly—beyond the usual instructional articles describing how to use this filter or that port? What, for instance, would it mean to have a fully fledged “software criticism”?

First, let’s look at what already exists. Certainly, we are not short of examples of prior art. In terms of the academy, sociology, for instance, offers: Jeannette Hofmann’s descriptions of the gendering of word processor software and its patterns of use within work; Paul N. Edwards’s history of the development of computer technologies through the models of science promotable at the height of the early cold war; Michael R. Curry’s formulation of a technico-aesthetic economy of signification and ownership in geographic information systems; Donald MacKenzie’s work on the political implications of floating-point-unit calculations in the design of missile guidance systems—the list goes on and extends to substantial areas in ethnography and anthropology. Material based around philosophy and literature includes Michael Heim’s Electric Language and the contributions of Friedrich Kittler, despite his assertions that the object of attention here does not exist. We can also look to texts which come out of bookshops, but that don’t get libraried up so much: Howard Rheingold’s Tools for Thought and J. David Bolter’s Turing’s Man, for instance. This list is certainly short, but it does continue. The creation of imaginary bookshelves is as good a way of thinking through combinations as the imaginary museum, and there are three areas in particular which seem to offer elements recomposable into a more thoroughgoing strand of thought about and with software.

Human–Computer Interface

Human–Computer Interface (HCI) is obviously one area that should be turned to. This is, after all, the point at which the machinations of the computer are compelled to make themselves available in one way or another to a user. The way the computer makes available such use, and the assumptions made about what possible interactions might develop, are both fundamentally cultural.

Given this, HCI has an unusually narrow understanding of its scope. Much of the rhetoric is about empowerment and the sovereignty of the user, whose “personality” shapes and dialogues with the machine. It should be asked what model of a persona, what “human,” is engineered by HCI. We should not settle for answers that stray anywhere near the singalong theme-tune of “empowerment.” (Let us not forget that much of the methodology of HCI is still derived from theories that led B. F. Skinner to assume that he could train pigeons—in the days before Cruise—to act as primitive guidance systems for missiles.)

It seems clear that the vast majority of research and production in this area remains concerned with imposing functionalist models on all those systems that cohere as the user. Perhaps given software’s basis in boolean logic, where every action must be transmogrified into a series of ons and offs held in hundreds of thousands of circuits, this is inevitable at a certain level. Make no mistake, HCI works. It is productive because it belongs to a long line of disciplinary idealisations of the human that nevertheless have the capacity to latch onto flesh. The mainstream of HCI is considered here to be those largely positivist approaches which are represented in standard formulations of the discipline such as the Handbook of Human–Computer Interaction. When it comes to arranging the most suitable combination of ergonomics and information-design to ensure that a pilot can drop bombs or stockbrokers can move funds in the most efficient, information-rich, yet graphically and emotionally uncluttered manner, HCI delivers the goods. Reaction times—the number of interactive steps from task identification to task execution—can be measured. The results can be tabulated against variants of the system. The whole can be fine-tuned, pixels shifted, operatives retrained: the loop between stimulus and response tightened into a noose. This is the fatal endpoint of the standard mode of HCI. It empowers users by modelling them, and in doing so effects their disappearance, their incorporation into its models.

There are, of course, many “human-centred” variants on such designs. Yet this kind of naming illustrates its fatal flaw. There is still a model of the human—what constitutes it, how it must be interfaced—being imposed here. Some developments in software design have been made by acknowledging this. Alan Cooper’s approach to interface design works, for instance, by establishing a number of stereotypical users of a system. They are imagined as full “characters,” users of a system which is reworked, primarily in terms of interface, in order to meet an aggregate of their needs. The deliberate fiction of user identities is made visible at the design stage in order to allow greater insight into the techno-aesthetic composition of the software. A small, useful step would be to make these manufactured identities, but treat them as psycho-social open source.

More broadly, much could be gained by a change in the focus of HCI. In its emphasis on perception, on narrowly applied psychology, it has split the user from any context. One thing that is compelling about software is how it contains models of involvement with processes rather than simply with static elements—think about groupware, or the way in which most previously discrete applications have become part of wider suites of processes, to say nothing about the inherently modular nature of Unix. What would it mean to incorporate an explicitly wider notion of such processes into software—to reinfuse the social, the dynamic, the networks, the political, communality (perhaps even instead of, or as well as, privacy)—into the contained model of the individualised user that HCI has us marked down for?

We can see movements toward this in sociology- and psychology-derived currents within HCI such as Participatory Design. Here, there is a range of collaboration between users and designers that aims to stake out a territory for certain models of what a user becomes interfaced to. Notably, this territory can sometimes even be defined geographically, as in the institutional, corporate, and trade union uptake of this approach in Scandinavia. What these approaches allow is a removal of the more or less negative preconditions of the standard model of HCI that is simply applied to users by experts. The area of Computer Supported Co-operative Work brings some of these elements together, but largely as a way of making them function, of turning them to account.

One tendency that is of interest here is in the proliferation of higher-level languages and authorware. These allow for currents of design that place value on experimentation, rather than adherence to pre-formatted notions of functionality, to invade the conceptual and practical space of the computer. At the same time, capacities for invention do not belong solely to those who most often claim them; the problem of design, of interface, must be set in wider terms.

A key problem here, though, is the danger that a set of questions tend to stabilise out as particular techniques in which something gets solved. Software is a place where many energies and formations meet. At the same time, it constantly slaps up against its limitations, but these are limitations of its own making, formulated by its own terms of composition. Software is always an unsolved problem. We need ways of thinking into and activating this process of becoming, rather than some “kinder” or more “creative” design."