|The User-Developer Convergence: Innovation and Software Systems Development in the Apache Project|
|Prev||Chapter 2. Software systems development||Next|
Robey and Markus (1984) shows that developing software systems is not necessarily a rational process intended to achieve identifiable and agreed upon goals like an objectivist would argue, but rather "a process that can be interpreted as rituals which enable actors to remain overtly rational while negotiating to achieve private interests" [ROBEY1984](Robey and Markus 1984, p. 5). In the article System's Development in Scandinavia: Three Theoretical Schools [BANSLER1989] Jørgen Bansler (1989) shows that software systems development need not be viewed as an engineering discipline. It is instead viewed as a component in larger socio-economic contexts.
"Participatory design is about involving users in the creation of computer system" [MILLER1992](Miller 1992, p. 93). There are usually three arguments why participatory design will improve software systems The first two are practical. Participator design improves the knowledge upon which the system is built, and it enables people to develop realistic expectations while reducing the resistance to change [BJERKNES1995](Bjerknes 1995). Miller claims user participation makes "sure that the end product actually serves their [the users'] needs" [MILLER1992](Miller 1992, p. 93). The third argument is culturally and politically biased. A goal in Scandinavian research projects in software system development has been to increase working life democracy. Participator design has been explored to achieve this goal. Participatory design is traditionally justified by three arguments. It is believed participator design will increase working place democracy by giving the members of an organization the right to participate in decisions that are likely to affect their work.
Participatory design isn't a unified approach to software systems development, but rather a family of approaches subscribing to same goals and ideals of user participation. There are different ways this is achieved.
Miller argues "participatory design starts from the insight that the people on the front-line … are not only in an excellent position to know what works and what doesn't work in the current set up, but also what might be done to improve the situation" [MILLER1992](Miller 1992, p. 95). The theoretical foundations behind this kind of participator design is the so-called socio-technical systems theory. Central to the socio-technical approach is the notion of job satisfaction [BANSLER1989](Bansler 1989). While job satisfaction is an end in its own right, it is also a means for achieving higher productivity within organizations. Instead of a mechanistic approach to software systems development, the socio-technical approach proposes that organizations will be more effective if they are deliberately designed to ensure a high degree of job satisfaction. The argument is that a high degree of job satisfaction leads to increased responsibility, which in turn leads to better productivity. The means to achieve the goal of job satisfaction is participation.
Socio-technical theory treats organizations as two systems, a technical and a social. Disharmony between these systems leads to a suboptimal organization. Each of these systems have their own inner logic, and they operate along different axis. To optimize the social system employees responsibility and commitment is encouraged. Working conditions must meet the psychological and social needs of the employees. The employees must feel they have a meaningful job with variation and autonomy.
In the late 1960s Sweden saw rapid technological and structural change, something both employers and workers considered a problem. Unions were concerned about working conditions, employers about the personnel problems they were experiencing. The Norwegian socio-technical experiments seemed promising. So while several of the Swedish experiments produced interesting ideas on work organization and democratic participation, practical implementation proved more difficult. The employers were satisfied with the socio-technical approach, but not the joint experiments. The employees argued that the conflicting interest between employer and employees became even more manifest when implementing the new methods of working [EHN1992](Ehn 1992).
A new group of researchers argued the socio-technical approach didn't acknowledge the conflict between labor and management. Instead it provided a harmonious view of the organization, arguing for balance between the social and technical systems. This new direction of research, often called the critical tradition, argued that organization were not "cybernetic systems or symbiotic socio-technical systems, but rather frameworks for conflicts among various interest groups with unequal power and resources" [BANSLER1989](Bansler 1989, p. 15). The critical tradition doesn't reject all aspects of the socio-technical approach. It simply argues that the problems with practical implementation of socio-technical systems reflects the questionable assumption of organizational harmony, rather than short-comings in the socio-technical techniques [EHN1992](Ehn 1992).
The roots of the critical tradition's work-oriented design can be found in the Scandinavian discussion about the relationship between democracy and work in the 1960s. It was believed that increased working place democracy would increase efficiency and productivity. A large cooperation program was designed and conducted between the Norwegian Federation of Trade Unions and the Norwegian Employers' Federation, to improve working place democracy. The employers were concerned with rationalization and improved organizational development, while the trade unions wanted to empower the workers. In this climate of cooperation some explicitly stated political projects were carried to strengthen the trade unions, as it was believed stronger unions would contribute to working place democracy. At their annual meeting in 1970, the Norwegian Iron and Metal Workers' Union initiated a project whose objective was to apply workers' perspectives on development and introduction of new technology. Its stated goal was to strengthen the workers' influence with respect to introduction and use of new computer technology. The result of the project included technology agreements, textbooks and vocational training programs on technology [BJERKNES1995](Bjerknes 1995).
However, Pelle Ehn transcends the political importance of participatory design, arguing for the importance of participation in design by both users and developers. While working on a trade union based project, Ehn discovered some approaches were more successful when working with users. "Requirement specifications and system descriptions based on information from interviews were not very successful" [EHN1992] (Ehn 1992, p. 62). As it turned out the use of mockups, prototypes, simulations and experimental situations yielded significantly better results. Ehn aknowledges not only the political importance of participatory design, but also the importance of building a shared understanding of the problem domain between software developers and the users. In that Ehn acknowledges that there is more to software systems development than building the right system or building the system right, there is an social element of joint discovery and learning involved as well.
Floyd claims the product-oriented view sees the process model as a way to make software systems development less dependent on people [FLOYD1987](Floyd 1987). A basic assumption behind participatory design and socio-technical software systems development, is that introducting technology will contribute to rationalizing work and de-skilling workers [BJERKNES1995](Bjerknes 1995). This view is based on the notion of a contradiction between capital and labor, a view with basis in Marxist philosophy. The introduction of technology to rationalize the work process, is the central theme of scientific management. Julian Orr writes:
The basic premise of scientific management is that one can reduce the best way to do a given job to a set of instructions and give those instructions to someone who does not know how to do it independently but who will then be able to do the job by following instructions. In this way, management gets control over their employees, through control of the knowledge necessary to do the job, and can hire cheaper employees since they do not need skilled labor. [ORR1996](Orr 1996, p. 107)
This introduces a new dimension in how software system development is viewed, a dimension of harmony or conflict. Participatory design is explicit on the conflict between those funding the software system, management, and its users, the workers. One of the criteria Hirschheim and Klein uses in classifying approaches to software systems development, is this order-conflict dimension [HIRSCHHEIM1989](Hirschheim and Klein 1989). The order view emphasizes a world of order, stability, integration, consensus, and functional coordination. It is a view where everyone within an organization have the same goals, be they upper management or grass root worker. On the other hand is the conflict view that stresses change, conflict, disintegration, and coercion. At its core, their critique of the order view is based on the assumption that there are conflicting interests within an organization, small or large, and that these conflicts have to be acknowledge to understand the organizational problems facing systems development.
That neither of the software engineering process models presented earlier includes any views on the resolving any conflicting interests between users and management is no coincidence. Software engineering doesn't see this as within the scope the software development effort. The unified process explicitly exonerates itself from any conflicting interests, typified by statements such as this: "We think of the architecture of a system as the common vision that all the workers (i.e., developers and other stakeholders) must agree on or at least accept" [BOOCH1999](Booch et al. 1999, p. 59). Socio-technical critique of software engineering says software engineering optimizes the technical system at the expense of the social system [BANSLER1989] (Bansler 1989). Rather than accepting a conflict between capital and labor, software engineering itself subscribes to the views attributed management. Software engineering views methods as a way to make development less dependent on people [FLOYD1987](Floyd 1987). In this respect, the methodologists plays on managements side, while software developers subjected to engineering environments can be de-skilled and cheaper, less trained and experienced workers may be hired. Looking at software engineering from a conflict-harmony point of view, it is a tool in the hands of management.
The differing view on the conflict-harmony dimension probably stems from a more fundamental difference in world view. Where software engineering is objectivist view of software systems development, the alternative approaches have a subjectivist world view. "In contrast [to the objectivist position], the subjectivists position denies the appropriateness of natural science methods for studying the social world and seeks to understand the basis of human life by delving into the depths of subjective experience of individuals" [HIRSCHHEIM1989](Hirschheim and Klein 1989, p. 1201).
In participatory design both software systems developers and users play other roles than in software engineering. In software engineering the systems developer's primary role is to be an expert in technology, tools and methods of systems analysis and design, and project management. He is there to make systems development more formal and rational [HIRSCHHEIM1989](Hirschheim and Klein 1989). What little role the user plays in software engineering, it is largely instrumental to aid the developer in understanding the referential system. Work-Driven Design sees the developer as a "labour partisan" [HIRSCHHEIM1989](Hirschheim and Klein 1989, p. 1206). He sides with the workers in achieving increased working place democracy and a higher degree of influence on the organization. Socio-technical development sees the developer as an emancipator or social therapist, where his role is to attain balance between the social and technological systems. Both directions of participatory design sees the user playing a central role in shaping and directing the development effort.