The practice of software development lends itself to examining the ways that "systems of people and machines (are), situated and distributed, and most of all, deeply heterogeneous" [11]. Like any other social activity the work of designing and developing software is situated in the sense of taking place in specific locations and being performed by people who act from their specific context of knowledge, tools, tasks, colleagues, (organizational) memory, and history. At the same time, much of this work is done by multiple, often distributed, groups, each with their own standards and practices. There also may be much geographical as well as cultural space between those groups. Although they may not be connected in ways that help create a shared understanding, they manage to develop a reasonably coherent and stable product—which will probably be used in many different places.
In this article we explore some of the practices that make the accommodation of multiple places and views within a software development team possible, as well as the limitations of some of these practices. We will in particular examine how the trade-offs between multiplicity and standardization [9] are managed within software development teams. We use the term "standardization" in a broad sense, referring to the practices, images, notations, standards, and tools that help actors to shape and align their work so that it becomes readable and usable by relevant others. Button and Sharrock [3] examine some aspects of the "methodic handling of tasks" within software engineering as "achieving an orderly character of the work." We argue here that such practices not only reflect the inherently contingent nature of the task itself, but the multiplicity of places and voices involved in accomplishing the task.
Our article is empirically grounded in different case studies of design practice that were discussed within the Software Cultures framework.1 Although all these cases are small (with the size of development teams varying between two to twelve people), they took place in a distributed environment of team and relevant others (management, vendors, customers, special experts within the customer organization, and finally, end users). Each of the cases offers a different view on multiplicity and standardization. Our own case study work has been analyzed in a previous article with a focus on issues of cooperative work and, more specifically, on configuration management as a practice and tool [12]. We refer to two additional cases: the Landscape Architecture Case [10] and the Danish Radio Case [6] for which we had the opportunity of doing some additional empirical work.
Bounding Heterogeneity
We approach the topic of heterogeneity using the language of space and place in both a metaphorical and a concrete sense. We can look at the physical and electronic spaces in which design work occurs. These are furnished with material artifacts of all kinds (among them computers, office equipment, manuals, books), and with all the knowledge of people and their object world of software tools, written code, specifications, flow charts, block diagrams, task lists, and other inscriptions. This space provides a place for both people’s ongoing interactions, and the objects they use and produce in their work. In his studies of engineering design, Bucciarelli [2] makes this distinction between actor worlds (as the world of ongoing social interaction and evolving work practice) and object worlds (as the space of tools and representations or inscriptions).
We build on the notion that places are not neutral. They shape the perspectives of those who inhabit them and the scripts they produce. It is in this sense that we use the term "software cultures." It is related to an understanding of culture as the situated practice of reading and writing in the world (and as therefore being grounded in place). The five cases illustrate different cultured practices of balancing heterogeneity and standardization.
The Methodically Disciplined, Shared Space: The Document Case
The Document Case (1986 to 1993) represents a highly complex software project that was carried out by a team of eight developers. The product was a document management system with a graphical user interface, including subprograms for scanning documents, for creating and managing document folders, for document retrieval and other server-based management functions such as database and jukebox management applications that should run on standardized platforms (MS Windows as client and OS/2 as server).
Distinctive to this case is the research orientation and pioneering atmosphere of the development team. As there was no suitable development environment for the project at that time (the 1.3 version of MS Windows was still quite primitive and not supportive of multiple networked users), the team developed its technical platform from scratch. Team members artfully constructed their object world from textbooks, papers, and products, disciplining it methodically—everything had to make sense in terms of structure and method. While multiple voices were heard and their resources tapped in the many ad hoc design sessions that took place, often at the request of one team member, the chief developer established a tight regime of practices for the implementation work.
A lot of effort went into building a shared development environment with identical development tools being installed on each computer. This grew into a shared electronic space, with PVCS (an Intersolv product) as a supporting configuration management tool. The amount of energy spent on defining and structuring the software architecture and on specifying the interfaces between modules and layers was quite unusual at that time. Great emphasis was put on elaborating readable coding styles and on making sure the structure of the program as well as the composition of each module (even though these were individually owned) was understood by all. A central artifact designed for boundary crossings was created in the form of technical documentation with detailed information on the software architecture, the dependencies between components, and API definitions, on both a graphical and textual level. This document crossed the boundaries to testers and documentation people, to vendors, and from there to customers. It also was used in public presentations of the product.
There was more to these inscriptions than their instrumentality. Their value was partly symbolic, a visualization of the research orientation of the team and the shared vision of the project. "It was an artificial world with its own rules," as one of the developers characterized it in retrospect. Artificiality here has two meanings, simultaneously alluding to the constructedness of this object world and its detachment from the pragmatics of aligning one’s approach to more mundane concerns such as deadlines. The team stubbornly stuck to a time-consuming, method-based approach instead of satisfying customers’ needs with a less-ideally designed product. While communication within the team was intense, there were strong boundaries against the outside world, which was shielded off as potentially hostile to the nature of the task (which was seen as internally driven): "This is a real issue, how to protect the development team from the outside world. This is a must if you want to develop something. A product is ready for delivery only when it is finished and that’s it" (Chief Developer).
The spatial analogue to this disciplined and enclosed world is the kitchen. This was the place were the informal life of the team was concentrated and the rule to endorse the vision of the team was most clearly present. The kitchen was always crowded and used in the same way as in a private home where it often becomes a center of activities.
Building software is about making links between a multiplicity of object worlds, practices, and commitments via imagery, metaphors, and descriptions that can translate different views of the artifact-in-development.
Separate Worlds—Respect for Personal Boundaries
This is a case of a development team of two specialists in graphical presentation software for the Austrian National TV. At the time of the case study (1994) they were developing an application supporting the presentation of the results of national elections on a Silicon Graphics platform.
The developers act as a loosely coupled team. They have some good reasons for practicing such a fragmented approach to a project, some of which date back to their university experiences when the two first met. One is specialization—developer A’s strengths are project acquisition and the hunting of new products, development, and graphical presentation tools. Developer B is a competent designer and developer of complicated graphics algorithms and knows to handle difficult tasks such as converting different types of files. Another good reason are the differences in life style. Both developers live in differently timed worlds. While developer A is a polychronic person who enjoys performing several tasks in parallel and finds it difficult to set time apart for nonwork activities, developer B effectively plans and reduces his working time to regular periods of intense and directed activity. Finally, the two have completely different coding styles and their priorities for developing applications are not easily compatible. While developer B practices a highly structured approach to programming, sometimes using paper and flow or structure charts for designing a complicated function, developer A prefers writing very long source files with global variables and nonstructured procedures: "I simply do not touch global data. For instance, I could not read his programs and he not mine, since I put the opening brackets into the same column as the closing one, and he puts them at the beginning of the row (not into the same column). I am used to building the code structure with tabulators, and he with spaces. … My modules are hierarchical, at the bottom the in/out functions, on top of them those functions which call the others, a nice pyramid" (Developer B).
The two developers’ approach to software design-development is one of subdividing a task into functions that are developed separately and integrated at the very last minute. This is only possible because both of them are willing to step over the boundaries of their own worlds at some point and to engage in intense cooperation.
Places and transitions between them play an important role in hearing and aligning different voices: the home (for programming), the office (for linking and testing), the coffeehouse (for meetings), the studio (for last-minute adjustments and for performing). As both developers work most of the time in separate places, they use email and the telephone often and only meet to discuss urgent problems and the next steps in design and development. They typically meet at a coffeehouse, which is an environment that is semipublic, intimate and neutral at the same time, and therefore seems particularly suited for spontaneous boundary crossings and difficult encounters that need a neutral and relaxed atmosphere in order to occur. Another setting is the stage of the studio in front of the running cameras where the customer (a prominent TV journalist who himself has a strong notion of the functionalities of the product and details of the graphical interface) performs using the technology designed for him—the two developers act as his background support.
The File Cabinet
This is the case of a small software house (with 10 developers and one project manager) that specializes in applications for insurance and does 80% of its business with one single customer, a large insurance company. At the time of the case study,2 developers’ main task was to port existing DOS applications (40 programs that run on 5,000 installations) into a MS Windows environment.
Recommendations and suggestions from multiple voices were not asked for. On the contrary, the major concern of the customer (represented by the Technical Coordinator, a member of the company’s IT department) was how to ensure predictable performance. This was done through building a file cabinet of forms, checklists, and manuals. This cabinet contains written guidelines for the development process, programming guidelines, depending on the programming language (MS C, MS Visual Basic or MS Visual C) and the platform (MS DOS, MS Windows), and a quality assurance manual. A series of checklists ensures detailed documentation of all work performed. A software implementation form, a kind of paper-based workflow system, not only provides a detailed list of work to be done but also prescribes a rigid sequence of events. Its function is to document design and development activities, including the time estimated and the time needed for the completion of each task. There are a software test checklist, a customer request checklist, and a software release checklist highlighting the changes and new features added. A variety of tools support the coding and the testing of the programs. A code checker checks the programs syntactically and a bound checker assesses the allocated memories. Test data can be automatically created and reported by using a test tool that analyzes as well simulates the tests. Each developer uses a work plan that the developer continuously updates. In addition, the Project Manager keeps track of all development activities by using an Excel spreadsheet.
Connections to the customer are also spatial, with one of the developers located in the customer’s IT department, giving technical support and running software tests ‘in situ’. The company-based technical supporters act as the voice of the end users, formulating new requirements or reporting errors. The Technical Coordinator collects these in a database, to which the software company has only read access through a modem connection. The Technical Coordinator regularly creates printouts of these reports that he puts into a drawer of his desk where the Project Manager knows to find them. This drawer is also used for exchanging data (such as documents, test data, time schedules, new programs, and so forth) in disk form. Accessibility of a private place such as the drawer expresses shared power relations while also signaling trust.
Defending Local Autonomy Against a Centrally Controlled Communal Space
The Landscape Architecture Case refers to a small local office that is part of a large international company. Their work involves the planning and detailed design of outdoor spaces. The example we refer to is the introduction of Lotus Notes. The idea was to create a shared electronic object world that will be administered at the central headquarters. There are different types of documents in this space: customer profiles, personnel information, detailed contact reports, so-called action items (description of activities carried out by an office), and proposal details.
The design of this space was monitored by the company’s quality assurance and marketing departments. On the local branch level the notion of a centrally controlled communal space was perceived as threatening local practices and knowledge, and this in a situation of tight internal competition where each office must fight for survival. Headquarters on the other hand argued with quality standards (in particular their obligation to satisfy ISO 9001 requirements), and hence the need for making information transparent and for sharing it.
The local office did not have the expertise necessary for creating conviction for their perspective. Although participation had not been designed into the project, it evolved quite unexpectedly in the case of a visiting researcher who was able to set up Lotus Notes on one of their computers and give them some training in how to use it, but also helped them to create a set of forms for reporting used for arguing their point of view when meeting with people in the central office. These forms were purposefully designed as boundary objects. The idea was to demonstrate local ways of doing things and to inscribe them in the system in ways that would be useful for others as well. In order to serve as a boundary object a form should be both flexible and malleable for actors to fill in local meaning and vision of use, and sufficiently defined and durable to allow shared (conventional or routine) use [9].
A particularly worrisome feature of the artifact-in-development was the data replication mechanism. While the central office’s vision focused on data consistency throughout the whole company with its 2500 employees, the local office was more concerned with preserving its own knowledge base. Since data replication was done centrally, people on the local level could never be sure about the status of their own data if, for example, someone else had changed or removed some locally relevant information.
Eliciting Multiple Voices
The Danish Radio (DR) Case started with the intent of testing the MUST approach (a participatory design approach developed by the Design Group at Roskilde University (RUC)) and of establishing it within DR’s IT Department. A project group was established, consisting of the research team, members of IT, two journalists (as user representatives), and some administrative staff (whose job it is to give secretarial support to radio production). All of them engaged in some field work (doing interviews, participant observations) aimed at understanding how radio production works, as well as in joint meetings.
The place in which software development takes place is a host of local and distant resources, and it has to be constructed in order to accommodate these in a meaningful and productive way.
During these meetings an object world was built that was designed from the start as a boundary space, a space representing and supporting an evolving common vision. This space was populated by documents such as interview transcripts, loud thinking protocols, the posters produced during design sessions, and so forth. At some point, the IT people introduced data modeling (a quite common technique within software engineering but rarely used within a PD framework) as a tool for making the information flow during radio production (in particular temporal dependencies) transparent.
There was the double notion of producing these kinds of artifacts and making their construction transparent to the IT people so they could adopt the approach in their own work. On principle, end users should also be engaged in this process, but this idea was abandoned at a point were the pressure to produce a product took over. Different visions of the product to be developed existed, and their relevancy changed in the course of the project. While RUC was primarily interested in the result of testing MUST in a real setting (DR’s IT department), management and the journalists themselves looked for an executable system. While RUC’s image of prototype was something rather provisional and incomplete that should enable practical experiences with some central features of a supporting system, the radio people expected a program that would work in a real environment.
Discussion
The cases show different ways of handling multiple voices within a project:
- The developers’ task in the Document Case was to produce highly complex standard software. Their strategy for taming the artifact was to build a highly homogenized and transparent object world and to instill best practices. They based their work on a strong vision—a notion of research-based professionalism, fired by a pioneering spirit. An enclosed and protected environment was created that nourished an atmosphere of learning and mutual support.
- The separation of worlds practiced in the TV Case is based on a respect for difference. The small size and boundedness of the project, together with developers’ knowledge of each other, made it possible to let two equal voices (representing different knowledges, coding practices and life styles) speak. Heterogeneity was handled by limiting ambitions to creating an executable program, the inside of which was of little interest as long as the two developers knew how to handle errors within their own modules.
- The file cabinet in the Insurance Case has been constructed to ensure both compliance with the customer’s view of the artifacts-to-be-designed and the reliability of performance. A workflow like organization fills in for a common vision. The design space in this case is imposed and meant to bound risk rather than to inspire outstanding contributions.
- How different voices and commitments are handled within a project obviously also depends on power relations, on how these are perceived and enacted. This is also present in the Landscape Architecture Case in which introducing Lotus Notes was primarily driven by the interest to gain control over regionally distributed far-flung operations. This was done by enforcing standardized and easily overviewed practices of reporting. Headquarters did not equip the local branches with the expertise necessary to give their view a voice in the design process. However, this also mobilized the local branch to fight for regions and procedures of their own.
- In the Danish Radio Case there was a clear mission of the research team to establish and test participatory practices of systems design within the organization. Part of this was to hear multiple voices so as to gain a fuller understanding of the work to be supported. Multiple methods (from ethnographic studies of work to data modeling) were combined. At the same time, the heterogeneity of commitments and views made it difficult to shape the product.
The small size and boundedness of the project, together with developers’ knowledge of each other, made it possible to let two equal voices speak.
Building software is about making linkages between a multiplicity of object worlds, practices, and commitments. One way of bringing these together is through imagery, metaphors, and descriptions that can translate between different views of the artifact-in-development; another way is through shared tools and procedures. As we want to show with our short case descriptions, actual practice depends on context (of people, knowledge, and the nature of a task) and is cultured (in the sense of being shaped by beliefs, commitments, styles, and power relations). The place in which software development takes place is a host of local and distant resources, and it has to be constructed in order to accommodate these in a meaningful and productive way.
Another aspect of this is very well captured by Latour’s observations on the power of inscriptions as mobilization devices that make it possible to assemble a whole range of resources (from around the world, from different disciplines), for simultaneously constructing an artifact (such as a piece of software) and for staging its performance and understanding by others. "Boyle, for instance, in the fascinating account of his vacuum pump experiment described by Shapin, had to invent not only the phenomenon, but the instrument to make it visible, the set-up in which the instrument was displayed, the written and printed accounts through which the silent reader could read about the experiment, the type of witnesses admitted onto the stage, and even the types of commentaries the potential witnesses were allowed to utter. ‘Seeing the vacuum’ was possible only once all these witnesses had been disciplined" [8]. The point we want to stress here is that apart from looking at what is at hand in designer-developers’ object space we also have to understand how this space is set up and disciplined for different kinds of performances. While in the early design phase of a product there is a stronger need to mobilize heterogeneous resources [7] in order to capture all the potentially relevant views and knowledge, when the design space is gradually narrowing down, issues of coherence, stability, and transparency of a solution come to the foreground. Then coding conventions, reporting and documentation procedures—including consistent descriptions of how different parts of the software (or modules) fit together—transparent practices of handling bug reports, change requests and design changes, or version control become practical necessities.
A principal aspect of the approach we adopted for understanding software development in context is to perceive that "technologies are shaped and acquire their meanings in the heterogeneity of social interactions" [1]. This view is consistent with some parallel explorations that are taking place, for example by Ciborra [4] who makes a case for improvisation as a means of taking account of the multiple object worlds typically to be found in organizations, or by Clement and Halonen [5] who show how in the making of a dispatch system a multiplicity of visions and commitments was maintained.
These studies (among others) support our notion that heterogeneity is inherently important in understanding software development. They also point to the difficulties of finding adequate trade-offs between tapping all the resources potentially available and disciplining them into a coherent product.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment