INTRODUCTION

Recall (from chapter 5) that according to the evolutionary model a design at any stage of its development is best viewed as a tentative or conjectural solution; in other words, as a hypothesis which must be tested in the course of that evolutionary cycle and its successors.

It may also be recalled that in the TPD paradigm (chapter 9) the plausibility state of a constraint is determined by the evidence invoked in support of or against the plausibility of that constraint. Accordingly, it was noted (in section 9.4) that there is an analogy between plausibility states in TPD and the states of hypotheses or conjectures in science (see fig. 9.3).

Finally, in discussing the nature of program correctness proofs in chapter 8 (section 8.9), we noted Fetzer's (1988) suggestion that computer programs be viewed not as mathematical theorems (as is assumed in the FD paradigm) but as empirical, refutable, conjectures.

These various discussions appearing in diverse parts of this book collectively seem to suggest that there is some sort of a connection between the method of design and the method of science.

The subject of this penultimate chapter is precisely this issue. More exactly, I wish to examine whether, or under what conditions, the design process may legitimately be viewed as a process of scientific theory construction. I will anticipate later arguments by stating in advance the following thesis.

As stated at the beginning of chapter 3 the designer's brief is to develop a form such that an artifact constructed according to this form would satisfy the requirements. The form is the design. The ultimate output of a design process must, then, be an explicit description or representation of the form in some abstract or symbolic language. I shall use the term design description to refer to such symbolic representations of forms. When ‘design’ is used as a noun it becomes essentially a synonym for ‘form’.

The concept of form is elusive, abstract, and complex. It may refer to the visible shape of an entity – as when naturalists and biologists talk of biological forms. It may refer to the essential or ultimate nature of a thing – as when philosophers talk of Platonic forms. It may denote the way in which certain parts are arranged and related to one another in an entity – as when one talks of the form of an essay, an argument, a solution, or a musical composition. Finally, architects talk of forms or ‘built’ forms (March 1976, Alexander 1964) in which term they embrace in a complex, diffuse fashion, the totality of shape, structure and relationships of parts as manifested in buildings.

These examples clearly reveal that form as a general concept is multifaceted. Thus, when we undertake to design an artifact the end product of our activity – the form of the artifact itself and how it is to be described – is critically dependent on how or for what purpose the design is to be used.

THE AUTOMATION OF DESIGN

Thus far, the discussion of design paradigms has been basically devoted to the significance of design theory for computing systems design. Furthermore, the implicit focus has been on design as an intellectual, cogitative, human activity. In this and the next chapter I shall examine the obverse side of the coin – that is, the implications of computer science for design theory.

This is an issue that becomes rather relevant if we are interested in the automation of design. Specifically, we may ask the following types of questions: does the goal of automation cause us to expand our understanding of the design process (with respect to the architectonics discussed in Part I)? Given the desire to automate design, what are the characteristics of the relevant design paradigms?

The ‘classical’ response to the need to automate any task is to devise algorithms to perform the task. From a ‘classical’ perspective then, we are led to the algorithmic design paradigm. According to this paradigm, given a design problem one constructs algorithms that produce the design form. An algorithmic approach to design automation has the same kind of compelling appeal exhibited by the formal design paradigm: algorithms are formal, objective procedures with well defined, understandable behavioral characteristics. The problem with this paradigm is essentially twofold: firstly, the design problem must itself be sufficiently well-structured (see chapter 3, section 3.3) as to allow the algorithm to contain well defined conditions for its own termination; that is, in order to generate a solution to the design problem, the algorithm must ‘know’ what constitutes a solution and how to recognize the attainment of a solution.

In this book I intend to examine the logic and methodology of design from the perspective of computer science. Computers provide the context in two ways. Firstly, I shall be discussing the structure of design processes whereby computer systems are, or can be, designed. Secondly, there is the question of the role that computers can play in the design of artifacts in general – including other computer systems.

The aim of any systematic enquiry into a phenomenon is to uncover some intelligible structure or pattern underlying the phenomenon. It is precisely such patterns that we call theories. A theory that claims to explain must exhibit two vital properties. It must be simpler – in some well defined sense – than the phenomenon it purports to explain; and it must be consistent with whatever else we know or believe to be true about the universe in which the phenomenon is observed.

The phenomenon of interest in this book is such that it cannot be adequately described by a single sentence. That itself is an indicator of its inherent complexity – and therefore of its intrinsic interest.

Perspective differences at the Postal Giro

When we enter a large organization like the Postal Giro, we will be exposed to a large inhomogeneous mass of written and spoken language: we listen to the speech of workers engaged in work, interview them and talk to them, read manuals and look at the screen images they work with, and talk to management in offices removed from the shop floor. Although many of these verbal exchanges clearly refer to the same physical phenomena, the linguistic forms can be quite different. It soon appears that each linguistic form is adapted to the particular function the speaker fulfills in the total structure of work processes and power relations in the organization. Each sub-language expresses a particular perspective (on perspective, see Section 1.2.2.2) and reveals a partial truth about the organization.

In the development of the PGP system there was one major issue that in a nut-shell illustrates the intricate interplay between language, perspectives and position in the division of labor. In semiotic terms, the issue was simply the relation between signifier and signified, in this specific case taking the form of a disagreement between union and management about electronic scanning of paper forms.

Management wanted to get rid of all paper by optical scanning of the paying-in-forms and wanted all subsequent work involving the cards to be done by means of electronic card images on a video screen. The union demanded that the basis of data recording should still be the paper forms, so that a direct feeling of the amount of work remained intact. The union succeeded in preventing electronic scanning of paper forms.

In the previous part, I described the basic properties of computer-based signs. They have three main kinds of features (permanent, transient and handling features) and are organized in two main chains (concurrent and sequential). In this part, I shall treat composite computer-based signs. How are smaller computer-based signs combined to form larger signs?

It is very clear that complex signs corresponding to linguistic concepts like phrases, sentences, and periods exist. The player of video games will experience long nerve-racking combat episodes involving the hero and one or more enemies, and the user of a word processor will engage in major tasks like proof-reading a manuscript or reorganizing the composition of a text, involving extensive handling of tools and text. Since these larger activities are manifested in system processes, they must be considered signs also, and since they contain smaller recurrent elements with meaning (the hero and enemy, the tools and texts), they are composite signs.

Although the three main features of computer-based signs have been treated in detail, I have not yet said much of the analytical consequences of the fact that computer-based signs participate in two different chains.

I shall continue using the textbook on folk-dance from Section II. 1.2, since a dance instructor or a writer of textbooks on dance faces problems similar to those facing a designer of computer systems. Like the designer prescribing the sequence of computer-based actions and the stage of the screen, the dance instructor must teach the dancers how to move in time on the floor, how to coordinate their movements with their partner, how to hold each other, and how to establish collective patterns.

A psychological definition of language games

In the preceding section, I showed how to use semantic fields of lexical material for various purposes: when the system developer enters the organization she can use them to get an impression of conceptual differences of the organization, when she starts doing particular applications she can use them to design the general data structure, and when she has made a prototype, semantic fields are useful for evaluating its reception and for redesigning it. Finally, researchers studying the general effects of computerization on organizations can use semantic fields to record language changes in the organization, and use these data as a basis for setting up hypotheses about changes of culture and cognition.

However, language is more than a vehicle for interpretation and description. Besides the ideational functions, language also has an action aspect that is subsumed under Halliday's interpersonal functions.

Although it is not a bad idea to start with the ideational aspect, since professional languages are registers and tend to differ in vocabulary, the action aspect is equally important in systems development. Language in work situations is not only used to interpret and describe, but also to act verbally, and in a similar way, computer systems are used as media for distributing work, giving orders, and reporting. Designers not only need to know which kind of information is needed and how it should be structured semantically, they also need to know when it is needed and for which purposes.

In the preceding section, I showed how to use work and conversation patterns as a basis for design. In this last section I discuss principles for building these patterns into the system. What does it mean to “put work patterns into the system”? To what degree should it be done? How should it be done?

