CEPA eprint 3126

Software development process: some reflections on its cultural, political and ethical aspects from a constructivist epistemology point of view

Floyd C. (1999) Software development process: some reflections on its cultural, political and ethical aspects from a constructivist epistemology point of view. Cybernetics & Human Knowing 6(2): 5–18. Available at http://cepa.info/3126
Table of Contents
1. Introduction
2. Software Development as Design
2.1 Design as an insight building process
2.2 Design as a web of distinctions and decisions
2.3 Perspectivity in software design
3. Operational Form and Situated Action
3.1 Operational form
3.2 Rules vs. self-organization
3.3 Computer support for autonomous work
4. Methods Supporting Design
4.1 Formal methods as resources
4.2 Evolutionary systems development
4.3 Facilitating cooperative design
5. The Ethics of System Design
5.1 Dialogical Design
5.2 Subject-orientation
5.3 Responsibility and auto-operational form
6. Conclusion
Design in software development is viewed, from a constructivist epistemological perspective, as an insight building process linking the worlds of application, of methods, and technology. Design unfolds as a web of distinctions and decisions constructing at the same time the problem and a fitting solution. Design is evaluated based on the coherence of the decisions taken and their viability. Closure and self-organization arise from the feedback of evaluation on design, leading to revisions and further distinctions and decisions. Software design is specific in that it starts from operational form in different areas of human practice and provides auto-operational form to be re-embedded in human practice. Dialogical design seeks deeper insights by taking account of and crossing different perspectives. The consequences of this view on software development methods are briefly discussed.
1. Introduction
In this paper, constructivist epistemology is applied to the development and use of software. We are primarily concerned with the cooperative development of software to be used in (individual or cooperative) work processes. Here, software developers provide tools for the work of users and media for the communication between users. Moreover, software is used for coordinating work and thus embodies concepts for organizational control. Thus, on one hand, design relies on cooperation and negotiation amongst different parties: developers, users, management and so on, and the technical concerns for constructing high quality products are inherently tied up with communication and work – social processes which define the very nature of the problems to be dealt with. On the other hand, the systems in use shape the conditions for organizational development.
As a basis for advising projects in this area, I have found it helpful to adopt theories of self-organization drawing, in particular, on the ideas of Heinz von Foerster with whom I have been in close contact for several years (cf. Foerster 1984, Foerster, Floyd 1992 and Floyd 1996). This means viewing software development as design and understanding design in terms of choices – distinctions and decisions, their evaluation and revision – leading to further distinctions and decisions and thus to operational closure. In keeping with this basic orientation, I use ideas of self-organization primarily at an epistemological level in order to portray the process of building insights in design.
In contrast to conventional software engineering, this involves a profound re-orientation. For example, a software developer analysing an organization with a view to proposing a software system to support its information processes, is often encouraged to start from the ‘real world’, conceived in terms of the entities and actions constitutive of the information flow in the existing organization. These are supposed to be ‘given’, while the software developer’s task is to analyse, to abstract, and to elaborate, a correct model that can be manipulated by the computer. While this may be difficult to do, the task itself – discovering the correct description – is supposed to be clearly defined and independent of the software developer as an observer. Also, his or her responsibility in carrying out this task is restricted to matching the real world in the model with the greatest possible care.
The pseudo-objectivist view sketched above (see, for example, McDermid 1990) has been criticized by several authors, notably by Naur (1992), who points out that software development consists in theory building on the part of the individuals involved, and by Nygaard (1986), who brings out the social fabric of perspectivity and conflicts arising in systems development. Following Nygaard, many Scandinavians have emphasized the political nature of systems development: What is being modeled and how, how the resulting system relates to human work, and so on, must be negotiated between interest groups (cf. for example, Dahlbom, Mathiassen 1993 and Klein, Lyytinen 1992).
The picture changes even more drastically, when we acknowledge our active role in bringing about what we hold for real, which is the key to constructivist thinking. The emphasis now is on the observer constituting the way he or she sees reality and inventing a suitable description. Thus, the software developer is portrayed as making choices in an open situation, where there is more than one possibility. When developing the product software, we make choices in selecting the aspects we consider relevant for modeling, in making available modes of interaction with the computer, in determining the software system’s architecture, in the way we use the technical resources for implementing the system. Moreover, we make choices in anticipating how the computer will be embedded in its use context and in creating facilities and constraints for users and other concerned parties. And finally, we make choices in how we conduct the development process itself, in particular, we choose and adapt the methods and tools to support this process.
We only make a small part of these choices explicitly, more often they are implied by the course of action we take and, perhaps, even come about by our lack of awareness for potential alternatives or our unwillingness for coping with them and making conscious choices. Also, our choices are constrained by our interaction with others. When seen in these terms, the task of the software developer clearly involves reference to the individual software developer. By our choices, we constitute design. The results of design are reified choices, which, when becoming effective, interfere with choice scopes of human beings. Paying atten-tion to choices comes with acknowledging the responsibility for seeing possibilities and making choices. Thus, the ethical dimension of design becomes manifest.
Whilst the views presented in this paper draw on concrete experience in software projects and method development, the discussion is on a conceptual level. I shall make extensive use of the book Software Development and Reality Construction (Floyd et al. 1992) which attempts to lay epistemological foundations for design. The perspective adopted here is closely related to the so-called soft-systems tradition (e.g. Checkland 1981), which provides a methodological framework for design taking account of the organizational context and has also been applied to studying and evaluating software development methods (e.g. Jayaratna 1994). There is, however, a difference in emphasis and in scope. The aim here is not to provide a methodology, or even a framework for evaluating methods, but to contribute to an epistemology of design, applying constructivist epistemology to all levels of concern for understanding the interplay of software and human action. Therefore, the paper brings out and interrelates different issues of concern.
Section 2 deals with software development as an insight building process. Design unfolds as a self-organizing process relying on distinctions and decisions, with evaluation leading to closure. The design space is constituted by the interplay of two choice scopes: choices we make in design about choices available when the system is used.
In section 3, the idea of operational form is introduced for describing networks of connected operations. Operational form emerges from routine human action and is re-embedded in situated human action. Operational form can be used as a rule for prescribing or as a resource for supporting situated action. Applied in our field, automated operational form (auto-operational form) is the key concept for clarifying the interrelation of software systems and human actions.
Section 4 views methods as operational form in design. In keeping with a constructivist account of the role of methods, the emphasis shifts from viewing methods as prescribing rules to regarding them as resources in the situated, self-organizing design process.
Section 5 shows the ethics inherent in design. Von Foerster’s imperative, inviting us always to act so as to increase the number of choices, is proposed as an orientation for design. If, then, design consists in managing choice scopes, the dialogical potential of design in cooperating with users consists of creating use scenarios that will promote autonomy and flexible interpretation of technology.
In the closing section 6, the ideas presented here are tailored concretely to computer supported work and discussed in the social setting of power relations in organizations.
2. Software Development as Design
2.1 Design as an insight building process
In computing, we tend to start from problems. In the light of constructivist thinking, problems are not given, they are descriptions, invented by observers. Thus, we construct the problem as well as the solution. The key notion for me is design treated in depth in Floyd (1992b). As used here, design refers to a specific type of cognitive process geared to producing feasible and desirable results within a particular domain. We normally only speak of design when there are concerns we wish to fulfil, limited resources at our disposal, and different implementation options open to us.
The distinct character of design in software development is due to the nature of the product software and its embedding in human contexts of meaning. Software exhibits an extreme degree of complexity, thus calling for equally complex construction processes. It consists of a uniform, abstract building material, is therefore plastic and, in principle, completely revisable. It must be suitable for machine-processing, i.e. complete, consistent and free from formal error. It is not amenable to sensory perception and can therefore, in the last analysis, only be evaluated once in use. Thus, in a broad sense, design encompasses the overall process of organizational and technical system development.
Design links different worlds:
world of the applications which gives rise to requirements for software,world of technical resources – computer technology including existing software,world of methods and concepts used in modeling and implementation.
These worlds become updated, (re-)constructed and linked at every point in time. Moreover, they unfold in the course of the design process itself, thus constituting the design space. This means:
do not analyse requirements for the application, we construct them.do not refer to fixed means of implementation, instead we construct the meaningful use of technical resources by testing, selecting or enhancing what is available.do not apply predefined methods, but construct them to suit the situation in hand.
There are no methods per se – only processes of method development and adaptation. There is no predefined path through these worlds. It would only be possible to follow such a path if all the relevant decisions had already been taken. But then there is no place for design.
2.2 Design as a web of distinctions and decisions
Design is rooted in concerns of the application world, which leads to setting of goals that are to be attained with the help of specific means, the point of departure being an already established web of decisions, linking the concerns considered relevant for attaining the goals set with provisionally designated means of implementation. But this is not a solid foundation for design. The means of implementation may prove inadequate. The set goals may turn out to be misleading or be considered no longer valid. Even the concerns may change. To this extent, design lays its own foundations and sets its own goals. Design presupposes a range of options and scope for exploring them. It requires autonomy if a genuine choice is to be made.
Design rests on making distinctions and consists of a web of design decisions relating to these distinctions which, taken together, make up a proposed solution. Not all necessary design decisions are taken consciously. Frequently, it is not until the proposed solution has been evaluated that it becomes clear which decisions will be needed and what consequences failure to take them will imply. This results in building up complex structures of interwoven decisions, which must be intrinsically coherent and, overall, viable. Their emergence is specific to the individual design process. Design is shaped by the perspectives of those sustaining it and by the constraints imposed upon them.
The viability of design is determined by a number of different factors: whether the decisions match the concerns; whether the web of decisions covers all elements of the problem that are considered essential; whether meaningful use can be made of the means available; whether the goals set are attained. These distinctions are made by an observer. Design is thus based on a wealth of connected distinctions concerning what is ‘good’ (desirable) as judged in the course of the process by those involved. The criteria for such distinctions are invented to suit the concerns relevant to design.
Design can only fully unfold where decisions that have already been taken can be revised on the basis of their evaluation; in other words, if the results of design become themselves the starting point for design. This is how closure in design comes about. Decision making, evaluation and closure are interleaved: individuals revise their solutions continually when developing and checking it; groups base their evaluation on design reviews and on testing; the adequacy for the context becomes apparent during use. Closure involves admitting errors and learning from them, offering and accepting constructive criticism, abandoning erroneous goals and recognizing changing concerns. Closure means the continuation of design.
Design is successful as a whole if the web of design decisions stabilizes in the course of revisions; in other words, if it withstands evaluation and is acknowledged as ‘good’ by those involved despite changing concerns.
2.3 Perspectivity in software design
Due to the complexity of the design space, design always relies on a variety of views, even when pursued by individuals working on their own (who adopt different views in time). In the literature pertaining to systems development, the term ‘perspective’ is used in two distinct ways which are both relevant here:
a) Perspectivity arises implicitly from our individual subjectivity as shaped by our culture, our beliefs and our life experience. We can never leave our perspectivity in this sense, we can, however, aim at elucidating it to some extent in communication with others. Clarifying and crossing the individual perspectives of those who participate in design is of paramount importance for arriving at a common understanding, an inter-subjectively shared platform for development work and for design decisions that reconcile between conflicts of interest.
b) Explicit Positions adopted consciously by individuals or groups and related to common tasks, formulated interests or specific paradigms are also called perspectives. Examples are all notions of perspectives given by Nygaard (1986) as well as the proliferation of ever new perspectives for human computer interaction. In connection with software design, it is important to distinguish the ‘use perspective’ held by those who interact with software as a tool or as a medium from the ‘development perspective’ held by software developers. Furthermore, there is no one single use perspective, but a plurality of perspectives related to different users.
Different perspectives on one and the same software system may be in conflict due to misunderstandings or clashes of interest. If we take working with users seriously, these conflicts must be acknowledged and dealt with rather than smoothed out in a quasi-objective system analysis. Thus dealing with multi-perspectivity becomes a basic prerequisite for cooperative work. In particular, software requirements are governed by perspective, they reflect differences in individual perspectives and are subject to temporal change (cf. Reisin 1992). Articulating and crossing perspectives permits an in-depth-view of the decisions to be taken. Thus, to promote quality, design requires multi-perspective reflection.
3. Operational Form and Situated Action
3.1 Operational form
Formalizing and automating human activity is inherent in computing. To characterize the specific way in which formalization occurs here, I shall use the term operational form. By this, I mean an abstract characterization of the informational basis and the functional content of defined human activity. Software development always involves bringing out and automating operational form in a particular domain of human practice. This presumes routine in human activity and a modeling process in which this routine is explicitly defined. It rests on characterizing the objects we work with by informational attributes and our dealing with them as manipulation of these attributes. Note that my terminology avoids reducing human activity to operational form. It merely aims at characterizing that aspect of human activity that is amenable to being formalized and automated.
A program executed on a computer can then be seen as auto-operational form – a term proposed originally by Reisin (1992b) – that is, operational form becoming effective on its own when executed on a computer. Of basic interest in software design is how operational form, and in particular, auto-operational form, relates to situated human activity. My aim in the following sections is to sketch different orientations for this and suggest a basis for their evaluation (see also Floyd 1995, 1997).
3.2 Rules vs. self-organization
Computing invariably has to do with identifying and standardizing discrete operational steps and grouping them into formalized procedures, which give rise to algorithmic structures to be executed on a computer.
This involves several instances:
instance to set up rules: a human, who makes or identifies rules (for example the software developer complying with the wishes of the customer, the method developer prescribing how to proceed in software development and so on),instance to impose rules, often a non-human agent (the computer controlling work processes or technical systems), andinstance to carry out rules, either human or technical.
It is difficult to write about these instances without equating people and computers, since I have to choose between ‘which’ and ‘who’. This seemingly linguistic triviality reflects the fact that the mutual ‘rights’ of these instances depend entirely on the view of their desirable interaction and thus on decisions taken in design.
Programs embody rules (for example algorithms) to be executed by the computer. But the idea is often also to implement rules in the organization through computer programs. Imposing automated formalized procedures via computers brings about a new quality. While in general, the rules imposed on human activity have to be sufficiently clear and unambiguous for humans to follow, here they must be formulated in machine-interpretable terms. While humans interpret rules as they apply to the needs of the specific situation, programs always operate according to their predefined model. And while humans tend to associate rules with exceptions, computers do not.
Design is connected with the identification and the connection between the individual operation steps to be automated, with the possibility for humans to interfere and with the organization of computer-supported work.
Since all operational form rests on reductive models of entities carrying informational attributes, one borderline to explore is the relation of formal models to reality. This involves various levels: How do we decide which aspects are relevant for being included into a model? How do our modeling concepts shape how we think about the world? What kind of being do we ascribe to modeled entities? What claims do we associate with models? How are different models connected? How do models become operational in use?
We can also distinguish different ways in which auto-operational form becomes effective in use. Is it supportive or controlling? Is it informative or instructive? Is it simulative or does it directly affect reality? I don’t know a good classification here, but we need to work in this direction, as we populate the world with auto-operational entities of various kinds.
Thus, when making auto-operational form available, the instance setting up the rules must have a mental picture of the class of possible situations and a sufficiently rich understanding to allow for any potentially relevant activity at any time. There are two basic options for embedding formalized procedures in the richness of human situations. One is to rely on a formal model of the class of possible use situations, and to automate a set of rules for how to proceed according to this model. The other is to leave the use context open and to offer a repertoire of resources to use in self-organizing work.
3.3 Computer support for autonomous work
The choice between these options arises at many levels in computing. Because of their basic importance for computers in connection with work design, many authors have addressed these questions. For example, I have implicitly referred to Suchman (1987): rather than as rule systems to be followed, she suggests that plans (an instance of operational form) should be seen as resources to be relied on. Formalized procedures should not be imposed, but be available for flexible use in cooperative work.
To start with, modeling should occur with a view to human use, which means to perceive the entities to be modeled in the context of the work to be performed by them. If models, like plans, are to be used as resources in situated activity, this requires an understanding of their relation to context. Therefore, Reisin (1992a) understands a reference theory in software development as centering around the use-meaning of software. The use-meaning must be anticipated in cooperative design processes involving developers and users. Similarly, Budde and Züllighoven (1992) regard programs as things to use and formulate their object-oriented concepts in terms of how things are used in work processes. Use-oriented modeling rests on understanding the human activity to be supported.
Closely connected are the perspectives and metaphors used in design, ranging from machine, to tool, media and so on. An excellent overview has been given by Maaß and Oberquelle (1992). They show how different perspectives embody views on how humans should interact with computers.
An example is the tools and materials metaphor elaborated by Budde and Züllighoven (1992) and enhanced by Gryczan (1996) which comes with distinct concepts for tool support. Here, software-workers use tools which are designed to serve for a specific task, without making assumptions about the context in which the tool is used. This means especially that no order on the usage of tools is tool. Furthermore they have to be in control of the results – especially computerized – tools produce. These results can be used for other work tasks, whether these are computerized or not. That means, tools do not take actions by themselves, but are driven by human action.
Related is the design guideline: avoid all unnecessary sequencing of predefined work steps proposed by Keil-Slawik (1992), here also we have the shift from embodying formalized procedures in computer programs to providing a repertoire of possible actions with computer support.
4. Methods Supporting Design
4.1 Formal methods as resources
Likewise, methods can be seen as a particular instance of operational form. They are often perceived as rules to follow. The interplay between methods and the situated process is subject to controversial discussions. One extreme is the strict advocation of formal methods, for example in the Dijkstra school of thought. The other extreme is the radical statement: ‘There is no right method for theory building’, made by Naur (1992). Both refer to an understanding of ‘method’ as giving rules for how to proceed. In discussing methods we need to differentiate between the formal modeling concepts they offer and the formalized procedures they recommend. Naurs’ argument pertains to formalized procedures, not to modeling concepts.
A major reason for advocating formal modeling concepts in programming is the occurance of errors. But what are errors? In formal approaches, errors are defined as deviations between the program and its specification. The connection between errors and formalization is a subtle one. On the one hand, formal approaches offer conceptual means that enable suitable ways of abstraction and avoid certain categories of errors altogether. Thus, they greatly improve the logical consistency of programs. On the other hand, they introduce new sources of blunders. And they give no hint as to whether or not suitable decisions are made with respect to the context. Whether we tackle the right problem, so to speak.
According to constructivist thinking, errors refer to mismatches between actual and desirable decisions taken during programming. There is not always a fixed frame of reference available for judging what is right and wrong. Thus, errors are learning events in design. Going beyond formalization, we need to develop constructive ways of dealing with errors.
Design succeeds, if it leads to a coherent understanding of the product and its potential use as perceived by the participants. Adopting a constructivist approach, this can be characterized as emerging order. Thus, instead of requiring us to follow a formalized procedure, methods and tools should be designed so as to promote the emergence of own-order and allow for autonomous use. Rather than prescribing which work steps need to be taken in what sequence, the idea is to provide a repertoire of concepts for modeling. As resources, methods must be tailorable so as to support individual steps arising in the situation in a flexible manner and to help maintain the consistency of what has already been achieved.
4.2 Evolutionary systems development
Taking design seriously has an enormous impact on the practice of software development: Rather than trying to emulate linear top-down development, it will lead to cycles of design decisions, their evaluation and revision, as for example in connection with prototyping. Rather than fixing one view early on, it will suggest bringing out and coordinating the variety of views. Rather than dividing the work right away, it will emphasize the importance of a shared understanding to be developed and upheld by the participants. Rather than aiming for software development to be independent of the people involved, it points to focussing on the situated process and on making this more transparent. This is the idea behind evolutionary systems development – a rather paradoxical term, since it refers to a conscious, methodical orientation in design.
An approach in this direction is STEPS (Software Technology for Evolutionary Participatory Systems Design), elaborated by the author and several co-authors (Floyd et al. 1989) and used as a resource in several projects (see, for example, Floyd et al. 1997). STEPS is a framework for software development taking account of its connections to work design. It considers software development a learning process for both developers and users. It promotes cooperation in design and aims at enhancing user competence.
STEPS rests on a version-based cyclical project model reflecting the cooperative work between developers and users and on notions for the dynamic coordination of cooperative work. It focuses on software requirements as unfolding in the context of organizational tasks and human activities, on modeling as a means of creating an explicitly agreed basis for anticipating the use of the product, and on human computer interaction as the technical starting point for computer supported work design. Mutual learning in design, as well as the extensive use of prototyping, facilitates the embedding of software systems in meaningful work processes in the user organization.
As a consequence, the emphasis here is on perspective-based evaluation as the supreme guide both in building models and in interpreting constructed models (prototypes) in the context of meaningful human activities (see Budde et al. 1992).
Development, then, consists of intertwining some activities to be carried out jointly by developers and users and with others to be carried out by the respective groups on their own. Conventional software development methods for requirements analysis and design have their place, but need to be tailored to the needs of the communicative processes at hand, so as to show multi-perspectivity and to allow incremental work.
4.3 Facilitating cooperative design
The measures outlined here are basically geared to facilitating the unfolding of a ‘Project Mind’ and the emergence of a shared perspective. As argued in section 2.2, design teams should not proceed from any implicit assumptions; they need to lay their own foundations for cooperative work. This involves cooperation in establishing the project, in assigning tasks and responsibilities, in synchronizing and coordinating work, and in laying down conventions and standards for work within the team. But it also means jointly working out an authoritative project view of the basic documents and of the concerns, priorities and evaluation criteria valid in each case.
Cooperative design calls for
communication between all the parties involved; information must be continuously collected and disseminated, new viewpoints must be incorporated, and evaluations must be made from ever new perspectives;conscious development of a project language, linking the relevant domains of reality in a way that everyone is able to follow; and allowing goals to be set and revised;accessible and jointly maintained ‘external memories’ (Keil-Slawik 1992) such as project files and diaries, recording the currently valid foundations of work and jointly taken decisions, so as to enable the decision process to be reconstructed in the case of revisions.
The conclusion to be drawn for group work involves reconsidering project organization. Management takes on a new form: rather than imposing rules, the idea is to facilitate a process of self-organization. Group leaders are mainly responsible for the rules of the game and for setting up a climate, allowing the others to become creative and to interact. They are also in charge of setting the conditions for reflecting the process. And they need to make sure that the distribution of work tasks is based on a jointly upheld overall view, and results obtained individually are jointly validated.
Taking the communication process seriously leads to adopting moderation techniques to promote discourse. Thus, Pasch (1994) gives detailed recommendations on how to facilitate group work. Also Dahlbom and Mathiassen (1993) have coined the role of a facilitator as one that software developers are called upon to adopt.
The basic prerequisite for cooperative design is trust. And it can only develop where the interests of those involved are considered. Moreover, it presupposes a willingness on the part of all parties, especially the project manager, to create and maintain a socially supportive environment.
5. The Ethics of System Design
5.1 Dialogical Design
Ethics is always implied in human action, and in particular, in the conduction of work. The view of design proposed here does not rely on fixed norms but on the process of discourse amongst the participants.
Dialogical orientation in design is one way of characterizing cooperation both among developers and with users. The ‘I and Thou’ of software development is concealed in basic relationships such as ‘I develop software with you’ and ‘I develop software for you’. Teamwork in software development can be viewed as a network of this type of basic relations. The specific network of relationships between the people involved, unfolding in time, is constitutive in design.
Dialogical design involves working out a desirable tentative solution between myself and others, taking design decisions on a joint basis with consideration being given to the perspectives of all parties. This means that, instead of developing my model in accordance with my evaluation criteria – objectifying and enforcing these where possible – I should endeavor to be receptive to the perspectives of others. Instead of upholding my own model monopoly (Bråten 73), to which others must conform, it is up to me to take up all the other perspectives and allow them to interact.
In actual practice this shared responsibility leads to a field of tension where different interests need to be reconciled as we go along (Bjerknes 1992). In a dialogical design process, we must assume that each contribution is of a provisional nature; that cooperating designers entertain different expectations with regard to the process as a whole, setting different priorities and applying different evaluation criteria.
In dialogical design, we must also acknowledge conflicts and jointly overcome them, striving to weave together these perspectives in such a way that the web of decisions emerging during the design process is borne jointly.
5.2 Subject-orientation
In connection with computing, work design reflects specifically the view of human beings in relation to computers embodied in system design. There have been several attempts to furnish an orientation for how computer-supported work should be designed.
One criterion is subject-orientation in information systems proposed by Nurminen (1992). Subject-orientation refers to human beings as subjects of their work processes, being a subject is associated here with competence and responsibility. In many organizations, the use of information systems results in computerized tasks as inseparable parts of daily work. But a conscious orientation is needed in order to enable human beings to feel and act as subjects of their work processes.
The choices that help to achieve this kind of use-situation are made in the development processes. Here, subject orientation means that all participants in a project are viewed as skilled workers, who alone have the specific knowledge to fulfill their jobs. It is the responsibility of system developers to take this fact into account. Subject-orientation thus leads to a holistic view, where usage of computerized tools does not eliminate workers freedom of choice in selecting and sequencing work tasks.
Subject-orientation is also the gist of the contrasting analysis of the human-machine relation proposed by Volpert (1992), who gives several criteria to be taken up and discussed concretely in design. The idea is to provide a language for discourse allowing design decisions affecting human beings to be discussed and evaluated.
5.3 Responsibility and auto-operational form
Computer programs embody operational form in their application field. We invent operational form in the course of software design. But, in doing so, we also invent choice scopes for the users interacting with the working software. Of particular interest are automated choices encapsulated in operational form. In automating a choice, the designer anticipates the class of possible uses. In design we also create action spheres for a quasi-autonomous technical device. How do we allow it to interfere with human affairs?
When executed, programs become effective as auto-operational form, enabling or preventing users from making choices. In an age where we increasingly populate our world with computer based systems, it becomes of paramount importance to understand the entwinement between operational form and the living process shaped by it. In order to enhance our possibilities for human choice we need to assess how making available auto-operational form interferes with choice scopes in different areas of human practice.
The ethical imperative ‘Always act so as to increase the number of choices!’ (Foerster 1984, 1992) can be used as an orientation in design. Increasing the number of choices is a powerful guiding image, but at the same time, it lends itself to criticism. Whose choices are we supposed to increase? Are all choices equally worthy of being allowed for? Should we not sometimes decrease the number of choices?
Whilst we cannot expect to find context-free answers, these questions provide a very suitable approach for discussing the viability of design decisions in actual project situations.
6. Conclusion
In the light of constructivist thinking, the responsibility of those involved in software development is explicit, as they are entrusted with managing choice scopes. Quality is promoted through self-organization by allowing for variety, by seeking feed-back and by ensuring multi-perspective reflection in design. Design, then, becomes a matter of caring about choices.
In designing systems for computer supported cooperative work, in particular, we create working milieus for users in organizational settings. On the one hand, they provide space for autonomous situated action of individuals, on the other they embody concepts for organizational control reified as auto-operational form. The dialogical approach suggested in this paper aims at bringing in and crossing the perspectives and needs of the different parties involved: management, the users and so on with a view to finding a viable solution for all.
Keeping in mind the social nature of organizations, it is important to argue the relevance of the views presented here. Do they assume harmony? They do not. Quite on the contrary, the idea is to bring out and discuss the different perspectives involved and thus to break through a culture of organizational silence. Do they disregard power? Certainly not. There is an inherently emancipatory element in this approach, requiring personal integrity, the ability to see options and the willingness to form alliances. Can they be inhibited through sanctions? We need to take this into account. Indeed, we need to find workable strategies in the actual situation for achieving the scope of choice necessary for design.
According to constructivist thinking we, ourselves, are key elements in the process: it is a question of how we regard existing power structures and potentials for change, whom we seek to involve in the process and how, what kind of distinctions we bring out and what compromises we suggest. So, our role as software developers becomes more like that of a moderator or a therapist: we facilitate a process of organizational change to be triggered by the introduction of technology. Whilst we cannot determine the outcome of this process, the possibilities we admit into the discussion, the choices we propose and the technical constraints we implement, are ways of how we construct reality.
Bjerknes B. (1992) Shared Responsibility: A Field of Tension. In: Floyd et al. (1992) 295–301.
Bråten, S. (1973) Model monopoly and communication: Systems theoretical notes on democratization. Acta Sociologica 16 (2) 98–107.
Budde R., Kautz K., Kuhlenkamp K., Züllighoven, H. (1992) Prototyping – an Approach to evolutionary System Development, Springer-Verlag, Berlin, Heidelberg.
Budde R., Züllighoven H. (1992) Software Tools in a Programming Workshop. In: Floyd et. al. (1992) 252–68.
Checkland P. (1981) Systems Thinking, Systems Practice. John Wiley & Sons, Chichester.
Dahlbom B., Mathiassen L. (1993) Computers In Context – The Philosophy and Practice of Systems Design. Blackwell Publishers, Cambridge MA.
Floyd C. (1992a) Human Questions in Computer Science. In: Floyd et al. (1992) 15–28.
Floyd C. (1992b) Software Development as Reality Construction. In: Floyd et al. (1992) 86–100.
Floyd C. (1995) Theory and Practice of Software Development – Stages in a Debate. In: Mosses P. D., Nielsen M., Schwartzbach M. I. (eds.): TAPSOFT’95: Theory and Practice of Software Development, LNCS 915, Springer-Verlag, Berlin, Heidelberg, 25–41.
Floyd C. (1996) Choices about Choices. In: Systems Research 13 (3): 261–70.
Floyd C. (1997) Autooperationale Form und situiertes Handeln. In: Cognitio Humana – XVII. Deutscher Kongreß für Philosophie, Akademie Verlag: 237–52.
Floyd C., Krabbel A., Ratuski S., Wetzel I. (1997) Zur Evolution der evolutionären Systementwicklung: Erfahrungen aus einem Krankenhausprojekt. In: Informatik Spektrum 20 (1): 13–20.
Floyd C., Reisin F.-M., Schmidt G. (1989) STEPS to Software Development with Users. In: Ghezzi C. & McDermid J. A. (eds.): ESEC’89, LNCS 387, Springer-Verlag, Berlin, Heidelberg, 48–64.
Floyd C., Züllighoven, H., Budde R., Keil-Slawik R. (eds.) (1992) Software Development and Reality Construction. Springer-Verlag, Berlin, Heidelberg.
Foerster H. von (1984) On Constructing a Reality. In: Watzlawick P. (ed.): The Invented Reality. W. W. Norton, New York, 41–62. http://cepa.info/1680
Foerster H. von (1992) Ethics and Second Order Cybernetics. In: Cybernetics and Human Knowing 1(1): 9–20.
Foerster H. von, Floyd C. (1992) Self-Organization and Software Development. In: Floyd et al, 75–85. http://cepa.info/1738
Gryczan G. (1996) Prozeßmuster zur Unterstützung kooperativer Tätigkeit. Deutscher Universitäts-Verlag, Wiesbaden.
Jayaratna N. (1994) Understanding and Evaluating Methodologies. McGraw Hill, London. Keil-Slawik R. (1992) Artifacts in Software Design. In: Floyd et al. (1992) 168–88.
Klein H. K., Lyytinen K. (1992) Towards a new Understanding of Data Modelling. In: Floyd et al, 203–20.
Maaß, S., Oberquelle H. (1992) Perspectives and Metaphors for Human-Computer Interaction. In: Floyd et al. (1992) 233–51.
McDermid J. A. (1990) Software Engineer’s Reference Book, Butterworth Heinemann.
Naur P. (1992) Programming as Theory Building. In: Computing: A Human Activity. Addison-Wesley, Reading MA, 37–48.
Nurminen M. (1992) A Subject-Oriented Approach to Information Systems. In: Floyd et al. (1992) 302–12.
Nygaard K. (1986) Program development as social activity. In: Kugler H. G. (ed.): Information Processing 86 – Proceedings of the IFIP 10th World Computer Congress. North-Holland, Amsterdam, 189–98.
Pasch J. (1994) Softwareentwicklung im Team. Springer-Verlag, Berlin, Heidelberg. Reisin F.-M. (1992a) Anticipating Reality Construction. In: Floyd et al. (1992) 312–26.
Reisin F.-M. (1992b) Kooperative Gestaltung in partizipativen Softwareprojekten. Peter Lang, Frankfurt a.M.
Suchman L. A. (1987) Plans and Situated Actions – The Problem of Human-Machine Communication. Cambridge University Press, Cambridge UK.
Volpert W. (1992) Work Design for Human Development. In: Floyd et al. (1992) 336–48.
Found a mistake? Contact corrections/at/cepa.infoDownloaded from http://cepa.info/3126 on 2016-10-07 · Publication curated by Alexander Riegler