	New content
Science, Technology, & Human Values

Restricted access

Research article

First published Autumn 2005

When Is a Work-Around? Conflict and Negotiation in Computer Systems Development

Neil PollockView all authors and affiliations

https://doi.org/10.1177/0162243905276501

Abstract

The notion of a “work-around” is a much-used resource within the sociology of technology, reflecting an interest in showing how users are not simply shaped by technologies but how they, through adopting artifacts in ways other than those for which they were designed or intended, are also shapers of technology. Using the language and concerns of actor-network theory and focusing on recent developments within computer-systems implementation, this article seeks to explore and add to our understanding of work-arounds through unpacking the work of one group of “users” as they attempt to tailor and roll out a system within the administration departments of their university. This article argues that paying attention to the various networks that lead to and from work-arounds can improve our understanding of the way users both shape and are shaped by technologies. Focusing on work-arounds as “networks in place” also allows us to highlight some of their contingencies; for example, the other actors and entities on which these depend and are constituted.

Get full access to this article

View all access and purchase options for this article.

Get Access

1. Such forms of use ranged from users entering inaccurate data to bypass weaknesses in existing systems, to users simply manually carrying out the procedures the computer system is meant to do and inputting the job after the work has been completed.

2. See the work of Claudio Ciborra (2002).

3. Kathryn Henderson (1999), for example, uses but does not develop the term in her recent book on engineers and their use of CAD. See also the article by Marc Berg (1997), in which he describes how nurses work around the limitations of a medical record system. For an example of how the notion of a work-around is used in the loose body of thought that comes under the heading of Computer Supported Co-operative Work (CSCW), see the article by Luff and Heath (1993). More recently, Button and Sharrock (1998) use the term to describe how programmers circumvent an incompetent manager.

4. Scripts, argues Akrich, are often simply the outcome of decisions made by designers about future users—their skills and abilities and what the technology should do in relation to this user. Through the script: “... the designer expresses the scenario of the device in question—the script out of which the future history of the object will develop” (216).

5. See Berg (1997), who makes a similar point about writing within the social studies of technology.

6. This differs from Akrich, who describes a script as embedded within an artifact, whereas Michael is suggesting that scripts are both in the technology andin the wider networks attached to the technology. In other words, Michael’s is a more dynamic notion of script where notions of use are the upshot of an interaction between the artifact and this larger network. A technology can hardly be thought as separate from, say, its instructions for use, as the artifact’s working depends on these. In paraphrasing Pfaffenberger, he writes: “... technologies don’t have instructions for their use inscribed in their design. Discourses are needed which guide users in their appropriate use” (1996, 3).

7. Friedman (1989), for instance, writing in the field of information systems, lists at least six user roles, which include not only those who simply input and retrieve data but also users who initiate systems and those who are involved in development and implementation as well as maintenance.

8. See the article by Button and Sharrock (1994) in which they also describe programmers as users.

9. Collins Concise Dictionary, Fourth Edition, HarperCollins, 1999. For an explanation of this quote see the discussion below.

10. See Janet Rachel (1994), who makes a similar point when referring to her own ethnography and the apparent inactivity of the programmers she witnessed, though she notes that the activityof these programmers was “... produced through the appearance of inactivity” (819, her emphasis). Behind these seemingly still bodies, however, they were furiously typing away on keyboards “... networked together in an effort to accomplish change on a grand scale in other parts of the organization” (819).

11. The apposite image of a true “Delphic” Support Desk is the one that I want you to keep in mind here.

12. See Ciborra (2002) for a detailed discussion of bricolage.

13. In their article, Star and Ruhleder (1996) ask whenand not whatis an infrastructure. Here, in their intriguing article, they are rehearsing the sociology of technology commonplace that technologies are not just things with particular properties “frozen in time” but emerge for people in the practice of technology use. Likewise, infrastructure, they argue, is also a fundamentally relational concept: “It becomes infrastructure in relation to organized practice. Within a given cultural context, the cook considers the water system a piece of working infrastructure integral to making dinner; for the city planner, it becomes a variable in a complex equation.”

14. The key paper for this form of ambivalence within the approach advocated by Akrich is Singleton and Michael (1996). They argue that while actor-network theory has tended to story “successful” networks as those where the actors strictly play out their allotted roles, in practice actors often move between different positions (i.e., sometimes critical, sometimes supportive of the network). Indeed, as they argue, this crossover of roles often enables the very continuation of the network.

15. For a discussion of emergent skills, see Andrew Pickering’s Mangle of Practice(1995).

16. Leigh Star (1995) has described this as the “myth of infinite flexibility,” where in principle, software can be modified, but in practice it is very difficult to do so as changes will affect other parts of the system. This is especially true for integrated software systems (see Pollock and Cornford (2004) for a discussion of the difficulties of customizing Enterprise Resource Planning Systems).

17. For a discussion of software as a mediator, see also Born (1997).

18. The outcome of this negotiation will decide if the local programmers will receive further help in modifying that aspect of the system.

References

Akrich, M. 1992. The de-scription of technical objects. In Shaping Technology/Building Society: Studies in Sociotechnical Change, ed. W. Bijker, and J. Law. Cambridge, MA: MIT Press.

Abstract

Get full access to this article

References

Cite article

Cite article

Download to reference manager

Share

Share this article

Share with email

Share on social media

Share access to this article

Information

Published In

Keywords

Rights and permissions

Authors

Affiliations

Metrics

Journals metrics

Article usage*

Articles citing this one

Figures & Media

Tables

Get access

Access options

Sign in

View options

PDF/ePub

Also from Sage

Article usage^*