acm - an acm publication


Review of 'Social thinking - software practice,' by Yvonne Dittrich, Christiane Floyd, and Ralf Klischewski, eds.

Ubiquity, Volume 2002 Issue August, August 1 - August 31, 2002 | BY Paul Duguid 


Full citation in the ACM Digital Library

Mind the Gap

Social Thinking-Software Practice Yvonne Dittrich, Christiane Floyd, & Ralf Klischewski, eds. Cambridge, MA: MIT Press, 2002 ISBN 0-262-04204-5

Social Thinking -- Software Practice is the outcome of a three-year joint effort to address the gap between social science and software practice. Given the task, the 21 essays by 34 authors are suitably multidisciplinary. Authors come from departments of accounting, anthropology, computer science, design, engineering, informatics/information, library science, media, sociology, software engineering, and "space and virtuality." The book is also suitably international. The collaboration began in Germany in 1999, traveled to Aarhus, and concluded in Copenhagen the following year. The authors, multinational but with a clear Scandinavian tilt, reflect this border-hopping. They come from Australia, Denmark, Finland, Germany, Nigeria, Norway, Sweden, United Kingdom and United States. Divided into five parts with catchy, if not always wholly appropriate names (Deconstructing, Informing, Grounding, Organizing and Reorienting), the book called to mind a train in the way it takes time to get its variously coupled parts and disparate passengers under way. For me, it particularly recalled a London Underground train. People familiar with those trains will recognize the caution (puzzling to many Americans) to "Mind the gap," barked at passengers as they get on or off. Social Thinking -- Software Practice invites us, both directly and indirectly, to look out for, "bridge," and even take advantage of a variety of different gaps in the course of its journey.

The initial gap to mind falls between the software designer and the user. Critics have rightly castigated designers for underestimating this gap and taking users' needs, requirements, activities and predicaments for granted. To mind this gap, most but not all of this book's authors insist, requires the intervention of the social sciences. Such intervention, they believe, will in the end lead to better software. (This "better," it needs to be said, is more often mentioned than defined in the course of the book.)

Rolling into this particular station can give an uneasy feeling that our train is going backwards. For here is the gap that Lucy Suchman (rightly a central influence on almost every essay here) exposed so critically 15 years ago. But then again, life today often does call for reruns. Just as new-generation stockbrokers reveal their lack of prior experience when faced with a bear market, so a new generation of computer scientists, brought up in the digital boom, looks equally exposed as the promised digital future crumbles. In trying to explain why promises, technology and social systems break under the sort of pressure that the hopes and hype of the '90s imposed upon them, there is nothing wrong with going over the fundamental critiques of cognitive science once again.

But, the book doesn't just run over old tracks. It has other, subsequent gaps to expose. In particular, it turns attention towards the gap between the social researcher and the software practitioner. Reassessing social science from this perspective is important. In clumsier hands, Suchman's arguments were sometimes used to beat software designers over the head for their brute insensitivity. Did they not understand the user? Whack! Did they not know that their perspective was flawed? Whack! Did they not realize that they were reinstantiating capitalist power relations? Whack again! It is hard to listen while being knocked about the head, so even some of the best-intentioned software designers did not. The gap only grew wider, and the designers took most of the blame.

Of course, there certainly were many computer scientists who did not understand the complexities of social practice. But this book offers a welcome antidote to the sort of condescension software practitioners suffered at the hands of social scientists and the implicit claim that, by contrast, social scientists did understand. And no doubt computer scientists could be as insensitive as the next person. But so too, the reflective and reflexive essays here remind us, could social scientists. Indeed, while some social scientists fought nobly to protect the vulnerable user, they often ignored the vulnerabilities of software designers. The latter are usually (with exceptions I shall note in a moment) enmeshed one way or another in large, powerful organizations. Metaphorically hitting them over the head with a weighty edition of Foucault for their ignorance of power was, if not wholly inappropriate, then at the very least insensitive to their predicament. Refreshingly, several of the essays call out for a better understanding of that predicament and more generally a greater sensitivity to the organizational context of software design. "Software development organizations are organizations too," Jacob N�rbjerg and Philip Kraft feel compelled to say, suggesting rightly that this truism has somehow been overlooked.

Sadly the insight isn't taken a great deal further so we don't get much sense of the possible contributions theories of organization might make to understanding this gap. Such theories should help explain why corporate software is not, as some social scientists naively wished, inherently emancipatory. After all, economists from Ronald Coase to Oliver Williamson have argued that organizations form around hierarchy. In a related argument, Herbert Simon (a figure, much cited in this book, who does bridge the gap between economic theory and computer science) explained employment as the resignation of free will in return for pay. No one has to accept these arguments as gospel. But in trying to understand the relationship between the practice of software designers, the organizations for which they work, and related uses and abuses of power, it would be helpful to discipline arguments with a little theory of the firm before punishing poor designers for their ignorance of power.

