Are We Trapped by our Training?

Published in Conference Proceedings, Information Technology Training and Education, University of Queensland, 1991


ARE WE TRAPPED BY OUR TRAINING?

by

Chris F Reynolds

CODIL Language Systems Ltd., 33 Buckingham Road, Tring, Herts, HP3 4HG, ENGLAND

(Currently a visiting research scientist (until June 1991) at CSIRO Division of Information Technology, PO Box 1599, North Ryde, NSW 2113)

Abstract

Nearly twenty years ago Gerry Weinberg reported that he could predict a trainee PL/1 programmer's prior computing background from the way he used his new language and this can be considered as as an instance of the Sapir-Whorf theory which suggests that ours languages shape the way we think. Recently Richard Pettersen has suggested a relation between the computer languages Pascal, Prolog and Basic and the mother tongues of their creators.

    This psychological effect is relevant to the long term impact of industrial training in the information technology field. This is because the majority of the training effort goes into teaching how to use very specific languages; systems and packages, which often have short life spans compared with the average employee's working life. The continued use of tarted up version of first generation high level languages such as COBOL and Fortran would seem to owe much to the large pool of programmers for whom is is easier to continue with the old, rather than switch to newer, more sophisticated tools.

    But how important is the effect in practice? One effect will be that information technology employers will show an increased preference for the young - who can be trained without having to counter-act the mental clutter the old have accumulated by working with what are now obsolete systems. Another hazard is more subtle - in that certain ideas will be propagated through the industry for no better reason than, like the QWERTY keyboard, they are accepted by the majority.

   This paper examines this last idea in the light of an unconventional educational package called MicroCODIL, which was developed to to demonstrate a wide range of information technology ideas, including some in the artificial intelligence and expert systems areas. The package was well received by the technical press in the U.K. - but problems in getting it widely used were encountered because it was too flexible - and hence violated some of the sacred cows that anyone who works in the computer industry takes for granted. Particular problems are described, and it is concluded that there are information technology concepts in which there are serious mental blocks in the minds of those instructed in procedural programming or relational data base techniques.

Language affects thought

As Benjamin Whorf showed [Whorf, 1956], in his study of American Indian languages, the structure of the languages we use has a major effect on the way we think. Our assumptions about space, time, and form are related to the structure and the lexicon of the natural language we use.

    This effect extends to computer programmers. Nearly 20 years ago Gerry Weinberg [Weinberg, 1972] reported that he could predict trainee Pl/l programmers' prior computing background from the way they used the new language. Not only did they tend to use a subset of PL/1hat corresponded most closely to their previous language, but also they tended to assume that the old language restrictions applied to PL/1. The effect is often considered to be very far reaching and Edsger Dijkstra [Dijkstra, 1982] has claimed that:

"The use of COBOL cripples the mind: its teaching, therefore, should be regarded as a criminal offence"

and

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

    While anyone who has ever taught programming can think of cases where such problems occur, Dijkstra has undoubtedly overstated the problem. Of course there are COBOL programmers who are motivated by the problems of commercial data processing who would be left unmoved by Dijkstra's attempts to teach them a "more academic" approach to computer programming. At the time there are theoretically oriented programmers, who revel in the delights of languages like LISP, and who would be equally "crippled" if transferred to the "alien" commercial data processing environment involving messy real world data.

    The importance of the mental aspect of programming is highlighted by recent research, such as that by Stone, Jordan and Wright [Stone, 1990]. They studied the impact of PASCAL education on programming skills and concluded that the most relevant area to study was the structure of the programmers' mental processes and representations. Mental models are equally important in the way users at all levels interact with computer packages, and for maximum effectiveness it is important that the language/systems designer, the user, and the educationalist understand the nature and limitations of such models.

Where does Education and Training come in?

