The Organizational Accountability of Technological Work

Social Studies of Science

Volumn 28, Issue 1, 1998, Pages 73-102

  Button, Graham ^a   Sharrock, Wes ^b  

^a Xerox Research Centre Europe   (United Kingdom)

^b UNIVERSITY OF MANCHESTER   (United Kingdom)

Author keywords

[No Author keywords available]

Indexed keywords

EID: 0032390943     PISSN: 03063127     EISSN: None     Source Type: Journal    
DOI: 10.1177/030631298028001003     Document Type: Article

References (53)

1. See Andrew Pickering, Constructing Quarks: A Sociological History of Particle Physics (Edinburgh: Edinburgh University Press, 1984), and Peter Galison and Bruce Hevly (eds), Big Science: The Growth of Large-Scale Research (Stanford, CA: Stanford University Press, 1992).
2. See Andrew Pickering, Constructing Quarks: A Sociological History of Particle Physics (Edinburgh: Edinburgh University Press, 1984), and Peter Galison and Bruce Hevly (eds), Big Science: The Growth of Large-Scale Research (Stanford, CA: Stanford University Press, 1992).
3. See Max Weber, Wirtschaft and Gesellschaft (Tubingen: J.C. Mohr, 2nd edn, 1925).
4. See, in particular, Talcott Parsons, The Structure of Social Action (New York: McGraw-Hill, 1937).
5. See, for example, Karin Knorr-Cetina, 'How Superorganisms Change: Consensus Formation and the Social Ontology of High-Energy Physics Experiments', Social Studies of Science, Vol. 25, No. 1 (February 1995), 119-47.
6. See, for example, Andrew Pickering, The Mangle of Practice: Time, Agency & Science (Chicago, IL: The University of Chicago Press, 1995).
7. Knorr-Cetina, op. cit. note 4, 124 (emphasis in original).
8. Garfinkel's programme was initially worked out in his PhD thesis (H. Garfinkel, The Perception of the Other: A Study in Social Order [Cambridge, MA: Harvard University, June 1952]), and in his unpublished work A Parsons Primer, and is operationalized in a modified form in his Studies in Ethnomethodology (Englewood Cliffs, NJ: Prentice-Hall, 1967). For an introduction to this programme, see Wes Sharrock and Bob Anderson, The Ethnomethodologists (Chichester, Hants.: Ellis Horwood, 1986). Also see John Heritage, Garfinkel and Ethnomethodology (Cambridge: Polity Press, 1984).
9. Garfinkel's programme was initially worked out in his PhD thesis (H. Garfinkel, The Perception of the Other: A Study in Social Order [Cambridge, MA: Harvard University, June 1952]), and in his unpublished work A Parsons Primer, and is operationalized in a modified form in his Studies in Ethnomethodology (Englewood Cliffs, NJ: Prentice-Hall, 1967). For an introduction to this programme, see Wes Sharrock and Bob Anderson, The Ethnomethodologists (Chichester, Hants.: Ellis Horwood, 1986). Also see John Heritage, Garfinkel and Ethnomethodology (Cambridge: Polity Press, 1984).
10. Garfinkel's programme was initially worked out in his PhD thesis (H. Garfinkel, The Perception of the Other: A Study in Social Order [Cambridge, MA: Harvard University, June 1952]), and in his unpublished work A Parsons Primer, and is operationalized in a modified form in his Studies in Ethnomethodology (Englewood Cliffs, NJ: Prentice-Hall, 1967). For an introduction to this programme, see Wes Sharrock and Bob Anderson, The Ethnomethodologists (Chichester, Hants.: Ellis Horwood, 1986). Also see John Heritage, Garfinkel and Ethnomethodology (Cambridge: Polity Press, 1984).
11. Michael Lynch, Eric Livingston and Harold Garfinkel, 'Temporal Order in Laboratory Work', in Karin Knorr-Cetina and Michael Mulkay (eds), Science Observed: Perspectives on the Social Study of Science (London: Sage Publications, 1983), 205-38, at 206.
12. Garfinkel (1967), op. cit. note 7, Chapter 1, 'What is Ethnomethodology?', 1-34.
13. See Harvey Sacks' discussions of greetings and adjacency pairs, in his Lectures on Conversation, Volume II (Oxford: Blackwell, 1992), 188-99, 554-60.
14. We do so because reviewers of this paper have asked us to provide information about the organization and the projects we studied, and also about 'how we did it'. 12. See Ian Sommerville, Software Engineering (Wokingham, Berks.: Addison-Wesley, 1987).
15. One way in which software engineering teams are organized is into groups that correspond to the modules that make up a program. Thus on Archer, the engineers were assigned to different modules, such as the 'faults module' and the 'interface module'.
16. See Graham Button and Wes Sharrock, 'The Mundane Work of Writing and Reading Computer Code', in Paul ten Havé and George Psathas (eds), Situated Order: Studies in the Social Organization of Talk and Embodied Activities (Washington, DC: The University Press of America, 1995), 231-58.
17. See Debrah Tatar, A Programmer's Guide to Common LISP (Bedford, MA: Digital Press, 1987).
18. The other projects used an in-house language called 'SEQUEL', which was also very close to machine code. For a more detailed consideration of the problem of understanding involved here, see Graham Button and Wes Sharrock, 'Occasioned Practices in the Work of Software Engineers', in Marina Jirotka and Joseph A. Goguen (eds), Requirements Engineering: Social and Technical Issues (London: Academic Press, 1994), 217-40.
19. Simon Levy, Hackers: Heroes of the Computing Revolution (New York: Doubleday, 1984).
20. Button & Sharrock, op. cit. note 16.
21. See Frederick P. Brooks, Jr, The Mythical Man-Month: Essays on Software Engineering (Reading, MA: Addison-Wesley, 1982), esp. the Chapters entitled 'The Tar Pit', 3-9, and 'The Mythical Man-Month', 13-26.
22. The work of the project is treated as 'problem-solving', and the engineers' tasks are primarily those involved in investigating and solving problems. The work-to-be-done is thus partitioned into 'problems'; these are assembled into a centralized list of numbered and detailed problems, with selected ones then allocated to each engineer. Allocation takes into consideration factors such as: The kind of problems they are; the responsibilities of the engineer within the project; the specialist skills available to the engineer; the extent to which they are unique; and the size of the 'problems list' already in that engineer's hands.
23. For example, recording that the fault code displaying on the interface of a prototype machine was incongruous with the fault occasioning the display.
24. The 'problem wheel' was a scheme involving colour and numerical coding: so, for example, 'Red Six' was the final stage, where the engineer(s) working the problem had identified a solution and were about to implement it.
25. We borrow the phrase from Enid Mumford, Designing Participatively (Manchester: Manchester Business School, 1979), 7-9. We do not, however, borrow her methodological orientation.
26. Our phrasing here strays into issues that have been raised in debates about the relationship between the social and the technical: see, for example, Wiebe Bijker, Thomas Hughes and Trevor Pinch (eds), The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology (Cambridge, MA: The MIT Press, 1987). We are not so much concerned here, however, with the theoretical and epistemological issues involved in this debate but, rather, with describing how, in the course of routine practices, the distinction between the social and the technical is, on some occasions, drawn by the engineers, and yet on other occasions, obscured by them. Our general observations about the way in which the engineers make visible the relationship between the social and the technical in their work concur with those of Janet Rachel and Steve Woolgar, when they note that technology practitioners are often quite comfortable with the idea that the technical is constitutively social ( J. Rachel and S. Woolgar, 'The Discursive Structure of the Social-Technical Divide: The Example of Information System Development', Sociological Review, Vol. 43 [1995], 251-73), though we would add that the socially organized character of technology is not merely something they are 'comfortable with', but is something which they treat as the most routine, commonplace and indispensable fact of their working lives.
27. Our phrasing here strays into issues that have been raised in debates about the relationship between the social and the technical: see, for example, Wiebe Bijker, Thomas Hughes and Trevor Pinch (eds), The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology (Cambridge, MA: The MIT Press, 1987). We are not so much concerned here, however, with the theoretical and epistemological issues involved in this debate but, rather, with describing how, in the course of routine practices, the distinction between the social and the technical is, on some occasions, drawn by the engineers, and yet on other occasions, obscured by them. Our general observations about the way in which the engineers make visible the relationship between the social and the technical in their work concur with those of Janet Rachel and Steve Woolgar, when they note that technology practitioners are often quite comfortable with the idea that the technical is constitutively social ( J. Rachel and S. Woolgar, 'The Discursive Structure of the Social-Technical Divide: The Example of Information System Development', Sociological Review, Vol. 43 [1995], 251-73), though we would add that the socially organized character of technology is not merely something they are 'comfortable with', but is something which they treat as the most routine, commonplace and indispensable fact of their working lives.
28. By 'engineering knowledge' or 'technical knowledge', we do not mean anything portentous, any more than the engineers would. It is the knowledge that engineers have of electronics, mechanics and the like, which they apply to the problems they encounter. The fly-fisherperson displays a 'technical knowledge' of the behaviour of trout and salmon, and the lie and turn of the river; the bird-watcher displays a 'technical knowledge' of bird behaviour, habitat, calls and the rest. In neither case is such knowledge necessarily certified by 'science'; rather, it is tied to the techniques of an activity and its traditions.
29. Rubber insulating nodules.
30. The company in question practises the 'Total Quality Management' philosophy, one aspect of which provides standardized guidelines for developments in order to ensure the 'quality' of the product. For an introduction to TQM see, John Oakland, Total Quality Management (Oxford: Butterworth Heinemann, 1989).
31. These matters are 'flexible', in that it is possible to reschedule, or to obtain additional staff and budget. However, even this flexibility is practically constrained because, in the end, there is a limit to the resources that will be made available, not to mention the strategic problems and complexities of rescheduling, restaffing and rebudgeting within the context of the organizational processes involved.
32. But not in any sense which affiliates them with metaphysical 'realists'.
33. See Edward N. Yourdon, Techniques of Program Structure and Design (Englewood Cliffs, NJ: Prentice-Hall, 1975); Yourdon, Structured Walkthroughs (Englewood Cliffs, NJ: Prentice-Hall, 2nd edn, 1979); and Yourdon, Managing the Structured Techniques (New York: Yourdon Press, 2nd edn, 1979).
34. See Edward N. Yourdon, Techniques of Program Structure and Design (Englewood Cliffs, NJ: Prentice-Hall, 1975); Yourdon, Structured Walkthroughs (Englewood Cliffs, NJ: Prentice-Hall, 2nd edn, 1979); and Yourdon, Managing the Structured Techniques (New York: Yourdon Press, 2nd edn, 1979).
35. See Edward N. Yourdon, Techniques of Program Structure and Design (Englewood Cliffs, NJ: Prentice-Hall, 1975); Yourdon, Structured Walkthroughs (Englewood Cliffs, NJ: Prentice-Hall, 2nd edn, 1979); and Yourdon, Managing the Structured Techniques (New York: Yourdon Press, 2nd edn, 1979).
36. Before the introduction of structured methodologies, developments would often be embarked upon before the requirements for development, such as the tasks the software would be used to support or automate, were analyzed. Remarkably, the requirements would only be fixed in the course of the development. See Sommerville, op. cit. note 12.
37. Button & Sharrock, op. cit. note 16.
38. This matter is extensively discussed in Robert J. Thomas, What Machines Can't Do: Politics and Technology in the Industrial Enterprise (Berkeley, CA: University of California Press, 1994).
39. The company is traditionally hardware-dominated, and the 'lore' among the software engineers is that their work is invariably subservient to the priorities of hardware.
40. A programming language that is intermediate between high-level languages such as C and machine code.
41. We previously referenced TQM in our consideration of less-than-ideal-circumstances. We are not now contradicting ourselves when we say that TQM has been devised to provide dependable work practices. This is because our previous consideration took account of a conflict between imperatives derived from different networks of dependable work practices. We are not saying that these work practices do not themselves engender problems. We are saying that engineering work involves attempting to contrive arrangements that can be relied upon, mechanisms that can be deployed to confront the ever-present problem of organizing the work of engineering. Even the best sets of tools can let their users down, but it is the frequency and extent to which they will do so that is of concern to engineers.
42. Sommerville, op. cit. note 12.
43. We emphasize this point in the light of a reviewer's complaint about a previous draft of this paper, that we caricature 'the engineer or alternatively the coder, as an undisciplined, in need-of-supervision, messy and rather unresponsible worker, whose behaviour leads to chaos'. We are puzzled as to how such an implication could be derived from our observations. If we were to caricature these engineers it would, rather, be as highly disciplined, autonomous and thoroughly responsible individuals. Should there be any 'undisciplined conduct', however, the company can deploy a standard range of organizational resources to deal with the individuals concerned, such as the personnel assessment, bonus and incentive payments, objective and salary-setting schemes.
44. We saw a teacher herding a large number of pupils out of a Cambridge college they had been visiting. As she did so, she counted them out of the gates. We inferred that, in counting, she was using a procedure for ensuring that all of her charges were accounted for, and to check that she had not inadvertently left any behind, but not because she was sloppy or ill-disciplined and had had that procedure imposed upon her by her headteacher. Rather, we supposed, she just faced the practical problem of accounting for the vast number of her charges, and she needed a systematic method to ensure that she had not overlooked one. The engineers, faced with a myriad of problems, and the pressures to solve them quickly, similarly need procedures they can use to order their work so as to ensure they have not overlooked a vital detail, or jumped to the wrong conclusion, or whatever.
45. 'Requirements' is a loose term for the functions that a machine should embody, and the purposes for which it should be used. There are various methodologies for engaging in 'requirements analysis', and arguments about their merits. Requirements are the interface between the user and the developer: sometimes there can be different interests involved which can conflict, for what may seem to be a simple user requirement can, from an engineering point of view, turn out to be a complex task. Thus not only is 'requirements analysis' a problematic part of software development, having engineers then develop their projects so as to instantiate the 'requirements' is also a problem. The various contributions to Jirotka & Goguen (eds), op. cit. note 16, discuss different aspects of the problematic character of requirements analysis: for an overview see the editors' introductory chapter, ibid., 1-13.
46. For an introduction to CASE technology, see Alan Fisher, CASE: Using Software Development Tools (New York: John Wiley, 1991).
47. Button & Sharrock, op. cit. note 16.
48. The Product Delivery Process is detailed in a complex, hierarchically structured assembly of paper and electronic documents in which abstract and general 'life cycles' are outlined, and are further decomposed into progressively more detailed versions as they move down the levels of the hierarchy.
49. Louis L. Bucciarelli, Designing Engineers (Cambridge, MA: The MIT Press, 1994).
50. Garfinkel (1967), op. cit. note 7, 12.
51. In the sense in which this phrase is used throughout Sacks, op. cit. note 10.
52. It is worth pointing out that the manner of dispensing with the 'problem wheel' in such circumstances was not a matter of denying its substantive cogency or applicability, but of dispensing with its formality - this group of engineers did not need to guide their engineering decision-making by reference to the formal steps to ensure that the requirements that the problem wheel was designed to enforce would in fact be met.
53. Egon Bittner, 'The Concept of Organization', Social Research, Vol. 32 (1965), 239-55.