The book pays more attention to how, as well as overlooking the vulnerabilities of those they criticized, some social scientists also overlooked the vulnerabilities of their own methods and predicaments. No doubt computer scientists had trouble "understanding" the user. But the past 15 years have not shown conclusively that social scientific viewpoints are necessarily superior or pragmatically more useful. A few authors here confidently claim to detect or even "show" progress made by bridging the gap. But several authors ask quite directly whether social science, entrapped in its own uncertainties and doubts, is in a position to offer help to software practice. While one, Chris Westrup, boldly asserts that software practitioners are doing their own form of social science research and should be left to do it in peace. But overall, there is a stark, appealing honesty in those authors who focus instead on gap-bridging projects that, though begun with brimming confidence, ended in failure. Major gaps, Geraldine Fitzpatrick wisely suggests, remain unbridged not because of the folly of computer scientists, but because they are fundamentally "wicked" problems.

So the question remains, how well are the social and computer sciences equipped to deal with "wicked" problems? The book does not come to a united conclusion on this point. In this way as in others, this is not the book for people looking for rapid answers. But at least it does not succumb to the sort of methodological warfare that often follows such uncertainty. (Social scientists, while not necessarily given to the sort of abuse found on Slashdot, are nonetheless prone to intradisciplinary fighting.) Rather, the book suggests a willingness among the authors to try to pull in the same generally forward direction. The contributors nevertheless deal out a few whacks of their own to certain venerable methods in this field -- ethnomethodology, participant design, HCI, computer supported cooperative work -- for failing to deliver on promises. But they generally and generously paper over cracks among themselves. This may have taken serious effort on the part of either the contributors or the editors, for some of these gaps are quite profound. Yet while harmony is usually more attractive than conflict, such papering is not always a good thing and exposing gaps can be productive.

Among the different groups represented here, the one that is harmonious in theory yet curiously tendentious in practice is Actor Network Theory (ANT), presented by one of the editors, Ralf Klischewski. ANT dismisses with evenhandedness critical theoretical gaps and the viewpoints that claim to explore them. Consequently, ANT proponents claim variously to have dissolved distinctions between subject and object, the social and the technical, the macro and micro, or the human and machine. ANT's catholic embrace spreads over all, regardless of difference, bringing, for example, humans and machines into the common category of "actants." But with that claim, the train once again appears to be going backwards. For one of the great strengths of Suchman's work lay in the way it exposed the gap between the human and the mechanical that AI enthusiasts like Simon had glossed over. Central problems arise, she argued, if we fail to make distinctions between the way people and machines not only "think" but also "act." Several of the authors in this book -- from Christiane Floyd, who begins it, to Thomas Binder, who ends it -- also believe the distinction to be valuable and the gap to be irreducible, indicating significant subterranean gaps between the authors involved in this book.