These psychological effects are relevant to the long term impact of training in the information technology field. The key question is how far the system designer (at all levels from programming languages to everyday application packages) should be trained to adjust his mental model to suit the user - and how far should he simply be taught to accept the tools he is given. A recent supplement to an Australian computing newspaper [Computing, 1990] contains a summary listing of over a thousand courses. The vast majority were specifically oriented towards specific languages or packages but there was a solitary "User Role in Developing Systems" course put on by the Australian Computer Society. This fits in with an earlier survey of U.K. contracting jobs [Reynolds, 19891 which found only one, out of three thousand jobs listed, directly related to some aspect human-computer interaction. Of course, some of the courses under titles such as "systems analysis" will have some user oriented content but their number is small. Look in any bookshop, and 95% of the computer books will be "how to use it" recipe books, with very few covering the user aspects of design or psychological modelling.

    The problem is that the computer industry, of which the computer training and education field is merely a part, has become caught up in a classical technology trap. This occurs because the mental and physical investment in older ideas means that it is easier to train new staff in the old ways that to retrain the more numerous existing staff in new ways. The best known example of such trapping is the sub-optimal QWERTY keyboard, where a century old layout has become an international standard for computers for no better reason that it was already well known. The layout is so deeply ingrained in users' subconscious minds that the only way it will ever be changed is to replace keyboards with other kinds of input device, such as speech recognition. A related development in the word processor field is the awkward and often irrational combinations of control key commands, used in packages such as Wordstar, which date from early keyboards without function key facilities. The MS­ DOS operating system for personal computers is rapidly becoming the modern equivalent of the QWERTY keyboard - with its archaic and unfriendly features - but it may not survive for as long in its crudest incarnations because of the advent of WIMP systems which may well replace it with a radically approach to control. The continued use of first generation languages such as COBOL and Fortran would seem to owe much to the large pool of programmers and programs for which it is easier to continue with the old, rather than switch to newer, more sophisticated tools.

    In practice what happens is that staff are trained to use languages and packages whose lifetime is short compared with the normal employment lifetime. However once an organisation decides to standardise on a language or package its investment in programs, data, and people is such that it is likely to stay with that language or package until technical advances in the computer field make it obsolete. The consequence is that many staff are faced with five or ten years working with a single system until it is second nature to them, and are then faced with a retraining step which will represent a radical advance in the technology. While it is clear that many people can make such a transition, it is clear that some find it traumatic, while others are unable to make the most of the changes because of many years preconditioning on earlier and now outdated technologies. It is clear from the blatant age discrimination that is widespread in the computer industry that most employers believe that it is better to recruit young staff, who have never been exposed to the old technology, than to retrain old staff with skills to unlearn.

    This immediately raises the distinction between training for a particular narrow technology, and education for the future. It is clear that the vast majority of training materials in the computer field contain little or nothing to prepare the students for the changes to come. For example, a few years ago the author carried out a survey of some twenty introductory and advanced COBOL text books in order to select one suitable for teaching. Virtually all of them failed to mention any other computer language, or to identify the general computing concepts which are applicable to any procedural language. While they clearly identified COBOL's strong points, areas in which COBOL is weak compared with other languages were invariably ignored, apparently on the assumption that drawing attention to such difficulties would sully the "COBOL is the solution to all your problems" tone of the overall text. My own experience of long­term COBOL programmers suggests that those who have swallowed this "textbook" line are likely to be the least flexible when things change, and it may well be that Dijkstra's criticism of COBOL should really be directed at COBOL training, and the lack of exposure many COBOL programmers in industry have had to general programming principles.

Context affects Language Development

There is another dimension to the problem. Of course, programming languages influence the way programmers think about problems. Different languages reflect different needs, such as high run time efficiency, logical consistency, ease of use, etc. In addition, each programming language reflects the context in which it was developed and the though processes of its inventors. For example, Richard Pettersen [Pettersen, 1990] recently commented that computer languages often reflect the language and culture of their originators. Thus PASCAL was created by Niklaus Wirth, a German­speaking Swiss and PROLOG clearly reflects its French origins. BASIC is clearly a quickie do-it-yourself tool in the American tradition while COBOL clearly reflects its relation to the world of corporate business.

    In a completely different context, Margaret Shotton [Shotton, 1989] surveyed the behaviour of computer addicts, and gained the impression that addicts were good at writing programs that would be highly attractive to other addicts. On the other hand their programs were often unusable by non-addicts because they showed very little understanding of the needed of naive computer users. In fact the situation is almost certainly much more general in that there is a natural tendency for systems designers to design systems which reflect their own mental model of the world .. In cases were the user shares a mental model with the designer, this is perfectly satisfactory. In cases of incompatibility, the user will either need to mentally adjust in order to understand the designer's thoughts - or even worse uses the system mechanically and without understanding.

This raises an interesting question. If users fingers are trapped by the ancient QWERTY keyboard, and old-fashioned languages like COBOL and BASIC, or operating systems like UNIX or MS-DOS, can exert such an influence out of inertia, are we in danger of being trapped at a still higher conceptual level? I suspect that we are, and I will give some examples from my own experience in developing a package called MicroCODIL.

The MicroCODIL Experience

A full description of MicroCODIL is inappropriate here, as extensive details have been published elsewhere. However, it is a teaching package designed to allow a wide range of modern information technology research ideas to be introduced to pupils in the classroom in practical teaching situations (Reynolds, 1990a). Within a simple expert system/knowledge base environment it allows topics such as poorly structured information (missing and multivalued data), approximate, range and fuzzy matching and probabilities to be handled in a practical but non­mathematical environment (for examples of how it is used in teaching see Reynolds,1988). Human factors have played an important part in the package's design (Reynolds, 1987a, b). It has been been well received by the UK technical and educational press, and used for a wide variety of classroom subjects ­ including its use for local history studies, where its flexible approach allows the messy data common to historical records to be processed with minimum fuss (Reynolds, 1990b). The MicroCODIL architecture has also been described in detail (Reynolds, 1990c).

    As suggested earlier, computer languages reflect the mental model of their creators, and MicroCODIL is no exception. The background context involved considerable experience of manual research and development reporting to the management of an international company, coupled with a design study for a very large and complex computerised invoicing system and virtually no contact with typical "simple" commercial data processing tasks. In such circumstances it is perhaps not surprising that an important element in the underlying model was that real world data is naturally messy and what was required was a dynamically open-ended system which can accommodate the initial ignorance of both the designer and the user as appropriate. The role of ignorance in the design of MicroCODIL, and its relevance to artificial intelligence research, have been discussed at length elsewhere (Reynolds, 1990d) and this paper will confine itself to the way in which MicroCODIL represents data and handles "rules".

    The MicroCODIL approach to handling data is best introduced with an example. The following "listing" contains a simplified extract from a typical family history file, describing the incidents in the life of one George Washington Gibbs.

1	NAME = Gibbs, George Washington,
2		YEAR = 1802,
3			PLACE = Aylesbury, Bucks,
4				EVENT = Birth,
5					FATHER = Gibbs, Robert,
6						MOTHER = Miller, Ann.
2		YEAR = 1824,
3			PLACE = St Albans, Herts,
4				ADDRESS = Clock House,
5					LANDLORD = St Albans Corporation.
2		YEAR = 1825,
3			PLACE = Watford, Herts,
4				EVENT = Marriage,
5					WIFE = Dagley, Ann.
2		PLACE = St Albans, Herts,
3			YEAR = 1826,
4				ADDRESS = Clock House,
5					OCCUPATION = Printer,
6						OCCUPATION = Broker,
7							OCCUPATION = Pawnbroker,
8								SOURCE = Antique print.
5					OCCUPATION = Auctioneer,
6						PARTNER = Gibbs, John,
7							SOURCE = Trade directory.
3			YEAR >= 1828,
4				YEAR =< 1829,
5					DAUGHTER = Gibbs, Ann.

    For anyone interested in the history, the file is immediately recognisable, and usable, as a source of information about G W Gibbs. It contains a number of items (each approximately equivalent to a conventional data field) and a number of statements, each describing an event in his life (each approximately equivalent to a conventional record). Any "record" may contain any combination of "fields" and there is no need for any "record" predefinition. (If all the "records" on a file contain equivalent fields, which is perfectly possible, this is because the application requires such a regular structure, and not because the software requires some programmer or systems analyst to predefine the field combination.) Any "field" may represent a simple value (of dynamically variable length), a range, a item in a list, or even a complete file! Under most circumstances the order of the "fields" in a "record" is immaterial, although by having the NAME item first it can be shared between a number of "records" without needing to repeat it..

    Such an approach is in marked contrast with the conventional database approach, which originated with the pre-computing 80 column punched card, with predefined columns. This fixed format approach was adapted to early disc-based systems, where fixed sized records allowed faster access with the comparatively limited hardware involved. (It is worth noting that in the UK many early computers used paper tape rather than cards and this lead to the development of variable format systems. Unfortunately these flexible techniques were "lost" because of the over-powering influence of IBM and fixed format languages such as COBOL.) The fixed format idea then became enshrined in relational data base ideal, which evolved to handle the well-structured tables of data which which characterised most early data processing. More recently the spreadsheet has become popular, encouraging still further the idea that the idea that data is best handled as a regular array.

    In trying to teach the MicroCODIL approach I have discovered that the "arrays of little boxes" approach is as deeply embedded in many otherwise very competent computer programmers' minds as the QWERTY keyboard is for a touch typist. A similar effect is noted with many users of personal computer data base packages, and I have been fervently told on many occasions that it is impossible to use a computer to handle data unless the records are predefined, and often that fields must have predefined types and lengths. If I can persuade such a person to use MicroCODIL they will admit that it has the freedom they previously denied as impossible - but they seem almost incapable of making use of it. For instance they will create a file with no "explicit predefinition" but in which every "record" contains the same "fields" in the same order. This kind of mental block can occur almost irrespective of the individual's previous computer language, ranging from COBOL to PROLOG.

    The question of programs and rules in MicroCODIL also causes considerable problems. In MicroCODIL there is is a knowledge base which contains files of items - and there is no formal distinction between rules and data. Processing takes place merely by comparing files (often recursively) item by item. ANY file may be used as data, as a set of rules, or as a boolean condition returning true or false, and in many applications there is nothing that looks like a program. Many people experienced in procedural programming find considerable difficulty in unlearning the idea that applications must have a clearly defined set of rules.

  For example one experienced COBOL programmer decided to learn CODIL (MicroCODIL's main frame predecessor) and set out to implement a simple application in both CODIL and COBOL. After a short time he reported that it was so easy in CODIL that he wouldn't bother to do it in COBOL. On examining his working package I observed with surprise that he had tried to use CODIL as if it were a COBOL interpreter which did not require a predefined data division. When I explained that virtually all his "code" was redundant because CODIL would would carry out many of the operations automatically he threw up his hands in utter disbelief. Others are often puzzled by MicroCODIL because they cannot find the application programs which they assume must exist somewhere.

    Basically the problem seems to be that exposure to a wide range of computer programming languages and/or software leads to a QWERTY type mental block where it is assumed that, because all the application programs and file structures they have encountered have to be rigorously predefined, all computer applications MUST be constrained in this way. Even when it is demonstrated that these constraints can be relaxed, the programmers' training and experience force them to only select well­ structured tasks which can comparatively easily be predefined. It is almost as if contact with computers has lead many people to reject open-ended solutions to open-ended real world problems as a valid area for computerisation - to the point where they either reject them or feel obliged to try to rationalise them into a well-structured framework.

    It is easy to see how this has happened. Historically, the early computers were designed for well-structured problems, in which the rules were readily specified and the data could be treated as having a regular arrangement. These computers attracted applications which fitted the "early computer" conceptual model, and also attracted, as programmers, people who found it easiest to identify with the conceptual model. There was so much to be done that the next generation of hardware and software basically extended the original framework, and this has continued because, through inertia, it is easier to continue in the same direction. without realising that some of the "sacred cows" of computer science were artefacts of history, in the same way that QWERTY is.

    Of course not every person working with computers is infected with the "little boxes" approach. Certain large database applications, such as library, museum and archaeological record keeping, are based on variable structure records because a conventional "fixed" approach is obviously inappropriate to the task in hand. Despite the significant amount of work done in this field, it is interesting to note that it has almost totally been ignored by the majority of data base theorists, who would seem to prefer to work with data which fits with more sophisticated mathematical models.

Conclusion

The computer industry is currently in a technology driven stage where new hardware and software ideas are introduced before their benefits and limitations can be fully assessed. The speed of advance is such that it is impossible for individual companies to continually keep up with the new developments and produce usable results. As a result companies tend to select a particular programming language, or set of packages, and to stay with this until obsolescence forces a radical change. This means that many employees are faced with perhaps five or ten years working with, and gaining considerable skill on, a particular system only to be faced with a radical shift to something new when their old skills become redundant. Some, unfortunately will not make it.

    This situation suggests that it is necessary to introduce more education for change into computer oriented training. Programmers and users alike should understand where the systems they use fit into the general framework of computing, and in particular where difficulties are due to the the generation of technology they are using. Unless this happens the computer scene will be littered for many years with modern versions of the QWERTY syndrome - but are a far higher, and hence more blinkering ­ level.

References

Computing (1990) IT Training'91

Dijkstra, E. (1982) Selected Writings on Computing: A Personal Perspective, Springer­ Verlag

Pettersen, R. (1990) The tongues of men and machines, Byte, August 1990

Reynolds, C. F. (1987a) The use of colour in language syntax analysis, Software Practice and Experience, 17, 513-519

Reynolds, C. F. (1987b) Human factors in systems design, in People and Computers III, (edited by Diaper, D & Winder, R) pp 93-102

Reynolds, C. F. (1988) Introducing expert systems to pupils, J. Computer Assisted Learning, 4, 79-92

Reynolds, C. F. (1989) People don't matter in computing, Freelance Informer, 17 November 1989

Reynolds, C. F. (1990a) Moving information technology research from the laboratory to the classroom, Aspects of Educational and Training Technology, 23, 226-230

Reynolds, C. F. (1990b) A flexible approach to local history data in the classroom, Computers in the History Classroom, (edited Martin, A., & Blow, F.), Leeds University Press, 189-200

Reynolds, C. F. (1990c) CODIL - the architecture of an information language, Computer Journal, 33, 155-163

Reynolds, C. F. (1990d) A re-examination of Turing's notebook model, presented to the Australiasian Society for Cognitive Science First Annual Conference, 4-7th November (Publication status of proceedings uncertain)

Shotton, M. (1989) Computer Addiction? Taylor & Francis

Stone, D. N. et al (1990) The impact of Pascal education on debugging skills, Int. J. Man-Machine Studies, 33,81-95

Weinberg, G. M. (1972) The Psychology of Computer Programming, Addison Wesley

Whorf, B. L. (1956) Language, Thought and Reality, (edited Carroll, J.B.), The MIT Press