As my example I shall use the data entry parts of the data entry (registrering) process classified as control style in Section II.2.2.2. Here I noted that the PGP-system is in control in this part of the work process and guides the worker through a fixed standardized sequence of operations:

In addition, it automatically provides the next card of the same batch, and the first card of the next batch when the last of the previous batch is finished and the batch tallies. If it does not tally, it enters the completing subview. The system supervises the user's work, and directs the worker's attention to and from the screen by means of error messages like

a type of control which was consciously introduced by the developers: they wanted to “stop a phase where you work with the card, and initiate a phase where you work with the screen”.

I have already classified this standardization of work as a “frozen” variant structure.

I start with a reassessment of selected linguistic traditions. Since they were developed to meet needs other than those I want them to serve, a careful reexamination is not out of place.

Empirical characteristics of two work languages

The first issue I shall take up is simply whether they are able to handle the language variety in which most computer systems must function, namely the languages of people at work, and in order to do so we need to know what a “work language” is.

The car repair shop

The typical Danish car repair shop is a small scale enterprise, consisting of the owner and a couple of skilled workers, possibly an apprentice and a bookkeeper, as well.

Most of the work can be performed by one worker alone, so cooperation is seldom a physical necessity. Planning and execution of the work procedure is integrated. The mechanic performs both tasks. Personal relationships between employer and employee survive, such as the master-journeyman relationship. Normally, a small stock of tools is used: hammers, screwdrivers, nippers, etc.

In the early eighties, I investigated communication in a small repair shop, and the following pages are based on this project. The research was done in collaboration with one of the mechanics employed in the garage. A taperecorder placed on a bench recorded the conversation that took place during work. (Everybody in the garage knew about the recording.) The mechanic also produced written descriptions of whole working days.

The analysis of the data took 1 1/2 years. The mechanic was employed as an assistant teacher in an advanced course at the university.

In Part I of this book I presented a general framework for understanding language and computers, and in Part II showed how to apply this framework to analysis and design of computer systems. What remains to be done now is to broaden the scope of our analysis, and show how the same framework can be used for describing and designing computer systems in a practical context of work. In order to do that I need a concrete example, and I shall use data from the 1986 project at the Postal Giro Office in Stockholm, “Professional language in change”, mentioned in Section 1.1.1.

Before I start on this last stage of the journey, I think it would not be out of place to make a short summary of what has been accomplished so far.

Although the theoretical framework of the book is not natural science but a structuralist tradition of semiotics and linguistics, the project of the book is a part of an ongoing paradigm change in computer science itself: from seeing the computer system as a self-sufficient mathematical object, the focus is gradually being shifted to the relations between system and work context. An important practical motivation for this shift is simply that it hopefully will enable us to construct computer systems that meet the needs of the users in a better way. However, the shift is also theoretically motivated by the structuralist framework, since structuralism is characterized by focusing on relations, not on objects, as the real existing phenomena.

What is computer semiotics?

Semiotics is the science of signs and their life in society. A sign is anything that stands for something else for someone.

Semiotics treats all kinds of signs: verbal language, pictures, literature, motion pictures, theater, body language. Computer semiotics is a semiotic discipline that studies the nature and use of computer-based signs.

The motivation for the discipline comes from the nature of computer systems: although in many respects computer systems can be conceived as tools in analogy with typewriters, pencils, brushes and filing cabinets, they differ from these tools by not primarily existing or being used as physical objects, but as signs. The pencil of the drawing program is no real pencil that can be used to chew on, it is merely stands for a pencil, represented by a collection of pixels on the screen. Computer systems resemble other media by primarily acting as carriers of meaning.

Even if computer systems basically are symbolic tools, this symbolic nature has only attracted serious attention in recent years.

The reason for this is threefold: from being a tool only for specialists, computers have now been integrated into many occupations, and therefore the demands for interpretability have risen. The mode of operation and the meaning of the data must be easy to grasp for the secretary or the manager whose time should not be spent deciphering cryptic codes but writing agendas or making decisions. A good interface has become a necessary prerequisite for a good system.