For her part, Suchman used the difference to launch a theoretical challenge to the strong AI hypothesis. The two, humans and modern computers, essentially run on different tracks. And much of the value of technological development has come by taking advantage of the complementarity of the two, as many of the problems have come from ignoring this. So it is worrying to see attempts -- even if they are attempts that, ANT like, gain relatively little following among computer scientists -- to switch the two back onto the same track. Yet strong ANT is at base both compatible with strong AI and generally indifferent to the implications of such a claim. (In fairness, Klischewski, ANT's representative here, seems unwilling to back the strong ANT hypothesis and expresses doubts about the symmetry between human and nonhuman actants.)

In Social Thinking -- Software Practice, a strong contingent of Activity Theory proponents offer the most coherent (and I suspect incompatible) alternative theoretical perspective to ANT. This gathers traction by the final section, "Redirecting." The essays here suggest that, in contrast to ANT's elision, distinguishing between people and tools in an activity may not only be more comprehensible (despite the layer of in-house jargon you have to deal with), but also be more pragmatically useful. And from this follows a rather different way to "mind the gap." Americans tend to find the phrase puzzling, as I mentioned above, because they use mind to mean "take care of" or "look after" rather than "avoid." And after 400 pages about how to avoid or obliterate gaps, the last three essays (by Olav Bertelsen and Susanne B�dker, Sara Eriks�n, and Thomas Binder) start to pull in a different direction, suggesting that we work with what Bertelsen and B�dker call "discontinuities" rather than against them.

In arguments that I find particularly congenial (in part because John Seely Brown and I once tried to make similar ones), Eriks�n leans heavily on a comparison between software design and architecture, while Binder draws attention to "form" and "materiality" in the task of conveying not only content, but intent. Both suggest that to understand not simply information but communication we need to take physical space and material objects more seriously. While information science reveals a Gnostic's desire to free the soul of information from the material body, these essays remind us that information comes to us through machines. Machines and their users are physically embodied and located in the world. The differences between people, machines and information are real. Acknowledging the gaps for what they are, the final essays suggest, will help turn apparent constraints we have been working futilely against into resources we can work productively with. So for me the book manages to end on a positive note. If we "mind the gaps" appropriately, the train might indeed be capable of going forward.

It may, then, seem churlish of me to end on a more negative note, but I do want to point to one glaring gap left by the book as a whole. Here we have a book on software practice, conceived in 1999, published in 2002, and yet with no discussion of Open Source software (OSS). As far as I can see, there is but one mention -- a throwaway line at the conclusion of Victor Kaptelinin's essay. (The impoverished index is no help.) OSS has radically undermined venerable certainties about, for example, the value of markets, the role of organization, the necessity of intellectual property regimes, and the way robust software is built. It surely insists, then, that we also reappraise the relationship between social thinking and software practice, which is why it is a pity that this book with such an agenda fails to address OSS.

Hitherto, a good deal of the social thinking about software practice has looked at such practice within firms -- which is why, as I suggested earlier, it needs to address the theory of the firm. But OSS doesn't fit tidily within firms. Nor, however, does it sit simply outside firms, as some of its more libertarian proponents would suggest. Rather, it troubles the border, muddying the "make or buy" distinction that people previously used to distinguish what is within from what is without. For firms using OSS neither quite make it themselves, nor buy it from others. And if OSS doesn't fit tidily within firms, then the sorts of social thinking reflected in this book doesn't fit tidily within OSS and will need to be reappraised.

In particular, the social circuits within which OSS is developed need to be reassessed. There has been a lot of overheated talk about "gift economies" -- as if such an underspecified notion could deal with the "social" aspects of OSS practice. Such talk requires more suspicion than it has received. It is certainly odd to hear academics talk sanctimoniously about gift economies, particularly as they tend to include their own work, for which they are in general thoroughly well paid, as an example of such gifts. And it can also be worrying to hear it from the OSS world, too, because it distracts us from important questions about where money is coming from, where it is going, and what effects it will have on the networks of practice involved. (Will IBM's largesse affect Apache? Will Apple's interest change freeBSD? We can't really know if we simply hide the gap between the corporation and the software contributors under the title "gift relations.") Moreover, when we turn to that initial gap between the designer and the user, we can see that ordinary users have good reason to beware of geeks bearing gifts. For, while undoubtedly productive and generous, OSS developers tend to give, like calculating siblings, working with themselves as the model of the ideal recipient. Consequently, they accept too readily that their experiences and desires generalize. But it is precisely because these don't generalize that it so hard to span the gap between the highly skilled designer and the ordinary user. Spanning this gap requires what the poet Keats called "negative capability," the ability to see the world from another's point of view. And that, more than anything else, is an art.

It is because they fail to reflect the challenge of crossing such gaps, I suspect, that KDE and GNOME, OSS graphical user interfaces, while undoubtedly extraordinary efforts, are remarkably unwieldy and charmless, with none of the appeal to geek and nongeek alike that, by contrast the commercial OS X evidently has. Commercial organization of software design, long demonized by OSS contributors and social theorists alike, evidently has significant strengths in bridging that gap. I am not suggesting that all OSS programmers should therefore go and work for Microsoft. But I am suggesting that they need to try to understand better how commercial organizations cultivate this negative capability. In the case of KDE and GNOME, the complex journey back and forth between designer and user, production and consumption, that Binder indicates we need to understand if we are to design well, has been short circuited. As a consequence, while in execution, OSS takes us into radically new areas, in design (and not just interface design) OSS may be surprisingly conservative and narrow. Unskilled at bridging such a gap, KDE only helps Microsoft look good, GIMP gives Adobe a good name, and so on. So in the world of OSS, we find a remarkably innovative kind of train. But from the ordinary user's perspective it is still standing at the station with an untold number of engineers (and a remarkable track record at hauling network freight) but far too few passengers willing to board. Something extra seems to be needed to get the latter over the gap, onto the train, and out of the station. It could be some equally innovative social thought.

Paul Duguid is an independent researcher. From 1991-2001 he was a consultant at Xerox PARC and is currently a research associate at UC Berkeley and part time visiting professor at Copenhagen Business School. For the academic year 2001-2002, he lived off his wife and a fellowship from the Red Hat Foundation. He is co-author with John Seely Brown of The Social Life of Information (Harvard Business School Press).


Leave this field empty