Innovation and Change in the Information Systems Curriculum of an

i

Innovation and Change

in the Information Systems

Curriculum of an Australian University:

a Socio-Technical Perspective

Arthur Tatnall

BSc(Melb), DipEd(Melb), BEd(Melb), DipCompSc(Latrobe), MA(Deakin)

A dissertation submitted in fulfilment of the requirements for the degree of Doctor of Philosophy

Faculty of Education Central Queensland University

June 2000

ii

Abstract Information Systems is a relatively new curriculum area and one that is still growing in size and importance. It involves applied studies that are concerned with the ways people build and use computer-based systems in their organisations to produce useful information. Information Systems is, of necessity, a socio-technical discipline that has to deal with issues involving both people and machines; with the multitude of human and non-human entities that comprise an information system. This thesis reports an investigation of how Information Systems curriculum is made and how the choices of individual lecturers or groups of lecturers to adopt or ignore a new concept or technology are formed. It addresses this issue by describing a study into how the programming language Visual Basic entered the Information Systems curriculum of an Australian university, and how it has retained its place there despite challenges from other programming languages. It is a study of curriculum innovation that involves an important but small change in the curriculum of a single department in a particular university. Little of the literature on innovation deals with university curriculum and most reported work is focussed on research, development and diffusion studies of the adoption, or otherwise, of centrally developed curriculum innovations in primary and secondary schools. The innovation described here is of a different order being developed initially by a single university lecturer in one of the subjects for which he had responsibility. It is important primarily because it examines something that does not appear to have been reported on before: the negotiations and alliances that allow new material, in this case the programming language Visual Basic, to enter individual subjects of a university curriculum, and to obtain a durable place there. The research investigates a single instance of innovation, and traces the associations between various human and non-human entities including Visual Basic, the university, the student laboratories, the Course Advisory Committee and the academic staff that made this happen. It follows the formation of alliances and complex networks of association, and how their interplay resulted in the curriculum change that allowed Visual Basic to enter the Information Systems curriculum, and to fend off challenges from other programming languages in order to retain its place there. I argue that in this curriculum innovation no pre-planned path was followed, and that representations of events like this as straightforward or well planned hide the complexity of what took place. The study reveals the complex set of negotiations and compromises made by both human and non-human actors in allowing Visual Basic to enter the curriculum. The study draws on the sociology of translations, more commonly known as actor-network theory (ANT) as a framework for its analysis. I show that innovation translation can be used to advantage to trace the progress of technological innovations such as this. My analysis maps the progress of Visual Basic from novelty to ‘obvious choice’ in this university’s Information Systems curriculum.

iii

Table of Contents

Abstract......................................................................................................... ii

Table of Contents ........................................................................................ iii

Table of Figures........................................................................................... vi

Declaration................................................................................................... vi

1. Information Systems and Change ..................................................... 1 Curriculum Innovation: The Research Question......................................................2 The Disciplines Underlying Computing...................................................................3

Change in Information Systems Curriculum ......................................................4 The Demand for Information Systems Courses..................................................5

The Significance of this Study in IS Curriculum Innovation ...................................6 Organisation of the Thesis .......................................................................................7 Outline of the Curriculum Innovation at RMIT .......................................................8

Discovery and Exploration .................................................................................9 Prior Claimants...................................................................................................9 The Merger .......................................................................................................10 Surviving an Object-Oriented Challenge..........................................................12

IS Curriculum as Negotiation and Compromise ....................................................12

2. Information Systems Curriculum ................................................... 13 The Discipline of Information Systems..................................................................14

An Information Systems Body of Knowledge..................................................17 Model Computing Curricula from the United States .............................................18

ACM: Information Systems Curriculum Recommendations for the ‘80s ........19 DPMA: Information Systems - IS’90 ...............................................................20 ACM / IEEE-CS: Computer Science Curricula, 1991......................................21 Comparisons and Criticisms of ACM and DPMA Curriculum Models ...........22 Information Systems Model Curricula - IS’95 (draft report) and IS’97 ...........23 Other Model Curriculum Documents ...............................................................26

Programming in Information Systems Courses......................................................27 The IS Curriculum Development Process ..............................................................28

Keeping Courses up to Date and Relevant .......................................................30 The Importance of Human and Managerial vs Technical Skills.......................31

Curriculum Innovation in Information Systems.....................................................32

3. Theories of Innovation and Change................................................ 33 Innovation in Education .........................................................................................33 The Management of Change ..................................................................................35 The Adoption of Innovations by Schools...............................................................38 Innovation in Higher Education Curriculum..........................................................39 Innovation Diffusion ..............................................................................................41

Attributes of an Innovation...............................................................................42 Nature of the Communications Channels .........................................................44 The Passage of Time ........................................................................................46 The Social System ............................................................................................47

iv

Generating Innovations: the Innovation-Development Process........................48 Information Technology Infusion.....................................................................48 Innovation Diffusion Research Traditions and Topologies ..............................49 Research Biases and Criticisms of the Innovation Diffusion Model ................50

4. Innovation Translation.....................................................................52 Essentialist Approaches to Technological Innovation............................................52

Approaches Involving Social Constructivism and Actor-Network Theory......54 Actor-Network Theory .....................................................................................55

The Innovation Translation Model.........................................................................57 Innovation Translation and Innovation Diffusion ..................................................59 Mechanisms of Translation ....................................................................................61

5. Methodology ......................................................................................63 How this Research is Framed.................................................................................68

Soft Systems Methodology...............................................................................71 Ethnography .....................................................................................................72 Case Study Methodology..................................................................................74 How Actor-Network Theory Handles Complexity...........................................75

Uses of ANT and Innovation Translation Theory..................................................76 Criticisms of Actor-Network Theory................................................................78

The Author’s Place in this Study............................................................................79 Research Methods ..................................................................................................80 The Process of Gathering and Analysing Data.......................................................81

Ethical issues in data gathering and reporting ..................................................82 Actors in this study...........................................................................................83

The Research Process.............................................................................................85 Overview of the Adoption of Visual Basic.......................................................86 Actors and Networks in Information Systems at RMIT ...................................87 Interviewing Actors and Gathering Data ..........................................................88 Investigating Pick/BASIC and Alice Networks at RMIT Before the Merger ..89 Discussions on Object-Oriented Programming: Network Formation...............90 Introduction of Visual Basic and How its Network Formed ............................90 Follow-Up Interviews and Data Gathering.......................................................92 Interviewing the Course Advisory Committee .................................................94 More Follow-Up Interviews .............................................................................94

Reporting the Study................................................................................................95

6. Discovery and Exploration...............................................................96 Problems when Programming with Graphics in MS-DOS.....................................97 Fred’s Discovery of Visual Basic for MS-DOS .....................................................99

Fred as a Teacher, Programmer and Heterogeneous Engineer .......................103 Phillip Institute of Technology.............................................................................104

Information Systems at Phillip Institute of Technology .................................106 Business Programming at Phillip Institute .....................................................107

Exploration: Teaching Experiments with Visual Basic........................................108 Visual Basic and Other Alternate Visual Environments.................................112 Consolidation of Visual Basic’s place in the Curriculum...............................114 A Pause in Curriculum Development Due to the Impending Merger.............116

7. Prior Claimants: Pick and Alice....................................................117 RMIT University..................................................................................................118

v

Information Systems at RMIT........................................................................119 The Pick Operating System and Pick/BASIC ......................................................122

Pick and Pick/BASIC at RMIT ......................................................................124 Assembly Language Programming – the Alice Simulator ...................................128 Cobol....................................................................................................................131 A Comparison of Pick, Alice and Cobol at RMIT ...............................................132

8. The Merger...................................................................................... 134 Mechanics of the Merger .....................................................................................135 Getting External Input for Curriculum Changes ..................................................136 Conference Papers, Textbooks and Demonstrations ............................................137 Development of the New Degree .........................................................................139

The Information Systems Undergraduate Course Review Panel....................140 Course Teams and Educational Quality Assurance at RMIT .........................141 Introduction of Visual Basic in a Graphic User Interface Elective.................142

University and ACS Course Accreditation ..........................................................147 The New Degree Course ................................................................................148

Programming Languages and Course Proposals ..................................................149 Visual Basic and Applications Development-II .............................................152 The Survival of Pick.......................................................................................156 Alice’s Exit from the Information Systems Curriculum.................................160 The Failure of Cobol to Undergo a Revival ...................................................162 Object-Oriented Languages and Systems Implementation-II.........................162

9. Surviving an Object-Oriented Challenge ..................................... 164 Object-Oriented Forces for Change .....................................................................165

Contending Object-Oriented Languages ........................................................169 Visual Basic and Applications Development-II .............................................172

Problems with Using Visual Basic in Two Subjects ............................................175 Programming Languages and Future Curriculum Changes .................................178

10. What is Real? .................................................................................. 180 Apples, Mobiles, Trains, Monsters and Velveteen Rabbits .................................180 Real Programming Languages .............................................................................182 Using ‘Real’ to Mobilise the Computer Industry .................................................184 Gaining a Real Place in the Curriculum...............................................................185

11. Conclusion ....................................................................................... 187 Innovation Translation and Innovation Diffusion ................................................189 IS Curriculum Innovation: External Ideas and Serendipity..................................190 Research Contributions of this Study...................................................................191 Possibilities for Further Research in this Area .....................................................192

Bibliography ............................................................................................. 193

Appendix A. RMIT University............................................................................. 213

Universities and Colleges of Advanced Education ..............................................213 Creation of the Binary System in the 1960s ...................................................213 Universities and CAEs - The ‘Dawkins’ Amalgamations ..............................214

vi

The Birth of Information Systems at RMIT .........................................................214 RMIT’s Educational Quality Assurance System..................................................217

Course Teams and the EQA Process ..............................................................219 Course Reviews ..............................................................................................219 Different Opinions on EQA’s Virtues ............................................................220

RMIT: Then and Now..........................................................................................221

B. Visual Basic Development History ................................................222

Table of Figures

Figure 1.1 Computer Science, Computer Engineering and Information Systems.......4 Figure 2.1 Comparison of the coverage of IS, SE and CS curricula .........................17 Figure 2.2 Areas of Knowledge (ACS).....................................................................18 Figure 2.3 Chronology of Model Curriculum documents from the USA .................19 Figure 2.4 IS’97 subject areas...................................................................................25 Figure 2.5 Influences on MIS curriculum .................................................................29 Figure 3.1 Research, development and dissemination model ...................................34 Figure 3.2 Initiation decisions...................................................................................37 Figure 3.3 Pitman’s (1981) model of curriculum negotiation...................................39 Figure 3.4 Factors influencing curriculum................................................................41 Figure 3.5 Centralised versus decentralised diffusion systems .................................46 Figure 3.6 Categories of Adopters ............................................................................47 Figure 4.1 Innovation diffusion versus innovation translation..................................60 Figure 5.1 The Research Process ..............................................................................85 Figure 6.1 VB for MS-DOS; design screen for Wotan’s Cake Price Calculator ....101 Figure 7.1 Alice Computer Simulator .....................................................................129 Figure 7.2 Comparison of Pick/BASIC, Alice and Cobol at RMIT........................133 Figure 8.1 Personnel Viewer; VB runtime screen...................................................144 Figure 8.2 Visual Basic design screen, with code, for the ‘Personnel System’ ......145 Figure 9.1 Evolution and adaptation of Visual Basic in the IS curriculum.............177 Figure 10.1 Becoming ‘real’ in the curriculum.........................................................185

Declaration I certify that the thesis entitled ‘Innovation and Change in the Information Systems Curriculum of an Australian University: a Socio-Technical Perspective’ and submitted for the degree of Doctor of Philosophy is entirely my own work, except where otherwise acknowledged, and that it has not been previously submitted as a requirement for the award of a degree at Central Queensland University or any other institution of higher education. Arthur Tatnall 30/5/2000

Innovation and Change in Information Systems Curriculum page 1

Chapter 1

Information Systems and Change The importance of a study in Information

Systems curriculum innovation This thesis reports on a recent innovation in the Information Systems curriculum at RMIT University in Melbourne. It investigates how the programming language Visual Basic found a place in the curriculum, and how it has remained there despite serious challenge from other programming languages. The thesis is made up of eleven chapters. This first chapter sets up the research question and explains its significance. It also provides a brief summary of the main events in the adoption of Visual Basic at RMIT and details the organisation of the thesis. Visual Basic was first released by Microsoft late in 1991, and being a visual, event-driven language it represented a new paradigm in computer programming when compared to the procedural languages more commonly used at this time (Shackleton 1998). In 1999, Visual Basic is one of the most widely used programming languages in the world (Harriger and Lisack 1998). In relation to Information Systems education, a recent survey of universities in the United States (Hardgrave and Douglas 1998) shows that Visual Basic is not only widely taught as a general programming language, but that it is also the most popular language for use in teaching object-oriented programming in Information Systems courses, ahead of both C++ and Java. It is probably true, as you will sometimes hear an experienced programmer say, that you can solve a programming problem using any programming language; it is just that the solution is easier in some languages than others in each particular case. Despite this, however, the choice of which programming languages to teach in an Information Systems (IS) course is still a very important decision. There are three main reasons this choice is important and why it is argued over almost incessantly in IS academic staff rooms around the world. Firstly, there is an employment-related reason; students like to be able to ‘tick the box’ in job advertisements to show the programming languages they have studied. This tends to lead IS departments to lean towards the more popular languages, the ‘real’ programming languages used to a large extent in the computer industry. The second reason is educational; some languages are easier to teach with and more suitable to convey fundamental computing and programming concepts than others. Some languages also dovetail better than others to a particular course teaching emphasis. A programming subject in a Computer Science course dealing with artificial intelligence, for instance, would probably teach Prolog or Lisp. A course that emphasised Transaction Processing Systems would almost certainly choose to teach Cobol running on a mini or mainframe computer, while a course more concerned with systems integration or user interface issues may choose Visual Basic. Thirdly, choice of a programming language also affects not just those subjects specifically teaching programming, as many other subjects in an IS degree rely on students coming to them with a grasp of certain programming concepts. Although many programming concepts are language independent, the vehicle used for teaching programming does have an effect, particularly when it is based on a different programming paradigm. The teacher of a database subject may want her students to make use of Structured Query Language (SQL) to extract data from a database. As SQL follows a procedural paradigm to some extent, she may expect them to have some understanding of


procedural programming from an earlier study of Pascal or Cobol. Had they instead studied an object-oriented language like Smalltalk, or an event-driven language like Visual Basic, the way she would need to introduce SQL would be quite different. The choice of what programming languages to teach within an Information Systems course is therefore very important. In the late 1980s, RMIT’s Department of Business Information Systems, as it was then known, adopted a programming environment called Pick to introduce programming concepts to its first year students. Shortly after this it also introduced a machine language simulator, known as Alice, to illustrate concepts of low-level programming and machine architecture. The choice of these two programming environments determined what this department considered to be important concepts for its degree students to understand, and defined the nature of Information Systems as seen by RMIT. In 1995 the Department of Business Computing, as it became after a merger between RMIT and Philip Institute of Technology, adopted Visual Basic in an elective called *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ3URJUDPPLQJ, and also in the core programming subject $SSOLFDWLRQV 'HYHORSPHQW�,,. To succeed at RMIT, Visual Basic had to find itself some useful allies who could manage to re-define business programming curriculum to include more than just Pick and Alice. With this assistance, Visual Basic quickly established a firm place for itself in the curriculum. The curriculum changes caused by the introduction of Pick, Alice and Visual Basic can truly be regarded as innovations as academics at RMIT made their own adoption decisions and did not merely follow other universities. What is more, when Visual Basic was adopted at RMIT few other universities had yet made this choice.

Curriculum Innovation: The Research Question This thesis addresses the issue of curriculum innovation by reporting on an investigation into how Visual Basic entered the Information Systems curriculum at RMIT University, and how it has retained its place there despite serious challenge from other programming languages, and the growing importance of object-oriented programming. Visual Basic is now accepted and taken for granted in the Information Systems curriculum. The thesis shows how it came from being a novel, new programming language to an ‘obvious choice’ for use in the RMIT Information Systems curriculum. In exploring and questioning the events and entities that led to this programming language gaining a significant place in the teaching programs of the Department of Business Computing at RMIT, I addressed a number of related issues:

• How was the innovation initiated? Was the source of ideas internal or external to RMIT?

• To what extent was it triggered by the merger between Phillip Institute of Technology (PIT) and RMIT?

• Why was Visual Basic chosen rather than some other programming language? • How did Visual Basic push its way past the other programming languages already

present in the curriculum? • How was the innovation process supported? What negotiations took place? What

human and non-human alliances did RMIT academics build? How did Visual Basic come to be so easily accepted in the curriculum?

• How did the alliances built by the IS academics involved ensure that Visual Basic retained a significant place in the curriculum against other challengers?


One view of curriculum change in higher education is suggested by Wood and Davis:

“... we know that most curriculum change is piecemeal, incremental and unplanned with respect to the total curriculum. For the most part, what students are taught can be almost entirely explained by the size and composition of the faculty. Typically, curricula are built around the expertise and interests of the faculty, and curriculum change is the result of gradually adding new members to teach specific (and often new) courses.” (Wood and Davis 1978 :3)

While accepting that curriculum innovation is necessarily related to the expertise and interests of the academic staff, I will show that the curriculum innovation process in a technological university like RMIT is a great deal more subtle and complex, and involves many more actors than Wood and Davis allow.

The Disciplines Underlying Computing The study of computing and Information Technology in Australian universities is currently divided into three major curriculum areas: Computer Science, Computer Systems Engineering and Information Systems, otherwise known as Business Computing1 (Department of Education Employment and Training, Department of Industry Technology and Commerce et al. 1992). It is thus quite important to establish, at the beginning, where this study is located. Computer Science investigates the fundamentals of computing in areas such as artificial intelligence, formal language theory, algorithms, data structures and compiler construction, and does not usually much concern itself with applications of computing. Within a university, Computer Science is often taught within a Faculty of Science or Engineering. Computer Systems Engineering, which is mainly concerned with such topics as digital electronics, numerical computing, signal analysis, robotics, and control and communications theory, tends to be taught from within a Faculty of Engineering. The Information Systems curriculum document IS’97, recently published in the United States (Davis, Gorgone et al. 1997), sees the academic field of Information Systems as encompassing two broad areas: an Information Systems function consisting of the acquisition, deployment and management of information technology resources; and a services and systems development function involving the building and evolution of infrastructure and systems for information use in organisational processes2. In Australia, Information Systems courses are usually delivered by academic departments based within either Faculties of Science or Business. While there have been some indications of a trend by those departments based within Faculties of Science, or Schools of Information Technology, towards a more theoretical approach to Information Systems curriculum (Maynard 1990), this has not been the case with those in Faculties of Business. A trend that can be observed in some of these Business-based departments is towards Information Management with a concentration on the management aspects of the business use of Information Technology. Most Information Systems courses however, especially those within Faculties of Business, have remained quite practically oriented towards the application of Information Systems to business3 (Juliff 1990), and so are closely related to current business uses of Information Technology.

1 Although the term Information Systems is used throughout this thesis, Information Systems and Business

Computing are generally regarded as being synonymous. 2 See Chapter 2. 3 In universities in the United States, departments of Management Information Systems and Computer

Information Systems also represent two different, but closely related forms of Information Systems.


Principles

Applications

Hardware oriented

People oriented

Computer Systems Engineering

Computer Science

Information Systems

Figure 1.1 Computer Science, Computer Systems Engineering and Information Systems - adapted from DEET (1992 :Fig 2.1)

One useful way that the different computing course types can be differentiated is on the basis of their emphasis on the study of underlying principles versus applications, and on the extent to which they are concerned with investigating the technology itself compared with the human issues revolving around the uses people make of this technology. How each of the major curriculum areas of computing stand in relation to these issues is Figure 1.1 above. Change in Information Systems Curriculum The mission of a university Department of Information Systems is quite clear: it must investigate and teach how businesses, and other organisations, can make the best use of computers and Information Technology (IT) to further their business aims. By its very nature, Information Systems (IS) is an applied discipline and is closely related to the use of information technology in business applications. Courses in Information Systems can be described as:

“... curricula designed primarily to educate students in the efficient and effective application of computer hardware, software and systems to the solution of business and organisational problems.” (Tatnall 1993 :4)

My research question relates to one aspect of IS curriculum: computer programming, which is regarded by most academics as an important part of any Information Systems course (Shackleton 1998). Almost all IS curricula include at least one compulsory programming subject and a number of programming electives. Information Systems courses typically comprise topics such as: an investigation of how and why organisations use computers, systems analysis, process modelling, database theory, data modelling, programming concepts, networks and data communications, information resource management, programming languages, IT project management, change management, systems design, systems implementation, and perhaps computer architecture. But although it is possible to make a list of topics like this that most IS academics would


agree generally covers this field, Information Systems is still undergoing constant, rapid and often quite dramatic change within these topic areas. Of necessity then, an Information Systems curriculum also must undergo frequent changes. Information systems are complex socio-technical entities, and organisations using these systems have had to learn to cope with the rapid technological change that is characteristic of them (Agarwal, Krudys et al. 1997). There is little difficulty obtaining evidence of the rapidity of change in computing as almost every week the media announces some new major development in information technology. From mainframes and mini-computers to micros, from Cobol, Fortran and Pascal to Visual Basic and Java, from conventional keyboards and character-based screens to graphic user interfaces, icons and a mouse, from punch-cards to peer-to-peer networks and the Internet, computer technology has not paused to allow university curricula the luxury to relax and wonder when the rate of change will decrease. More importantly for Information Systems courses, however, the uses that organisations make of information technology have also dramatically changed from a time when only ‘white coated’ members of the Data Processing Section were allowed to touch the expensive machines, to a when that now almost everyone has a PC on their desk or uses some form of computer technology. University Information Systems courses cannot ignore these changes as was pointed out by Cougar et al. in their introduction to the draft Information Systems curriculum report IS’95:

“An industry as innovative and progressive as the computer field needs continuous knowledge and skill updating. Concomitantly, university level Information Systems curriculum needs constant updating to remain viable. Most IS academic units have mechanisms in effect to maintain currency of curriculum.” (Cougar, Davis et al. 1995 :6)

This rapid change has characterised Information Systems curriculum development since its inception (Tatnall 1993) and currently shows no sign of doing otherwise. In a survey of US Information Systems academics conducted in 1992, Gambill and Jackson (1992) found that the vast majority of respondents said that revisions in their IS courses were frequent. They found that because of rapid changes in business requirements for information technology most IS curricula underwent a major revision every three years or less, and that minor revisions in individual courses were “made on a continuous basis” (Gambill and Jackson 1992 :16). Continuous changes in technology mean that IS academics need to spend a considerable amount of time just trying to keep up with what is going on in their field (Longenecker, Feinstein et al. 1994). The cost of this change is high in terms of the financial value of new hardware, software, books, manuals and training, but also in terms of time. Keeping up with these changes: learning a new software package or a new programming language, reading about applications, trying to learn a new systems design methodology or finding out about new hardware, all takes a great deal of time that academics in other disciplines are able to use in other ways (John 1997). The Demand for Information Systems Courses The Information Systems curriculum area has grown over the past twenty-five years from nothing to one of considerable size and importance (Tatnall 1993). A major reason for the growth in importance of Information Systems courses is, not surprisingly, related to the graduate employment market. In the introduction to IS’974, Davis et al. (1997) stress the on-going importance of students studying the discipline of Information Systems. They note

4 Described in detail in Chapter 2.


that the trend in commerce and industry to move Information Systems functions out from the Data Processing Departments into the user community has accelerated and that the demand for IS graduates is forecast to grow very rapidly until at least the year 2005. For example, the forecast increase in annual demand for system analysts up to the year 2005 is over 8% in the United States. Corresponding figures are not readily available for Australia but there is no reason to expect that they would differ much from these.

“... there is no lessening in demand for IS knowledge and ability in organizations; to the contrary, the demand is expanding as the functional areas of the organization gain more capability in IS. Many areas of the organization are now hiring IS majors for departmental computing activities. There is also strong demand for the IS minor by students in other disciplines who need IS expertise in order to be effective in their work and to assist in developing applications in their functional area. A third reason that the demand for IS courses will continue to increase is that students in related disciplines want to acquire basic and intermediate IS skills. Every discipline is experiencing growth in computer use, and students who enrich their IS knowledge are at a career advantage.” (Davis, Gorgone et al. 1997 :vi)

The most recent Australian figures readily available (Department of Employment Education Training and Youth Affairs 1998) suggest that there are currently around 2,300 students enrolled in Information Systems courses in Victorian universities. It is difficult to fix this figure precisely as course names and content vary from university to university but it is somewhere around this number. Information Industries Education and Training Foundation (1992) figures show that in 1990 there were about 1,400 Victorian university students enrolled in computing courses. A reasonable estimate would be that about 75% of these students would have been enrolled in courses of Information Systems, so current figures represents a considerable increase in quite a short time. If you also consider that most MBA (Master of Business Administration) courses, and many other university courses of all types contain a core unit in Management Information Systems (MIS) or something similar, it can be seen just how significant the curriculum area of Information Systems has become in our universities. A glance through university handbooks shows that almost every university in Australian now has a Department of Information Systems or its equivalent.

The Significance of a Study in IS Curriculum Innovation The subject of most reported studies in educational innovation involves curriculum change in primary or secondary schools (Chapter 3), and few studies consider the process of curriculum change in tertiary education. Although there are papers stressing the need for university departments to heed the requirements of industry and commerce and suggestions for how these requirements can be determined, there has been little reported scholarly work concerned with how Information Systems curriculum is made. Despite student demand and business interest in Information Systems curricula, as well as the rapidity of change in Information Systems itself, little academic interest has been shown in Australia or elsewhere in documenting these developments with curriculum studies. Most of the published research is American in origin and concerns itself with the content and pedagogy of Information Systems courses5. In particular, much of the literature involves a discussion of the US model curricula and considers their development and suitability in various applications. The published literature on university Information Systems curriculum development tends to look at this very much from an overall course 5 In this thesis the term course is used in the Australian, rather than in the American sense. It is used in

reference to the complete course of study for a degree, while the term subject is used for a specific unit of study, normally of one semester’s duration. A number of subjects (often twenty-four in a Business degree) then go to make up a complete degree course.


level, considering issues like what sort of subject areas should be included, what equipment is required, the place of cooperative education and how much time should be given to practical work, rather than on the choice of material within specific subjects. A careful investigation of the literature reveals very little research considering the detail of how a selection is made of what specific topics to teach, and how this selection is kept current. Mine is a study of educational innovation that involves an important but small change in the curriculum of one department in a particular university. It is a study of curriculum innovation in Information Systems, which is a new curriculum area and one that is still changing as new technologies, and new uses and roles for these technologies, continue to emerge. It is an area where decisions of which new technologies to incorporate into the curriculum have important implications, particularly for the job prospects of those students undertaking them, and so is an important one to research. I will argue that decisions such as whether to introduce students to computing and computer programming concepts using Pascal, Pick or Visual Basic, or whether to use an object-oriented language, are very important in determining the whole direction of the IS curriculum. I maintain that such decisions have a considerable impact on students’ employability upon graduation, and affect the regard with which business and industry hold the degree course. The published research has not reported on how such decisions are made, and the significance of this study lies in it doing so. While some universities can take the line that catering to industry needs is secondary to their main educational function of exposing students to the important tenets of the discipline, RMIT University has always been most concerned with being seen to be responsive to industry needs in all its courses. Technological universities like RMIT regard choice of subject material that, while relevant in showing the main tenets of the discipline, is also pertinent to industry and commerce, and to student employment prospects, as very important. In summary then, this study is significant because it examines something that has not previously been researched: the negotiations and alliances that allow new material, in this case the programming language Visual Basic, to enter a university curriculum at an individual subject level, and to obtain a durable place there.

Organisation of the Thesis Before commencing this study I was personally acquainted with many of the Information Systems academic staff at RMIT, and was a close friend of Fred; one of the key actors. I can thus make no claim to being a disinterested outside observer, as I had a significant part in the networks I was studying. For this reason, and due to the type of material being considered, the thesis is written in the first person rather than the more traditional third person.

Chapter 1 In this chapter I set out how the thesis reports on an investigation into how Visual Basic entered the Information Systems curriculum at RMIT University, and how it has retained its place there despite serious challenge. I also explained why the research its significant.

Chapter 2 Most of the literature on Information Systems curriculum deals with its content rather than the process of its development. This literature must, nevertheless, be considered in arriving at an understanding of the basis for curriculum innovation in Information Systems. In


Chapter 2, I discuss and analyse the IS curriculum literature as the theoretical underpinning of Information Systems curriculum development.

Chapter 3 This chapter deals with theories of innovation, and I begin with an analysis of the literature on educational innovation, before proceeding to a consideration of innovation diffusion; the model most commonly used for describing innovations.

Chapter 4 Difficulties with essentialist approaches used in innovation diffusion, and much innovation research, are discussed in Chapter 4. I then examine the alternative approach of innovation translation, informed by actor-network theory (ANT), and compare this with innovation diffusion.

Chapter 5 In the research methodology chapter I argue that Information Systems needs to be seen as socio-technical, and that doing so requires a model of analysis that is consistent with this. I discuss how actor-network theory offers a way of considering the social and the technical without privileging one over the other, and how ANT allows the contributions of both human and non-human actors to be given due consideration. In the second part of the chapter I detail how the research was carried out.

Chapters 6 - 9 This set of chapters reports on the development of Visual Basic as an innovation in the Information Systems curriculum at RMIT. Actor-network analysis of the important moments of this process establish the complexity, contingency and negotiated nature of this curriculum change. An outline of the content of these chapters follows in the next section.

Chapter 10 Turning out students able to meet the employment needs of industry and commerce is very significant to a technological university like RMIT. An important recurring issue, raised by many of those involved in designing and teaching the Information Systems curriculum, relates to the relevance of each topic in fulfilling this objective. A question often raised in relation to programming languages at RMIT is: ‘is this a real programming language?’ What the questioner tends to mean by this is: ‘is this a language that is used to a significant extent in business?’ In this chapter I consider some aspects of what it means to be ‘real’ in relation to a curriculum innovation of this type, and explore actor-network notions of ‘mobilising’ the computer industry in this way.

Chapter 11 In the final chapter I report the conclusions of the study.

Outline of the Curriculum Innovation at RMIT This research traces the introduction of Visual Basic (VB) into the Information Systems curriculum at RMIT. It begins when an academic came across Visual Basic in an outside consulting job before the merger of Phillip Institute of Technology with RMIT, and ends with a more object-oriented Visual Basic surviving further change in the curriculum. I have divided the analysis into four parts based on my interrogation of the actors in the study. By clustering the analysis in this way I do not intend an historical account, but one which traces the key sets of negotiations over the period under consideration. The four parts are: Discovery and Exploration (Chapter 6), Prior Claimants (Chapter 7), The Merger (Chapter 8), and Surviving an Object-Oriented Challenge (Chapter 9). To assist the reader I have


next provided a brief summary of the main events in the adoption and maintenance of VB in the RMIT Information Systems curriculum. Discovery and Exploration In 1992, Phillip Institute of Technology (PIT), situated in Melbourne’s northern suburbs, merged with the city-based RMIT to form RMIT University. This study begins in 1989 at PIT before the merger, when Fred was appointed to the academic staff of the Department of Accounting and Electronic Data Processing6. In its Information Systems curriculum Phillip Institute was very much a typical College of Advanced Education (CAE)7 and it sought to ensure that its curriculum related well to what it perceived as the needs of the business community it represented in the northern suburbs of Melbourne. As its Information Systems degree was an applied course oriented largely towards turning out business programmers, many of its subjects had a programming flavour. Programming was taught through use of the programming languages Pascal, dBase and Cobol. Shortly after Fred’s arrival, and largely because of Fred’s energy and enthusiasm, several new programming subjects were developed. Late in 1992 Fred was involved in an outside programming job with his son George that involved using Microsoft QuickBasic in an MS-DOS environment. Aspects of the job required displaying graphics and different fonts on the computer screen. Displaying anything other than standard text, however, presented difficulties when programming in an MS-DOS environment as each type and resolution of computer screen required a different DOS screen-driver. George remembered seeing a review in a computer magazine of a new Microsoft product called Visual Basic for MS-DOS that had a single set of screen-drivers that worked as calling routines from the operating system and so should work with any MS-DOS screen. George had previously come across Visual Basic for Windows, which had been released the year before, but had not made much use of it. Visual Basic for MS-DOS solved the graphics programming problem, and the consulting job was completed successfully. Fred, who had never before really taken to the use of Windows and graphical environments, discovered that he began to really like Visual Basic and the different type of programming style it represented. He liked the fact that VB allowed the programmer to put a useful program together in a short time and that the program had a good professional look to it. He quickly became convinced that he should introduce VB to his students at PIT. He did this by exploring and experimenting with VB in several existing subjects. He tried out VB as a screen prototyping tool in an introductory core subject, then used it to explore the Windows operating system in an operating systems elective. After ‘playing around’ with Visual Basic for several semesters Fred formally implemented VB into two subjects in the form of assignments and exam questions. A merger between PIT and RMIT was announced during 1992 with complete integration of the two institutions to be implemented over several years. This meant an end to further curriculum development at PIT but did not prevent Fred from continuing his experimentation with Visual Basic. Prior Claimants Computing at RMIT had begun in the 1960s, but early courses were in Computer Science with a Department of Business Information Systems not being created in its own right until

6 It was later renamed the ‘Department of Accounting and Business Computing’. 7 See Appendix A.


the mid 1980s. As a latecomer to the area, the new department decided not to take on other tertiary institutions in turning out Cobol programmers but to go for a niche market catering to an ‘intelligent user’ approach. Their curricula were thus initially much more general and less oriented towards programming than the course at Phillip Institute. In the late 1980s Stephen, an RMIT Business Information Systems lecturer, came across the database-oriented operating system Pick while working on an outside consulting job. With very few resources and only a small amount of documentation available to help him Stephen set out to grasp an understanding of Pick. It did not take long before he had convinced himself that Pick, and its programming language Pick/BASIC, would be worth trying to include in the subjects he taught at RMIT. In the same way that Fred later did at PIT, Stephen experimented using Pick/BASIC in a programming subject and found that the students took to it quickly. The inclusion of Pick into two programming subjects was formalised in 1990. The use of Pick was seen to fit the idea of providing students with jobs in a niche market, and by the time of the merger it had become the department’s main vehicle for introducing students to programming. Also in the mid 1980s, James developed an introductory subject in computer architecture and operating systems for the Information Systems degree. To help show how the machine worked and to make the teaching of assembly language more concrete he decided to build a software ‘computer simulator’. The idea was that when using this ‘virtual machine’ the students would be better able to understand what goes on inside a computer. James built a series of simulators named Snark, Jubjub, Boojum and Alice, based on his assessment of what Information Systems students needed to understand about the internal operations of a computer. It was generally acknowledged that the simulators did this very well, but there was always some concern over how much an ‘intelligent user’ needed to know about this topic. Nevertheless, Alice was in use in the core computing subject at the time of the merger. Although taught over a number of years at RMIT, Cobol had no strong supporters. There was a general view that Cobol was ‘old hat’ and somewhat past history, and it was not very popular with the students. Cobol plays little part in this story. The Merger In mid-1992 the merger came into effect, but it was not until the following year that things affecting the two Information Systems departments started to happen. In relation to Information Systems one of the objectives of the merger was to produce a single Information Systems department with a single degree course. This course was originally to be offered at both the City and Coburg campuses before the decision was taken by RMIT to close the Coburg campus and move all its Business degree programs to the City. To facilitate the design and implementation of the new (combined) degree the Department of Business Computing, as it was now called, set up an ‘Undergraduate Course Review Panel’ to propose a new course structure and subjects for discussion by the Course Advisory Committee and departmental teaching staff. In doing its research for the review the panel considered the opinions of students, suggestions from academic staff, industry surveys, DPMA and ACM8 model curriculum documents, similar courses in other universities and computer industry input.

8 The Data Processing Management Association (DPMA) and Association for Computing Machinery (ACM)

are US-based international Information Technology professional associations. Neither of the more recent


The curriculum review process proceeded over the next two years to the stage when the new degree was accredited. While this was going on, however, it was still possible to propose new electives as long as it seemed that they would fit into the new degree structure. Fred used this opportunity to propose a new elective called *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ3URJUDPPLQJ that was based on the use of Visual Basic. The new elective was first offered at the Coburg campus in second semester 1995. This was RMIT’s first subject designed with the express purpose of teaching and using Visual Basic. The success of this subject was closely monitored, for different reasons, by a number of academic staff. Some saw VB as an exciting new development, while others were concerned that Visual Basic might represent a challenge to their existing subjects. In late 1995, the Department of Business Computing applied to both the university and the Australian Computer Society (ACS) for accreditation of the new degree. Although there was no requirement by RMIT for its courses to be accredited by professional associations, the university was keen to be seen as catering to the needs of industry and commerce and so encouraged this step. In addition, ACS accreditation was seen to enhance the job prospects of its graduates. The accreditation process checks on available computer resources and the qualifications of the teaching staff, and also to see if the new course appears to covers the sort of things that most Information Systems courses do. To verify this the course is compared with various standard curriculum models. The Course Review Panel had deliberately avoided specifying programming languages in any of the four new programming subjects proposed for the core; this implementation decision was to be made closer to the time each subject was first delivered. Despite this policy decision there was tacit agreement that the first two subjects would probably use Pick/BASIC, a matter on which there was less than complete support among the academic staff. Pick, nevertheless, was in a sufficiently entrenched position to survive the merger and when these two subjects were finally offered they did indeed use Pick/BASIC. Although the course descriptions indicated that these first subjects would use a procedural language the third subject, $SSOLFDWLRQV 'HYHORSPHQW�,,, was intended to explore other aspects of programming and the language chosen was Visual Basic. In its adoption in this core subject Visual Basic had gained a most significant place in the curriculum. Alice, however, was not so fortunate. When it was first introduced in the late 1980s there was little question that the internal workings of a computer was something of which all Information Systems students should have a significant understanding. Times change and by the time of the course review discussions during the merger, this assumption was being questioned. While it was agreed that some understanding of computer architecture and assembly language was useful, incorporating this in a compulsory subject was not supported and Alice lost its place in the curriculum. By early 1996, after the time the merger was complete, Visual Basic had found a place in two Information Systems subjects, $SSOLFDWLRQV 'HYHORSPHQW�,, and *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ3URJUDPPLQJ. Whether its place in the curriculum would become durable remained to be seen.

curriculum models - IS’95 and IS’97 - were available in time for consideration by this panel. Model curricula are further discussed in Chapter 2.


Surviving an Object-Oriented Challenge Debate on programming languages did not stop after the new course was accredited, but increasingly the debate turned towards the value of introducing object-oriented (OO) programming into the degree. As time went on it became a question not of whether to introduce OO programming, but where to place it. In 1997 the fourth programming subject, 6\VWHPV ,PSOHPHQWDWLRQ�,,, had not yet run due to the cooperative education year intervening. This seemed like a good place to introduce object-oriented concepts and any idea of beginning with OO programming in place of Pick/BASIC was soon discarded. The next question was which OO language to use. Despite not being fully object-oriented, Visual Basic was briefly considered for both the last two subjects. This proposal did not proceed for two reasons. Firstly, although version 5.0 of Visual Basic (VB5) is close to fully object-oriented, Visual Basic was not seen by most people as an OO language. Secondly, there was a view that with only Pick/BASIC and Visual Basic in the course the choice of language might be seen as too narrow. Java was the language chosen for this subject. If the final programming subject was to use an object-oriented language a question then arose as to whether VB was still appropriate in the preceding subject which would now need to introduce object concepts. At this point VB5’s object-oriented features saved the day for Visual Basic and it was decided to keep it in place here. Another problem now, however, arose in the teaching of Visual Basic in both $SSOLFDWLRQV'HYHORSPHQW�,, and *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ. The difficulty was in differentiating what should be taught in each subject given that one subject was an elective, and students who did both subjects could take them in any order. Part of the solution lay in making $SSOLFDWLRQV 'HYHORSPHQW�,, tackle VB from an object-oriented perspective, but this alone was not enough. The other part of the solution was to change *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ to a subject teaching VB to non-programmers. This was to be done by making extensive use of the property settings of VB’s in-built controls rather than using programming code. The changes were accepted and Visual Basic gained an ongoing place in RMIT’s Information Systems curriculum for the foreseeable future.

IS Curriculum as Negotiation and Compromise In this chapter I have described my research question and shown why the research is significant. My topic is located within Information Systems, one of the disciplines underlying computing, and involves research in Information Systems, education and innovation. I have described the organisation of the thesis and provided a brief outline of the progress of the innovation under consideration. The thesis is an investigation of an IS curriculum innovation in an Australian university of technology. My research clearly demonstrates that the process of curriculum innovation is a complex one that arises from a series of negotiations and compromises between both human and non-human actors. It shows that it is impossible to see at the outset where the innovation will lead. As Franklin argues:

“It should be evident by now that there is no such thing as ‘just introducing’ a new gadget to do one particular task. It is foolish to assume that everything else in such a situation will remain the same; all things change when one thing changes.” (Franklin 1990 :102-103)


Chapter 2

Information Systems Curriculum A review of the literature dealing with the content

and development of IS curriculum

Computer programming typically occupies an important place in computing courses, and issues concerned with the choice of appropriate programming languages for particular types of course are significant. The stress that is put upon programming, and the languages used, differ between curricula in the disciplines of Computer Science, Information Systems and Computer Systems Engineering. This chapter reviews literature dealing with the discipline of Information Systems and with IS curriculum, as a consideration of this is necessary to see how and where programming fits in the curriculum. The chapter points to model IS curricula, most of which emanate from the USA, as an important determinant on what is taught in an Australian IS course, particularly if the course aims to gain professional society accreditation9. Literature is described on what these model curricula contain, and the constraints and influences they and other things place upon the curriculum design process. More specifically, the chapter investigates literature dealing with the place of programming in IS courses and the influences that promote the use of one programming language in preference to another. Electronic computers have been in existence now for a little over 50 years, with university courses relating to computing beginning in Australia in 1947 (Pearcey 1988). A search of library sources and on-line databases shows however, that it was only with the advent of the microcomputer in the late 1970s and early 1980s that a significant body of literature on computing curriculum began to appear. This late start is not surprising as in the pre-microcomputer era few computers were used in schools, and it is with school education that most such papers are concerned. Today, the field of Computers and Education in primary and secondary schools boasts a considerable international literature, but this is less true of university-level Information Systems curriculum. Given the size and importance of Information Systems it is somewhat surprising to find very little reported research that deals with the processes involved in the formation of curriculum in this area. The bulk of the recent literature on university computing curricula is American in origin and concerns itself largely with the development and content of the curriculum models proposed by the major professional societies involved with computing in the USA. These model curricula are important as they provide a framework, and act to set a limit on the range of what can legitimately be taught in an Information Systems course. Their influence also extends to this country and it would be a ‘courageous’ (Lynn and Jay 1984) Information Systems department that ignored these curriculum models when planning their courses. When it comes to an investigation of the curriculum innovation involved in adopting a new programming environment like Visual Basic several aspects of the literature are relevant. An important issue is the place occupied by computer programming in Information Systems courses. The question is sometimes asked, usually by Computer Science academics, whether computer programming is something that should be taught in Information Systems courses at all, or only by Computer Science departments. Few IS academics accept the view 9 See later in this chapter, and also Chapter 8.


that programming is not part of their discipline, but a question remains on the sort of programming that should be taught: which languages are relevant, how much of a course should be devoted to teaching programming, and to what level of complexity it should be taught. The literature relating to model curricula, along with other more specific papers, can be of assistance in shedding light on how these questions have been answered, theorised and understood by those developing curricula. The model curriculum documents provide contemporary interpretations of the Information Systems discipline and are important factors in determining what topics are taught in an Information Systems course in Australia. This chapter provides an analysis of the current state of Information Systems curriculum literature as a necessary basis for locating the research reported in the thesis. It examines literature relating to the following areas of interest:

• Attempts at shaping the discipline of Information Systems, as distinct from Computer Science, including Australian moves to define an Information Systems ‘Body of Knowledge’.

• Papers dealing with model curricula from the USA and elsewhere. These typically address a definition of the Information Systems discipline, describe how the curriculum model in question was developed, outline its contents, and suggest approaches and resources needs for its delivery. There is evidence in this literature (Fabbri and Mann 1993; Bonnici and Warkentin 1995) of the political nature of this process with a degree of rivalry apparent between the professional associations that developed the different curriculum models.

• The Information Systems curriculum development process and papers concerned with related topics such as the place of technical issues versus interpersonal skills, and industry input to course design.

• The place of programming in Information Systems courses. Questions of how course content is selected are also informed by literature on innovation in general and curriculum innovation in particular. In relation to my research question however, there is little literature explicitly concerned with IS curriculum innovation and so I have drawn on that dealing with innovation in general. This is dealt with in the next chapter.

The Discipline of Information Systems Attempts by Computer Science, Computer Systems Engineering and Information Systems towards establishing themselves as distinct formal discipline areas has had a considerable effect on computing curriculum in past years, and continues to do so today. In examining how this has happened it is useful to draw on the work of Layton (1972), who proposed a three-stage model to explain the evolution of school subjects in nineteenth century England. While Layton was speaking of the slow evolution of school subjects, if I may paraphrase him slightly to reduce this emphasis his argument could be stated as follows. Firstly, on entering the curriculum a new subject justifies its existence on grounds of “pertinence and utility” (Layton 1972 :10). Then, as a tradition of scholarship begins to build up it moves its ground in search of greater rigour and “growing academic status” (Layton 1972 :10). Finally, specialist scholars and professional societies, with “established rules and values” (Layton 1972 :10), gain the right to determine the selection of subject matter. During much of its past history the content of Information Systems curriculum has certainly been formed on grounds of pertinence and utility (Tatnall 1993). Prior to the 1980s, these courses typically aimed to turn out business programmers and so emphasised systems


analysis and programming, usually in Cobol. Before Layton’s second stage could be achieved, however, a change in technology, in government policy, or in business requirements caused a reinterpretation of what had to be taught that resulted in a return to the first stage (Tatnall 1993). This meant that during the period from 1960-1985, IS curriculum innovation in Australia repeatedly re-covered the same ground, but using different technology and with modified goals. This meant that there was little chance to get away from the strictly applied emphasis of these courses. In recent years, despite continued rapid changes in technology, the revolutionary change in Information Systems curriculum appears to have slowed a little and there is evidence in many universities of a search for greater rigour and academic status in the new discipline - Layton’s second stage (Tatnall 1994). The recent publication of a ‘Core Body of Knowledge’ by the Australian Computer Society10 (ACS 1997) shows that there has been some recent progress in the involvement of professional societies - Layton’s third stage. The question of whether Computer Science should be considered to be a branch of science, a branch of engineering, or whether it was something else entirely unique, was discussed at length in the 1970s and ‘80s until a consensus began to emerge. In the late 1980s Hopcroft (1987) wrote that Computer Science was just beginning an attempt to establish itself as a discipline when he began his career in 1964. He describes how, in the 1960s, changes in electronics technology allowed Computer Science to broaden its scope from considerations of circuit theory into computation, and that by 1987 there were signs that Computer Science was interesting itself much more in application areas. Two years later Gries, Walker and Young (1989) were able to say that there appeared to be general agreement that the various disciplines of computing had matured and come into balance. Denning et al. contended that the fundamental question underlying all of computing was: “what things can efficiently be automated?” (Denning, Comer et al. 1989 :12), and proceeded to the following definition:

“The discipline of computing is the systematic study of algorithmic processes that describe and transform information: their theory, analysis, design, efficiency, implementation and application.” (Denning, Comer et al. 1989 :12)

In a rather philosophical discussion of the discipline of Management Information Systems (MIS)11, Banville and Laudry (1989) consider what constitutes an academic discipline and whether Information Systems was a science. They observe that:

“MIS is a fragmented field, or to put it in other words, an essentially pluralistic scientific field, especially in view of its vocational character.” (Banville and Landry 1989 :58)

They further build their argument by offering Astley’s (1985) contention that:

“Any scientific field is a perpetual and continuous social construction that can be influenced with the proper tools.” (Banville and Landry 1989 :58)

Even if Computer Science is to be considered in a manner similar to that of a physical science, current debate is not clear on whether Information Systems is also of this nature. The tendency seems to be towards the view that it is not, and many writers would now argue that Information Systems relates more closely to organisational theory and to management than to ‘pure’ science (Nunamaker 1981). In the United States, during the 1980s in particular, the Data Processing Management Association (DPMA)12, the Association for Computing Machinery (ACM), and the Computer Society of the Institution of Electrical and Electronic Engineers (IEEE-CS) all published papers and documents

10 Discussed later in this chapter. 11 In many contexts, the terms MIS and Management Information Systems are often use synonymously with

IS and Information Systems. 12 Now called the Association for Information Technology Professionals (AITP).


discussing these issues and giving curriculum guidelines for courses of various types in Computer Science and in Information Systems (Carlson 1966; Fein 1967; Nunamaker 1981; 1982; Denning, Comer et al. 1989; Denning 1989; Gries, Walker et al. 1989; Longenecker and Feinstein 1990). Cougar et al. (1995) note that the academic study of Information Systems began in the 1960s when organisations first began to make use of computers for information processing. Comparing Computer Science and Information Systems they hold that:

“Information systems concentrates on relating IS activities to the company’s organizational objectives and secondarily to technical objectives. The context of information systems is an organization and its systems. This is contrasted with computer science where the context is algorithms and system software.” (Cougar, Davis et al. 1995 :9)

In 1984, Vogel and Wetherbe (1984) concluded that MIS research in the USA was emerging as an eclectic and diverse body of literature, but noted that variations in research methodology created problems in comparison of relative merit. Five years later Jackson and Nath (1989) remarked on the shift in information systems research from non-empirical to empirical investigations13. In what appears to have been intended as a criticism of the field of Information Systems, Fabbri and Mann (1993) noted that a recent survey of IS literature (McBride and Rademacher 1992) had shown that 53% of IS research papers were still based on subjective/ argumentative analyses and a further 17% on surveys, suggesting that “the discipline remains in its adolescence” (Fabbri and Mann 1993 :77). In addition to Computer Science, Computer Systems Engineering and Information Systems, the disciplines underlying computing discussed in Chapter 1, a number of writers also add Software Engineering (Purvis 1996; Bagert 1998). As its name suggests, Software Engineering is concerned with building computer software systems, and Shaw (1990) argues that it needs to become a discipline more like other traditional engineering areas. The similarities and differences between Computer Science (CS), Software Engineering (SE) and Information Systems (IS) curricula are set out in Figure 2.1 below (Glass 1992). Taken together these fields cover most of the academic material relating to the use of computers and the creation of software to solve problems, but each is plagued with uncertainties about its identity and validity (Glass 1992). Glass poses several questions: is the content covered by each of these fields relatively separable? Are there any undue overlaps? Do gaps exist in the coverage of computing topics? and, should CS, SE and IS curricula be revised to provide a more comprehensive and cohesive coverage of the overall field? Glass (1992) remarks that Computer Science emphasises cause - how the device operates, while Information Systems emphasises effect - what the device enables, and illustrates the coverage provided by each of these areas as follows:

13 Information Systems research is further discussed in Chapter 5.


Computer Science Software engineering Information systems Complete coverage computing hardware,

life cycle concepts methods life cycle concepts management

Strong coverage theory system concepts, solution approaches

Some coverage solution approaches methods, system concepts, solution approaches, management

life cycle concepts, methods, theory, computing hardware, system usage

Little or no coverage

management, system concepts, system usage

theory, computing hardware, system usage

Figure 2.1 Comparison of the coverage of IS, SE and CS curricula - adapted from Glass (1992)

A recent Australian survey (Keen 1996) has shown that there are twenty Information Systems departments in Australian universities, twelve of which operate from within faculties of Business/Commerce, six from faculties of Science and two from faculties of Information Technology. Keen (1996) notes that there are a total of sixty-five IS groups within Australian universities, the other forty-five of which do not have departmental status and often form sub-groups of Computer Science departments. Taken as a whole, 48% of IS academics work from within faculties of Business with the next largest group being in Science with 32% of IS academics based there. Information Systems thus has only recently begun to approach the question of its disciplinary status and still has some way to go. Uncertainty often characterises the boundaries of new, fast growing curriculum areas (Gries, Walker et al. 1989), and the curriculum boundaries of Information Systems are still being negotiated and resolved. In the study of a curriculum area like computer programming that is taught in each of the underlying disciplines, investigation of disciplinary boundaries is especially important. Recent curriculum efforts by the Australian Computer Society (Layton’s third stage) represent one attempt at resolution of the content of computing courses, but do not address the boundary issues. An Information Systems Body of Knowledge The Australian Computer Society (ACS) has recently published a document setting out what it regards as the Body of Knowledge required of a computer professional (ACS 1997). This core Body of Knowledge has been expressed in a form intended to assist university computing departments - both Computer Science and Information Systems, with the development of their curricula. The intention is that it will then be used in determining the eligibility of these courses for ACS professional accreditation. In its core Body of Knowledge the ACS sets out fourteen topic areas, three of which it regards as any essential part of any computing course. It has indicated that to receive ACS accreditation a course must give ‘due regard’ to the three mandatory knowledge areas, as well as to an ‘appropriate number’ of other knowledge areas, depending on the type of course.


Areas of knowledge mandatory to all IT courses Other useful areas of knowledge Interpersonal communications Computer organisation and architecture Ethics, social implications, professional practice Conceptual modelling Project management and quality assurance Database management Data communications and networks Data structures and algorithms Discrete mathematics Systems software Program design and implementation Security Software engineering and methodologies Systems analysis and design

Figure 2.2 Areas of Knowledge (ACS) Even though there is no requirement for a university department of Information Systems or Computer Science to take any notice of the curriculum recommendations of professional bodies like the ACS, in most cases their views are given careful consideration. Many universities (including RMIT and Victoria University) apply to the ACS for accreditation of their computing courses partly to increase the status of these courses, but also in an attempt to enhance the job prospects of their graduates14. In the accreditation process the course being considered is compared with various standard curriculum models. The ACS has not, until recently, made any attempt at defining its own model curriculum preferring to make use, for comparison purposes, of those developed in the USA15. The Information Systems department preparing to have its course accredited must then set out where its course is similar, and how it differs, from these curriculum models. Given their use in course accreditation it is important now to have a close look at how the various IS curriculum models are set out, what they contain, the importance they place on programming, and how they have been developed.

Model Computing Curricula from the United States In May 1995 in the United States, a joint curriculum task force representing the Data Processing Management Association (DPMA)16, the Association for Computing Machinery (ACM) and the Association for Information Systems (AIS) published the draft report Information Systems IS’95: Model Curriculum and Guidelines for Undergraduate Degree Programs (Cougar, Davis et al. 1995). For a number of years the various professional associations concerned with computing in the United States have been in the business of producing model curricula for university and school programs. A model curriculum for Computer Science was first published in the US by the ACM in 1968, and revised ten years later (Longenecker, Feinstein et al. 1994). Development of model curricula for Information Systems courses began soon after with the publication, in May 1972, of ACM Graduate Professional Programs in Information Systems (Longenecker, Feinstein et al. 1994). Since that time there have been regular curriculum updates from both the ACM and DPMA (AITP) and it is interesting to note some apparent early rivalry between these professional societies. The full chronology of

14 RMIT’s degree accreditation is described in Chapter 8. 15 This is, however, likely to change now that the ACS has published its own core Body of Knowledge. 16 The Data Processing Management Association (DPMA) had been describes as a ‘management-focused’

practitioner organisation (Glass 1992). In 1996, the DPMA changed its name to the Association for Information Technology Professionals (AITP) and hence it should be noted that all references in this study to either the DPMA or the AITP are references to the same organisation.


these model curricula up to 1995 is given by Longenecker et al. (1994), but to bring this list up to date (Figure 2.3 below) it is necessary now to add a reference to the latest model: IS’97. May 1972 ACM Graduate Professional Programs in Information Systems December 1973 ACM Undergraduate Programs in Information Systems March 1981 ACM Educational Programs and Information Systems 1981 DPMA Curriculum for Undergraduate Information Systems Education 1982/3 ACM Information Systems Curriculum Recommendations for the 80s:

Undergraduate and Graduate Programs October 1984 DPMA Secondary Curriculum on Information Technology and Computer

Information Systems October 1985 DPMA Associate-Level Model Curriculum in Computer Information Systems October 1985 DPMA Model Curriculum for Undergraduate Computer Information Systems October 1989 ACM unofficial, unpublished updated version of ACM 1983 May 1990 ACM/IEEE-CS Computing Curriculum in Computer Science for

Undergraduates October 1990 DPMA IS’90 Information Systems Curriculum, draft document June 1991 DPMA IS’90 Curriculum for Undergraduate Programs in Information Systems June 1991 ACM/IEEE-CS CS’91 Computer Science Curriculum January 1994 DPMA IS’94 Curriculum for Two-Year Programs in Information Systems January 1994 ACM Curriculum for Two-Year Programs in Computer Information Systems December 1994 May 1997

IS’95 draft Information Systems Curriculum from a joint ACM, AIS/ICIS, DPMA task force

IS’97 Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems – a collaborative effort from ACM, AIS and AITP.

Figure 2.3 Chronology of Model Curriculum documents from the USA Nunamaker et al. (1982) also note that in addition to the professional societies mentioned above both the Computer Society of the Institute of Electrical and Electronic Engineers (IEEE-CS) and the International Federation of Information Processing (IFIP) have also shown an interest in publishing computing curricula. ACM: Information Systems Curriculum Recommendations for the ‘80s The earliest model curriculum to be of any interest to current researchers on Information Systems curricula in Australia is described in the report Information Systems Curriculum Recommendations for the 80s: Undergraduate and Graduate Programs, written in the early 1980s by the ACM’s Curriculum Committee on Information Systems (Nunamaker, Daniel et al. 1982). In a prelude to the release of their report Nunamaker (1981) describes the process by which the new curriculum was researched and designed. He describes how in determining the status of educational programs in Information Systems the ACM conducted a survey in the late 1970s of Schools of Business Administration, Departments of Computer Science, Engineering Colleges and other educational institutions offering Information Systems courses. Nunamaker (1981) categorises IS programs into two main groups: those designed to introduce computers to the general management student, and those designed for students intending to move into a career in Information Systems. IS being a fairly new term, the report describes the components of an Information System, noting that:


“An IS integrates systems analysis, statistics, management, management science, accounting, economics, finance, marketing, production, and computer and communications technology to accomplish these tasks. In this respect, IS is the embodiment of the so-called ‘systems approach’.” (Nunamaker 1981 :125)

Regarding IS courses, Nunamaker argues the need for degree programs which provide both technical and organisational knowledge, combining material from the disciplines of Computer Science and Management. He notes that Computer Science programs typically emphasise hardware and software technical knowledge but leave out any mention of management or organisations. He goes on to point out that the survey showed that there was very little commonality in what was then taught in IS courses, and that much of what was included appeared to have been put together on an ad hoc basic. Content varied from a “gee whiz” overview to a “nitty-gritty, nuts and bolts” approach (Nunamaker 1981 :125). Details of the curriculum model itself, published in late 1982 (Nunamaker, Daniel et al. 1982), begin with the statement that the need for a model IS curriculum was currently greater than it was when first outlined by an ACM committee ten years previously. Curriculum revision was necessary because of considerable:

“… changes in the importance of information systems, advances in technology, improvements in information systems analysis and development processes, and an increased need for information systems management skills.” (Nunamaker, Daniel et al. 1982 :783)

Nunamaker et al. note that an IS graduate needs, in addition to technical knowledge, to understand organisations, organisational processes and organisational functions. They remark that a person implementing an information system is thus both a “boundary spanner” and a “change agent” (Nunamaker, Daniel et al. 1982 :784), and that an IS curriculum should take this into account. DPMA: Information Systems - IS’90 In the preface to the document defining the DPMA Model Curriculum for a Four Year Undergraduate Degree the authors (Longenecker and Feinstein 1990) state that their purpose is to provide a framework for the implementation of Information Systems programs. They acknowledge that IS curricula have always reflected dynamic change due to the rapid development of information technology and hence need to be revised frequently. These revisions have, they contend, been driven by technology and have often resulted in the addition of new subject areas rather than synthesis of this material into the “basic tenets of the discipline” (Longenecker and Feinstein 1990 :7). In summarising the need for an updated curriculum they offer the following: • Significant advances are constantly being made in both hardware and software

technologies. • Information Systems continue to grow in importance in all organisations. • The role of the IS professional continues to grow in importance. • IS is much more than just programming and also requires the practical application of

systems analysis and design methodologies to organisational problems. They claim that their IS’90 curriculum has been designed to be flexible and so applicable to a variety of different settings, providing a number of alternative paths through “a dynamic body of knowledge”. They note that its development methodology:

“... specifies a detailed body of knowledge mapped into knowledge clusters by depth of understanding.” (Longenecker and Feinstein 1990 :7)


This mapping is intended to form the basis for a set of required, supporting and elective subjects. Emphasis in the model is placed on systems theory, user requirement-based problem solving and software engineering. Students progress from working on the development of small systems right up to those at enterprise level. As well as imparting technical knowledge and skills the curriculum also aims to produce graduates who can communicate effectively, be confident in their ability as professionals, and be able to continue to learn and update their skills constantly. They should also appreciate the ethical, legal and social responsibilities which result from the key role IS plays in our society (Longenecker and Feinstein 1990). The development methodology for the IS’90 model curriculum involved the following steps: • A survey of undergraduate Information Systems programs in the US and Canada. • Development of seven ‘knowledge clusters’. • Definition of the IS body of knowledge into knowledge units. • Definition of the depth of understanding, or competency level, expected of students

from each knowledge unit. The competency levels were based on those in Bloom’s Taxonomy (Bloom, Englehart et al. 1956).

• Mapping of knowledge units onto knowledge clusters to produce subjects. • Assignment of lecture and laboratory times to the knowledge units in each cluster. ACM / IEEE-CS: Computer Science Curricula, 1991 Although dealing with Computer Science curricula and specifically excluding Information Systems, the CS’91 report still has relevance to this study as a point of comparison with IS’90. In discussing the need for an updated curriculum Turner and Tucker remark that:

“One problem was that while many programs had sprung up in response to local demand, the implementors did not have a good feel for the discipline and the programs were too narrow, often lacking depth as well as breadth.” (Turner and Tucker 1991 :69)

The report outlines nine constituent subject areas and three processes that the authors say define the curriculum. The subject areas relate to Computer Science, but for Information Systems courses the processes: theory, abstraction and design are still of interest. The authors argue that in computing, theory is similar to that found in mathematics, abstraction is rooted in the experimental sciences and design is related to engineering.

“Because computing is simultaneously a mathematical, scientific and engineering discipline, different practitioners in each of the nine subject areas employ different working methodologies or processes during the course of their research, development and applications work.” (Turner and Tucker 1991 :73)

In relation to curriculum design, Turner and Tucker (1991) contend that a curriculum depends on a number of factors including the purpose of the program, strengths of the faculty, the background and goals of the students, institutional and infrastructure support, and accreditation criteria. They recommend that curriculum design should be guided by the following principles: • The purpose of a curriculum is to educate students and this should drive its design. • Unified ideas and goals should span the whole curriculum. • A variety of student learning modes, including laboratory sessions, should be

considered. • Environmental constraints should not be ignored.


• Computing is “a dynamic vital discipline that offers many challenges and interesting problems, exciting results and imaginative applications” (Turner and Tucker 1991 :82) and the curriculum should try to impart this sense of excitement to students.

They note that all curricula should be evaluated periodically but contend that this is particularly important in computing curricula because of their dynamic nature.

“Another concern in computing curricula comes from the fluid nature of theory in the discipline. As computing is based on artefacts in addition to physical laws, many of its ‘fundamentals’ are subject to constant reinterpretation and re-evaluation.” (Turner and Tucker 1991 :82)

Comparisons and Criticisms of ACM and DPMA Curriculum Models As one would expect, the publication of new model curricula typically produces some controversy, and the publication of IS’90 and Computer Science 1991 were no exception. The problem of different approaches to the emerging discipline of Information Systems becomes particularly clear when the views of members of different professional societies who come from quite different academic backgrounds are examined. Much of the debate between the two curricula seems to centre on the business content of Information Systems courses and its absence in Computer Science. The fact that there were two different models at all upset a number of people, and Fabbri and Mann (1993) remark on “the unsatisfactory situation” due to “the growing divergence between the curriculum models of the DPMA and ACM” (Fabbri and Mann 1993 :77). Perceptions of the differences between Computer Science and Information Systems graduates also caused some concern.

“Managers complain about the college preparation of entry-level personnel. Computer science graduates are stigmatized as hackers who want to automate everything without regard to the bottom line, and information systems graduates lack the technical foundation to assimilate rapid technological change.” (Fabbri and Mann 1993 :77)

Fabbri and Mann comment that:

“A fundamental premise of the ACM model is that ‘computing is simultaneously a mathematical, scientific and engineering discipline …’. Paradigms such as theory, abstraction, and design which are central to those disciplines must permeate the curriculum.” (Fabbri and Mann 1993 :78)

They go on to remark that:

“Mastery of a significant amount of these paradigms greatly enhances the ability of the graduate to remain abreast of rapid developments within the field.” (Fabbri and Mann 1993 :78)

Bonnici and Warkentin (1995) however question whether Fabbri and Mann really acknowledge the differences between the disciplines of Information Systems and Computer Science, and that Information Systems graduates need a good understanding of business perspectives and skills. They argue that these can best be obtained from common core business programs.

“This consensus from curriculum experts is validated by numerous studies which indicate that employers also prize general knowledge of financial systems, accounting practices, market research, inventory analysis, operations management, business forecasting, strategic management, and other fundamental business components in their IS professional staff.” (Bonnici and Warkentin 1995 :96)


Evidence is presented that employers need graduates able to bridge the gap between business and technology (Rifkin 1987) and Bonnici and Warkentin use this in their support of the DPMA model. They also quote Wiersba (1991) who argues that rather than withdrawing Information Systems from the School of Business:

“MIS departments must work more closely with the other departments in the business schools to assist them in … adopting information technologies as management decision making and forecasting tools.” (Wiersba in Bonnici and Warkentin (1995 :96))

Fabbri and Mann contend that higher education is failing to produce IS professionals:

“... who are prepared to meet the challenges of complex integrated systems development and rapid technological change in an efficient and cost effective manner.” (Fabbri and Mann 1993 :79)

This, they argue, has a lot to do with Information Systems courses typically being offered by Schools of Business. They contend that this is not really appropriate as Information Systems concepts apply to all problem domains from “business to education to science to engineering” (Fabbri and Mann 1993 :79) and call for the adoption of an ‘Information Engineering’ approach to IS curricula.

“Like engineering its paradigm is analysis, design and cost effective implementation of a product that is useful. Like engineering, it is grounded in mathematics and science. Like engineering its advancement as a discipline relies on experimentation and the clever utilization of advances in science and mathematics.” (Fabbri and Mann 1993 :79)

Far from falling short in preparing students for complex problem solving as Fabbri and Mann claim, Bonnici and Warkentin (1995) hold that effective problem solving requires a well-honed understanding of the problem and that the DPMA curriculum allows students to develop a much better knowledge of business systems than that possessed by Computer Science graduates. In answer to the criticism that IS curricula should contain more academic topics Bonnici and Warkentin reply that:

“... no curriculum can accommodate the infinite complexity of IS. Difficult choices must be made on what to include in the limited room available.” (Bonnici and Warkentin 1995 :97)

Like that cited above, much of this literature illustrates the on-going academic controversy on the nature and extent of IS curriculum. In Chapters 6-9, I will show how this controversy came into focus at RMIT in discussions on the design of the new IS undergraduate degree resulting from the merger of PIT and RMIT. The next curriculum model: IS’95 appeared partly in answer to criticisms such as those described above and partly because of rapid, continuing change in Information Systems. Information Systems Model Curricula - IS’95 (draft report) and IS’97 The most recent model curriculum publications are cooperative efforts from the three major professional societies with an interest in Information Systems. Information Systems IS’95: Model Curriculum and Guidelines for Undergraduate Degree Programs – Draft Report (Cougar, Davis et al. 1995) and IS’97 Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems (Davis, Gorgone et al. 1997) were both jointly produced by the Association of Information Technology Professionals


(AITP17), the Association for Computing Machinery (ACM) and the Association for Information Systems (AIS). IS’95 was only ever presented as a draft report from which IS’97 was later published. The two underpinning documents for IS’95 (and hence IS’97) were the ACM’82 Information Systems curriculum and the DPMA’s IS’90 report, according to a paper describing the task of putting IS’95 together (Gorgone, Cougar et al. 1994) written by those involved. The paper describes how the ACM and DPMA went to considerable effort to ensure that IS’95 was representative of the views of both their organisations. This is further emphasised in the introduction to IS’95 (Cougar, Davis et al. 1995) where it is noted that the former separate curriculum recommendations previously prepared by these two organisations had resulted in confusion to both the academic and practitioner communities. One of the important issues that IS’95 set out to address (Gorgone, Cougar et al. 1994) was the definition of Information Systems and the essential differences between Information Systems, Computer Science and Software Engineering. Much of the information necessary to produce this updated curriculum document was obtained from a survey of about 2,000 participants from both business and higher education (Longenecker, Feinstein et al. 1994). The survey indicated an industry requirement for entry-level graduates with an increased technical orientation, as well as improved skills in behavioural considerations. IS’95 has an applied focus which draws upon links between theory and practice, and the report states that:

“The primary requirement of IS’95 graduates is to be able to implement and deploy information systems within an organisational context.” (Longenecker, Feinstein et al. 1994)

Although the IS’95 curriculum model was developed for, and intended for use in the United States and in Canada, its authors claim that as the model is grounded in fundamental body of knowledge elements which are not tied to the education system of any particular country it could also be considered as a reference model for international use (Cougar, Davis et al. 1995). The curriculum was designed with the intent that it could easily be updated, and was developed using an instructional design methodology derived from Gagne and Briggs (1988).

“A primary design goal of IS’95 was to incorporate the body of knowledge, a rational presentation structure, and a set of courses that would satisfy the different constituencies.” (Longenecker, Feinstein et al. 1994 :177)

The draft IS’95 curriculum was discussed at several international Information Systems conferences and was reviewed by almost a thousand academics and IS professionals before being published in its final version in May 1997 as IS’97 (Davis, Gorgone et al. 1997). IS’97 sees the academic field of Information Systems as encompassing two broad areas:

• An Information Systems function consisting of the acquisition, deployment and management of information technology resources and services.

• A Systems Development function involving development and evolution of infrastructure and systems for information use in organisational processes.

Based on IS’95, IS’97 presents a layered model in which each layer includes and builds upon the content of earlier layers. It uses a spiral approach to material presentation where the student revisits many of the items, each time with increasing complexity (Longenecker, Feinstein et al. 1994). 17 - formerly the DPMA


The Information Systems Body of Knowledge presented in IS’97 is based on that of IS’90 and consists of three major topic areas: information technology, organisational and management concepts, and theory and development of systems. Each of these is further subdivided (Davis, Gorgone et al. 1997) into 29 sub-areas, two of which are primarily concerned with programming and a number of others contain a significant weighting of programming concepts. The overall architecture of the model curriculum is of five curriculum presentation areas: information systems fundamentals, information systems theory and practice, information technology, information systems development, and information systems deployment and management processes (Davis, Gorgone et al. 1997). These five areas contain ten subjects (Figure 2.4 below), two of which are concerned with programming. It is based on 127 learning units which are derived from the Body of Information Systems Knowledge.

Figure 2.4 IS’97 subject areas In common with IS’90, the depth of knowledge required for each module is expressed using a metric based on that of Bloom et al. (1956), but with five levels: • awareness, • literacy, • concept / use,

IS’97.10 – Project Management and Practice

IS’97.9 – Physical Design andImplementation with a Programming Environment

IS’97.8 – Physical Design and Implementation with DBMS

IS’97.7 – Analysis and Logical Design

IS’97.1 – Fundamentals of Information Systems (IS)

IS’97.2 – Personal Productivity with IS Technology

Prerequisite: IS’97.PO – Knowledge Work Software Tool Kit

IS’97.5 – Programming, Data, File and Object Structures

IS’97.6 – Networks and Telecommunications

IS’97.4 – Information Technology Hardware and Software

IS’97.3 – Information Systems Theory and Practice


• detailed understanding / application, • skilled use.

As one can easily appreciate on reading it, a great deal of time and effort has gone into the production of this curriculum document and nothing else like it relating to IS curriculum has been published anywhere in the world. IS’97 is significant as a reference point to Australian IS departments and cannot be ignored. Other Model Curriculum Documents One important reason for the multiplication of model curricula in Information Systems is an attempt to define the scope of the IS discipline (Emurian 1998). Several smaller professional associations, mainly from the United States, have also published their own specialised curriculum models which are often expressed in considerable detail. I will briefly mention just the curriculum models produced by the Office Systems Research Association (OSRA), and the Information Resource Management Association (IRMA) in conjunction with the Data Administration Managers Association (DAMA). The OSRA model Organisational and End-User Information Systems (OSRA 1997) consists of eleven subjects aimed specifically at an audience of end-users rather than computing practitioners. Several of the topics parallel those found in more general IS curricula but the shallow treatment of these topics means that this model has little relevance in a consideration of curricula intended for the education of IS professionals. Similarly the IRMA-DAMA Information Research Management Curriculum model (Information Resource Management Association and Data Administration Managers Association 1996) is concerned primarily with the topic of Information Resource Management (IRM), a sub-set of Information Systems. The course is composed of ten subjects, one of which: $OJRULWKPLF&RQFHSWV DQG ,QIRUPDWLRQ Management emphasises programming. Although the authors claim this to be an ‘international curriculum model’ its narrow focus on IRM makes it of little interest here. Each of these curriculum models was devised in the USA, begging the question whether American IS curricula are relevant to Australia. Research into Information Systems curricula in countries including the UK, Canada, Norway, Japan, Ireland, Singapore, Switzerland, Denmark and Sweden (Goslar and Deans 1994) has shown a good measure of commonality in what is taught, and that much of the material used is of American origin. Comparisons of the views and expectations of MIS managers from different parts of the world (Watson, Kelly et al. 1997) also tend to confirm that those of managers from Australia and other developed countries, such as the USA and UK, are very similar. All this, coupled with the globalisation of Information Systems, suggests that surveys of the views of American MIS managers on Information Systems curriculum can also be expected to apply to Australia and other similar countries, and that US developed curricula should be of interest to Australian universities. Many of the national organisations of computing professionals such as the Australian Computer Society, the British Computer Society and a number of others, particularly in Europe (Finkelstein 1993) offer advice on the design of IS curricula, but have not produced documents with the same level of sophistication as the Americans. Each of these curriculum documents and models offers something to the IS curriculum picture, but some more so than others. In relation to the typical Australian course in Information Systems the IS’97 model is of the most interest by far.


Model curricula seek to define the scope of Information Systems curricula either generally, or in their area of specific interest. Although there is no obligation for an Australian university to follow their recommendations closely, the need for accrediting bodies to make some external comparisons means that these models are given consideration by IS Departments. In relation to this study, it is the place the model curricula give to programming in relation to other areas that is of the most interest, and the literature discussed in the previous sections has shown that this place is significant.

Programming in Information Systems Courses The study of programming is a large and diverse topic and consideration will now be given to the types of programming language generally thought appropriate for use in Information Systems courses. It will be shown that different categories of language are considered suitable for use in Information Systems curricula than those used in Computer Science. Several years ago a report from DEET (1990) identified fifteen groups of tasks undertaken by IT professionals and indicated that in only one of these: Systems Trainers, could programming not be regarded as a regular part of their work. A later DEET survey (1992) on the relevance of course content to employer needs showed that programming, especially procedural and object-oriented programming, was regarded as a highly desirable component of any computing course. Questions of whether programming should be taught to all students in a computing course, and if so what programming language should be used as the vehicle, are always likely to be hotly debated. diSessa, Resnick and Papert, and Clancy and Linn, for instance (Solway 1993), all insist that programming is essential if the full power of computing is to be realised. Solway and Guzdial maintain that IS curricula should not concentrate on teaching programming in languages like Pascal, Basic or Lisp, except to students majoring in programming (Solway 1993). They suggest instead use of domain-specific, ‘scaffolded’ packages like PhotoShop and ScienceWorks to teach students to create microworlds and manipulate computational media. Miller sees the teachers of programming moving in two irreconcilable directions: one group moving towards use of C and the other towards ‘end-user’ programming languages like Visual Basic (Solway 1993). He argues that people who can program a computer are empowered and that programming is here to stay. Object-oriented programming is more than just a little different from conventional procedural programming and requires an entirely different approach to the extent that it can be regarded as representing a different programming paradigm (Statts 1998). Moves in many computing courses towards adoption of the object-oriented paradigm (Massey and Douglas 1993; Hardgrave and Douglas 1998; Lee and Leigh 1998) require the incorporation of many software engineering concepts and so present a challenge to traditional curriculum (Statts 1998). Several writers (Goff 1997; Hardgrave and Douglas 1998) suggest the likelihood of OO languages replacing languages like Cobol in the IS curriculum of the near future. Ironically, given the media exposure of OO languages like C++ and Java, a recent survey of university IS departments in the USA shows Visual Basic to be the most popular object-oriented language in Information Systems courses (Hardgrave and Douglas 1998). Current programming languages have been classified (Ousterhout 1998) into two groups: ‘systems programming languages’ like Pascal, C, C++ and Java, and ‘scripting languages’ such as Perl, Tcl, Java Script, Unix shells and Visual Basic. System programming languages as designed for use in building data structures and algorithms from scratch, while scripting languages are used for systems integration and rapid application development; for


use in ‘gluing’ powerful existing components into useful combinations. Whilst Ousterhout believes that systems programming languages will remain an important tool for a small group of professional programmers, he sees scripting languages as the way of the future for the majority of IS professionals who will use them to assemble pre-existing components in building their organisational information systems. IS’97 regards programming as an important underlying theme with elements of programming in many areas. Programming is also seen as an important topic in its own right with two of the ten suggested subjects: ,6ª�� ¥ 3URJUDPPLQJ� GDWD� ILOH DQG REMHFW VWUXFWXUHV and ,6ª�� ¥ 3K\VLFDO 'HVLJQ DQG ,PSOHPHQWDWLRQ ZLWK D 3URJUDPPLQJ (QYLURQPHQW being given completely over to programming (Davis, Gorgone et al. 1997). One of the ways that Computer Science and Information Systems curricula are differentiated is by their respective treatments of programming. Both IS’90 (DPMA) and CS’91 (ACM) regarded the teaching of specific programming languages as important, but the ACM model promoted structured languages such as ADA and Pascal, while the DPMA model recommended Cobol. Neither model stressed language syntax. Different types of programming languages that may be appropriate in each of these types of course are categorised in a DEET report as follows:

“Lower level programming will be hardware specific, requiring detailed technical skills and knowledge of multiple processing across a range of repositories. In contrast, higher level programming will be close to the end user, requiring detailed knowledge of business functions.” (Department of Education Employment and Training 1990 :172)

Cook (1990) further divides these higher level languages into those suitable for ‘users’, and those for ‘power-users’. He argues that users need languages that are as ‘friendly’ and as easy to use as possible, and gives as an example a macro language in a word processor or spreadsheet. Power-users, on the other hand, need ‘full-featured’ languages such as Visual Basic. In similar vein Beck (1994) uses the terms ‘abstracter’ and ‘elaborator’ where an abstracter is an experienced programmer whose task is to create reusable segments of code, while an elaborator combines and modifies these segments into user applications. He describes abstracters as component builders and elaborates as solution builders. Given the applied nature of Information Systems courses, these courses are more likely to stress the teaching of programming at the higher-level to power-users and to elaborators (Shackleton, O'Connor et al. 1997), leaving users to more general courses and abstracters to Computer Science and Software Engineering. This has implications for the type of programming languages that may be considered appropriate for use in Information Systems curricula when compared with other computing courses. University IS Departments, such as the Department of Business Computing at RMIT, are generally aware of these issues and give them due consideration when choosing which programming languages to use.

The IS Curriculum Development Process The relatively small amount of literature relating to IS curriculum development processes will now be considered in three areas: forces which shape the curriculum, processes that may help in keeping the IS curriculum up to date and relevant, and how IS curricula are moving towards the increased incorporation of human and managerial skills. Writing in relation to Master’s level curricula in Management Information Systems in the United States, Sandman (1993) offers seven principal environmental forces which he contends shape this curriculum and trigger its reassessment. The forces he describes could well be generalised to apply to other curricula.


Figure 2.5 Influences on MIS curriculum

- adapted from Sandman (1993) The strongest of the seven forces Sandman postulates is that of the ‘academy’, a term he uses to mean the requisite body of knowledge prescribed by one of the professional associations (ACM or DPMA). Model curricula (such as IS’97) from these organisations are thus the most obvious manifestation of the influence of the academy (Chapter 8). Obviously the faculty of academics who teach the program has an influence and Sandman considers that the background and experience of these academics can be a limiting factor. IS graduates undertake masters courses primarily in order to get better jobs, he asserts, and so the views of the local industrial community are an important force to take into account in developing a curriculum. Student background is another constraining factor. In common with a number of writers on IS curriculum (Nunamaker 1981; Longenecker, Feinstein et al. 1994; Cougar, Davis et al. 1995), Sandman argues that this is a technology-driven field and that emergent technologies are an important force in this dynamic area. Competition for students is a force for curriculum change as courses adapt to capture the ever elusive extra student. At a recent ISECON18 conference in America, the keynote speaker (Dougherty 1997) raised the possibility that competitive forces would soon induce some universities to offer courses that would dovetail with the certification requirements of IT companies like Microsoft, SAP, Lotus and Novell. Students would then get a degree and, for example, a Microsoft Certified Systems Engineer qualification19 (Watson and Schneider 1998). An important question then arises in whether a student intent on an IS career needs a university degree, or if industry certification is sufficient. Alexander (1997) claims that industry certification helps in the job market but notes that his discussions with IS managers suggest that it cannot be seen as a suitable replacement for an IS degree. Finally, organisational constraints are also important forces for change. These range from internal departmental power struggles to shortages of funds and equipment (Sandman 1993). Recently at Victoria University of Technology a move to merge the Departments of Information Systems and Computer Science was defeated. Had this move been successful it would probably have resulted in changes to both the Information Systems and Computer Science curricula as two sets of academics struggled to adjust to working within the same new department. The subjects most likely to change would be those currently taught, in different ways, by each department. In relation to this study, the merger of RMIT and PIT 18 Information Systems Education Conference (ISECON’97), Orlando, Florida, October 1997. 19 This is already being considered in several Australian universities, including RMIT.

Organisational constraints

Competition Technology

Academy

Students

Faculty

Community MIS Curriculum


(Chapter 8) also initiated significant curriculum change as shall be shown in the following chapters. A reading of a number of other papers on IS curriculum suggests that two issues currently stand out as particularly significant: how courses can be kept up to date, and the balance between technical, managerial and human skills required of students. Each of these issues relates to students later finding jobs in the computer industry, and so is of especial concern in an educational institution like RMIT. Keeping Courses up to Date and Relevant Many writers (eg Longenecker et al. 1994) stress the need for Information Systems curricula to keep up to date, but Vincent and Ross (1998) note that software is changing so fast that keeping up with these changes is increasingly difficult. One aspect of keeping up to date and of improving IS courses involves seeking the opinions of students, and Richards and Sanford (1992) argue that surveys of IS graduates are essential if curricula are to be modified to keep pace with the growth of technological changes and demands in the marketplace. They distinguish between education in the foundations of the discipline of Information Systems, which they see as a long-term activity designed to build a foundation of knowledge and reasoning ability, and short-term technical training needed by graduates in order to be immediately effective in their jobs. Their survey results suggest that their IS graduates see the most valuable components of their education as including their technical training, structured programming and Cobol, systems analysis and development, database systems, and general business concepts. They reiterate that educators cannot ignore the acceleration in technological change occurring in the computer industry and implore that courses must remain current (Richards and Sanford 1992). Another aspect of keeping courses relevant involves seeking industry views, (Ahmadi and Brabston 1997) and Haworth and van Wetering (1994) remark on the oft levelled criticism that IS curricula are not in tune with the needs of the IS practitioner and note that one way that a number of business schools have attempted to address this issue is to establish links, often in the form of business advisory boards, with the business community. Quoting Gambill and Jackson’s (1992) findings that communication between the business community and academia is inadequate, they note that the use of advisory boards may not be an effective way in which to obtain industry input for curriculum decision making. They propose that a more structured method of obtaining data is required and suggest the use of the Q-methodology developed by Stephenson (1953) for the study of individual attitudes20. In their study, Haworth and van Wetering (1994) identified four orthogonal factors in their data: business management, non-Unix technical, Unix business systems and Unix technical. They note, however, that the four viewpoints account for 22%, 19%, 10% and 9% respectively of the variation in responses and that even if a curriculum could be devised to satisfy these, 40% of the respondents would thus be dissatisfied. They go on to point out that the four identified subsets are orthogonal and thus independent, but that this does not mean that they are mutually exclusive with respect to content. They show that there is considerable commonality and that this may mask the underlying differences between

20 Stephenson proposed that a person’s point of view (subjectivity) could be studied in an objective, orderly

and scientific manner (McKeown and Thomas 1988). Q-methodology comprises a series of mini-experiments or Q-sorts where subjects distribute the items into a forced normal distribution of most to least agreement. The result is a quasi-normal distribution that yields a model of subjective preferences. Analysis for Q-methodology involves the sequential application of three statistical procedures: correlation using Pearson’s r, factor analysis, and calculation of factor scores for each of the statements in each of the factors (Haworth and van Wetering 1994).


members of an advisory board. They postulate this as a possible explanation for the apparent failure of these boards. Concerns reportedly expressed (Clarke 1996) by IT employers with the IS curriculum development process in Australian universities include a need for better articulation between courses and institutions, and the time taken to launch a new course; often two to three years from conception to first intake. Both of these are seen as problems that increase the difficulty of keeping courses up-to-date and relevant in our universities. It has even been suggested (Burn 1997) that perhaps the concept of generic curriculum to meet the needs of all future IS professionals is now obsolete and that future curricula should be targeted at specific career paths. This view however, does not seem to have much support at present. The Importance of Human and Managerial vs Technical Skills In the late 1980s and early 1990s a number of writers discussed the need to include more than just technical material in an IS curriculum. Some (Hilton 1990) stressed the importance of interpersonal and communications skills, while others (Licker and Miller 1989; Yaffe 1989) underlined a need for the inclusion of multi-disciplinary studies focusing on ‘soft’ skills such as communication, management and general business skills, arguing that surveys of IS professionals show that human skills are more important than technical skills in career advancement. Carlson and Wetherbe (1989) and Stolen (1992) showed that the teaching of skills of this type was often lacking in IS courses in the US, and Lo (1991) and Ang (1992) found that the same was true in Australia. To remedy this perceived problem several writers (Adams and Song 1989; Fortune and Palmer 1990; Wysocki and Young 1990; Tye, Poon and Burn 1995) have argued for placing more emphasis on the managerial aspects of Information Systems at the expense of the technical, procedural and application aspects. They maintain that Information Systems professionals with solid business backgrounds and a combination of interpersonal, technical and business skills will be better able to cope with future business demands. These views contrast with those of Fabbri and Mann (1993) discussed earlier. After surveying US business and academia, Gambill and Jackson (1992) comment on the need for greater emphasis on business skills in IS courses, and specifically on a deficiency in managerial and communication skills. They refer to a report (IBM 1987) which notes that information processing managers focusing intensely on their specialty frequently do not develop a depth of knowledge about business management. In conclusion, they remark that:

“It is clear that the MIS environment has undergone dramatic changes and that today’s circumstances require MIS professionals that understand not only the technical aspects of their field, but how IS relates to the entire organisation as a whole.” (Gambill and Jackson 1992 :16)

Stolen (1992) found that there appeared to be two major IS course types: a pure MIS major in which only Information Systems was studied and a mixed major which combined Information Systems with some other curriculum area such as accounting or quantitative analysis. The dilemma faced by curriculum designers wanting to include more managerial aspects at the expense of the technical however, is that many IS students obtain their first job as an entry-level programmer, only later moving on to ‘bigger’ things (Stolen 1992) and any reduction in the teaching of technical skills would make getting such jobs more difficult. Stolen (1992) argues for a compromise where the teaching of technical skills is reduced only slightly to make way for other things.


Cooperative education offers another way to emphasise business skills, and Crow and Rariden (1992) argue in favour of the value of including a component of this within the IS curriculum.

“Utilizing this mode of education provides experiential learning in ways not available in the classroom setting.” (Crow and Rariden 1992 :52)

They point out that this then provides a nexus between theory and practice, adding relevance to the theory, providing a theoretical underpinning to the practical, and allowing curriculum integration in the various aspects of computing (Clear 1997). Taken together this literature argues that relevant contact with business and the computer industry is important to ensure that Information Systems curricula remain relevant. They also point out that, although technical issues are still important, IS curricula are moving away from an emphasis on the more technical aspects of computing towards a focus on general business skills and skills that can be useful in facilitating the use of computers in business applications. In relation to programming curricula, this could be interpreted as suggesting the use of industry relevant languages, and a stress on building applications rather than the more technical aspects of programming.

Curriculum Innovation in Information Systems This chapter began with a discussion of the formation and clarification of the discipline of Information Systems, and a contention that a consideration of such matters is important in determining the boundaries of the discipline, particularly in a topic area like programming that crosses them. I then analysed some of the major curriculum models relating to Information Systems, and showed how they acted to reinforce their designers’ views on the scope and boundaries of the discipline. All these model curriculum documents acknowledge the importance of teaching programming, but it is also necessary to look at other papers to gain some insight into the type of languages that may be most appropriate. Keeping IS courses relevant to industry needs has implications for choice of programming language. While the literature reports on a number of specific curriculum issues in university-level information systems courses, it makes little reference to research dealing with the process of IS curriculum formation and change; the subject of this thesis. Many academics (Nunamaker 1981; Longenecker, Feinstein et al. 1994; Cougar, Davis et al. 1995) have written of the effect that changes in computing have on IS curricula, and the need for its continual updating. Goldweber et al. (1997) remark that these changes force a corresponding rate of innovation in IS courses with the ‘Law of Conservation of Curriculum’ (Kay 1996) meaning that whenever new content is added, something else must be removed. They caution that while innovations, such as new technologies and programming languages, may seem appropriate at the time, they are sometimes adopted without sufficiently careful consideration and that this can result in costly mistakes. They note that sometimes in their haste to adopt some new initiative, teachers of computing overlook the possibility of adverse effects following from these innovations, and recommend that past history can be a useful yardstick to judge the worthiness of these new ideas. The issue of innovation in Information Systems curriculum is a complex one and is the subject of the next chapter.


Chapter 3

Theories of Innovation and Change Innovation in education and the diffusion of

innovations The IS curriculum literature analysed in the last chapter has a lot to do with innovation, but it makes little specific mention of this term, or any of the mechanisms by which innovation might occur. The adoption of Visual Basic in the Information Systems curriculum at RMIT was not just a minor curriculum change in which one programming language replaced others that were very similar; it represented an entirely new and different approach to programming. The Macquarie Dictionary (1981 :914) defines an innovation as occurring when something new or different is introduced, so the adoption of Visual Basic at RMIT can thus be considered to be an innovation. This chapter, and the next, examine the literature on innovation in an attempt to explore the role that innovation theories have played in explaining educational innovations of this kind. The literature on innovation in general, and educational innovation in particular, is large and so I have examined it selectively. As the educational innovations under consideration in this study are concerned with choices made by an individual lecturer or group of lecturers, or at most with a university department, literature relating in some way to innovation of this kind is what I have sought. Changing the way things are done is a complex affair and one that is difficult to achieve successfully. Success in innovation is always doubtful because people who are prepared to support the innovator can be difficult to find and to convince. Although writing of political change almost five hundred years ago Niccolò Machiavelli summed this up as follows:

“There is nothing more difficult to handle, more doubtful of success and more dangerous to carry through than initiating changes ... The innovator makes enemies of all those who prospered under the old order, and only lukewarm support is forthcoming from those who would prosper under the new. Their support is lukewarm partly from fear of their adversaries, who have the existing laws on their side, and partly because men are generally incredulous, never really trusting new things unless they have tested them by experience.” (Machiavelli 1995 :19)

By far the dominant paradigm in innovation research is that of innovation diffusion (Rogers 1995) and no discussion of innovation would be complete without a consideration of this approach. Another approach, that of innovation translation (Latour 1986), informed by actor-network theory (ANT), will be discussed in the next chapter. This chapter examines models of how innovation has been theorised, and begins with a discussion of the literature relating to innovation in education.

Innovation in Education Much of the literature on educational change reports on studies concerned with planned and managed school improvement undertaken by central educational authorities. For instance, although stressing the importance in any long term perspective on the evolution of social change of unplanned or naturally occurring changes, Fullan, who writes on curriculum innovation and educational change in schools, declares that:


“My goal is to highlight the problems and possibilities in bringing about educational change through some deliberate means.” (Fullan and Stiegelbauer 1991 :xii)

Most other researchers working in this area have similar goals. Fullan and Stiegelbauer (1991) for the most part consider situations in which change is imposed, or at least directed, from above. In most cases this change results from an idea initiated by the school system rather than by a classroom teacher or even a particular school. Rather than specific changes in curriculum content of particular subjects, what most of these studies are really concerned with is overall school improvement (Fullan 1993).

Figure 3.1 Research, development and dissemination model

- adapted from Deakin University (1985 :92) Curriculum innovation of the type discussed in many of the reported studies is based on a research, development and dissemination model (Havelock 1969; 1971) in which research leads to the development of an educational ‘product’ which is then diffused, or disseminated, to schools that may either adopt or reject it (Figure 3.1 above). Many of the research studies are based on an examination of the factors that affect adoption or rejection decisions in schools. In most cases, schools and classroom teachers are seen as having no part in creating the innovation; this is done centrally and they are just expected faithfully to adopt it in the suggested form. This approach is in line with the ‘centre-periphery’ model of curriculum innovation, one of three models outlined some years ago by Schön (1971). A centre-periphery approach to educational innovation can be shown to have the advantage of authority and speed of adoption, provided either that schools are required to adopt or that they can be made to see good reason to accept the proposed change (Hoyle and Bell 1972). In Schön’s second model, consultants and mediators are employed to ‘spread the good word’ and so disseminate the innovation. This ‘proliferation of centres’ (Schön 1971) approach has a benefit in reducing the distance from the centre, where the innovation was devised, to those expected to adopt the innovation. Thirdly, Schön characterises innovations that are not centrally sponsored, but nevertheless reach schools, as following a ‘shifting-centres’ model. In the context of higher education curriculum Nordvall (1982), building on the work of Havelock (1969; 1971), identifies several models for curriculum change that he suggests all have relevance at the subject, course, and institutional levels. • Research, development and diffusion models. Relying on logical and rational

decisions, curriculum change models of this type depend on the use of convincing arguments based on programs of research. They posit a rational and orderly transition from research to development to diffusion to adoption (Kaplan 1991: 595). These models relate closely with the centre-periphery model described above (Deakin University 1985) and consider researchers, developers and disseminators of the new curriculum as the prime agents. The recipient is treated as passive, and those who do not comply by adopting the change are considered as ‘resistant’ (Kaplan 1985) and their behaviour ‘dysfunctional’ (Wetherbe 1988 :243-246). Nordvall however, suggests

Basic research

Mass production and packaging

Development and testing of prototypes

Applied research

Adoption by users

Planned mass dissemination activities


that unlike the situation existing in school education, innovations of this type are probably not often encountered in higher education.

• Problem solving models. Change in this conception is based on a perceived educational need identified either from within the educational institution or from outside. In this case the ‘centre’ (Schön 1971) is the educational institution (Hoyle and Bell 1972). Also seen as a quite rational approach (Nordvall 1982), it involves searching for alternative solutions, often by looking at what colleagues with similar interests are doing but sometimes by other forms of research, in an attempt to find a solution to the educational problem. Change is considered to occur in stages where needs are first identified and articulated as problems before solutions are sought, selected and applied (Kaplan 1991). Nordvall’s research shows that this is a fairly common approach to curriculum change in higher education, and fits well with concepts of academic professional judgement.

• Social interaction models. Models of this type focus on the individual receiver of the innovation (Kaplan 1991). Exposure to a new idea, persuasion by influential colleagues, desire for social acceptability, or just a sense that others are making a change and ‘so we should do so too’ are examples of change undertaken according to these models (Nordvall 1982). Change brought about in this way is not necessarily based on evidence but more often, as the name suggests, on social interaction. Havelock (1971) sees this model as representing a generalisation of the process of innovation diffusion.

• Political and conflict models. Pressure groups and coalitions, either inside or outside the university, can sometimes trigger change based on conflict. Nordvall (1982) notes that this change is often related to perceived student needs or social inequalities.

• Diffusion, linkage or adaptive development models. Exhibiting characteristics of several of the other change models, these models rely on opinion leaders and linkage agents to make known the need for change and the nature of the change required. Nordvall suggests that models of this type attempt to integrate the other models and are often useful in describing externally driven curriculum change.

The Management of Change Curriculum innovation does not, however, differ fundamentally from other forms of change (Davis, Rhodes et al. 1998) and all change is seen to cause some anxiety, struggle and loss to those individuals concerned (Marris 1975). In examining whether, or how, an innovation is adopted, the involvement of those individuals undergoing the change should thus not be forgotten. As Fullan and Stiegelbauer remark:

“The crux of change is how individuals come to grips with this reality.” (Fullan and Stiegelbauer 1991 :30)

Several scholars have come up with models of how people handle and react to change, and these models are useful in suggesting ways in which change can effectively be implemented. A model attributed to Kurt Lewin (1947) examines the forces for and against change. Forces that push for change are called driving forces while those that resist the change are labelled restraining forces. Lewin argues that to improve the effectiveness of the change a manager should identify forces of each type that are operating and then attempt to promote the driving forces while removing the restraining forces. Building on Lewin’s work, the Lewin/Schein change model (Schein 1961) contends that managers planning any change need to move their organisations through three stages:

• Un-freezing - the process of removing old ways of doing things and creating a climate conducive to change. People are reluctant to change unless they see a need to do so, and


the purpose of this stage is to establish a need for the change in those who will have to do the changing; to create a climate that is both non-threatening and conducive to change.

• Moving - implement the change and learn the new system. In addition to performing the actual implementation this stage provides the change subjects with the knowledge, skills and information needed to bring about the necessary changes in attitude required if the new system is to be successfully implemented.

• Re-freezing - reinforce and institutionalise the changes that have occurred and return the organisation to stability so as to fix the new situation as the accepted routine. Re-freezing requires the change to be integrated into the overall operation of the organisation and often requires diffusing the change throughout the organisation’s social system.

Although formulated over thirty five years ago the Lewin/Schein change model is still prominent in management texts today (eg Stoner, Yetton et al. 1994; Alter 1996) and its stress on working with, rather than against, those who have to undergo the change is reflected by Fullan and Stiegelbauer when they point out that:

“If we know one thing about innovation and reform, it is that it cannot be done successfully to others.” (Fullan and Stiegelbauer 1991 :xiv)

The more detailed Kolb/Frohman model of organisational change (Kolb and Frohman 1970) outlines seven stages through which change can be considered to proceed.

• Scouting. The system developer and the user get to know and understand each other; the user’s needs and the developer’s abilities are each assessed by the other.

• Entry. The developer and the user begin a formal collaboration and establish the project objectives.

• Diagnosis. The problem is identified and defined, and information is collected. • Planning and goal setting. The developer and the user consider the various alternative

courses of action possible in implementing the new system. They also determine the criteria to be used in evaluating the project’s success and develop a plan aimed at achieving such success.

• Action. The selected approach to the systems implementation is further developed and modified as required. A user-training plan is commenced.

• Evaluation. Criteria previously laid down for evaluating system success are now applied and any required remedial action is undertaken.

• Termination. When it has been confirmed that the system fulfils requirements, ownership is transferred to the user and the implementation concludes.

While the relationship is far from exact, the first three of Kolb and Frohman’s seven stages (scouting, entry and diagnosis) correspond roughly to unfreezing in the Lewin/Schein model. The next two stages (planning and goal setting, and action) correspond to moving, and the last two (evaluation and termination) can be related to re-freezing (Ginzberg 1979). Another of the underlying principles of innovation theory formulated some years ago comes from Berlyne (1962; 1965). Building on Festinger’s (1957) work on cognitive dissonance Berlyne proposed that the decision of whether or not to adopt an innovation creates conceptual conflict in the potential adopter. He contends that the degree of conceptual conflict increases with the number of competing responses to choose between, the degree to which the competing responses approach each other in strength, the total strength of all the competing responses and the degree of incompatibility between these


competing responses. He outlines a number of information gathering techniques that are available to the potential adopter to help resolve the conceptual conflicts. These include:

• Disequalisation of the competing responses; a process by which new information reduces the nearness of the competing responses to equality in strength.

• Swamping the competing responses by a new response which was not originally examined and which exceeds all the others in strength.

• Conciliation of the competing responses, so that they are shown not to be incompatible. • Suppression of thoughts about the subject matter to reduce the total strength of

responses. Drawing on the work of House (1979; 1981), Hall (1997) contends that technical, political and cultural dynamics can be used to conceptualise innovation and change management processes. He maintains that the technological dynamic is founded upon a mechanistic view of innovation based on production, task orientation and efficiency. The political perspective emphasises negotiation, resource distribution and the exercise of power and authority, while the cultural perspective considers shared meanings and a sense of community based on shared values as its basis. The context in which curriculum change occurs is also an important consideration (Pincus 1974; Fullan and Stiegelbauer 1991; Hargreaves 1992; Sikes 1992). Fullan and Stiegelbauer (1991) argue that a number of social, administrative and educational factors affect the initiation of change and that this can be modelled, in a school context, as shown in Figure 3.2 below.

Figure 3.2 Initiation decisions

- from (Fullan and Stiegelbauer 1991 :50) Educational innovation is, they note ‘multi-dimensional’ having at least three aspects involving: use of new curriculum materials or technologies, use of new teaching approaches and strategies, and changes in beliefs. Pincus (1974) offers three factors likely to favour the adoption of an educational innovation: bureaucratic safety which adds resources without behavioural change, response to external pressure, and the approval of peer elites. Also contributing to the context in which curriculum change occurs, the concept of ‘cultures of teaching’ is regarded as important by a number of researchers (eg Sikes 1992; Fullan and Hargraves 1991; 1992) as “it is through these cultures that change is mediated, interpreted and realised” (Sikes 1992 :43). It is argued that these cultures are a product of the beliefs, values and characteristics of the teachers, students and community and that they represent ‘the way we do things here’ (Nias 1988). Hargreaves describes cultures of teaching as the:

INITIATION DECISIONS

1. Existence and quality of innovations

2. Access to innovations

3. Advocacy from central administration

8. Problem-solving and bureaucratic orientations

4. Teacher advocacy

7. New policy – funds (Federal/ State/ local)

6. Community pressure/ support/ apathy

5. External change agents


“... beliefs, values, habits and assumed ways of doing things among communities of teachers who have had to deal with similar demands and constraints over many years.” (Hargreaves 1992 :217)

Speaking primarily of schools he suggests that there are four broad forms of teacher culture each of which has very different implications for educational innovation:

• Individualism. As most teachers teach alone in their own classrooms they tend to be isolated from their colleagues, in many cases resulting in pedagogical conservatism.

• Balkanisation is “a culture made up of separate and sometimes competing groups, jockeying for position and supremacy like loosely connected, independent states” (Hargreaves 1992 :232).

• Collaborative culture. For this sort of culture to exist, teachers must be in broad agreement on educational values. Hargreaves suggests that this is the culture most conducive to local curriculum development.

• Contrived collegiality. In an attempt to move to a more collaborative culture, a form of collegiality is sometimes contrived. This is characterised by formal, specific procedures designed to increase collaboration.

Depending upon which of these contexts a curriculum innovation occurs in, the result may be entirely different.

The Adoption of Innovations by Schools In examining an educational innovation in order to decide whether or not to adopt it, Fullan and Stiegelbauer (1991) maintain that teachers look at issues such as relevance and practicality, and the readiness and availability of resources. Borrowing from Crandall et al. (1982), they qualify the ‘standard’ innovation paradigm for schools which traces the development of formally initiated programs, suggesting that it misses the many small changes made by teachers each day. They note that a strong body of evidence suggests that in these cases other teachers usually provide the preferred source of innovative ideas. Similarly, Hubbard and Ottoson (1997) followed an innovation in a group of US schools from its practice-based creation to its final implementation as public policy in the school district. They found that this ‘bottom-up’ innovation faced many of the same implementation difficulties that were commonly reported in studies of the ‘top-down’ innovations often discussed in the literature. Innovations are not always accepted by schools in their original form, and from his research on teachers’ acceptance of centrally developed science and mathematics curriculum materials Pitman (1981) claims that educational innovations are, of necessity, generally distorted by teachers adapting them to their own requirements rather than just accepting what is offered. He reports, however, that teachers having more contact with mediating agents, such as inspectors or consultants, tended more often to see their innovation choices in terms of a straight implementation-rejection decision. Pitman and Romberg (2000) have shown that those teachers who are prepared to uncritically accept ideas initiated by experts and authorities tended to favour any proposed change, whereas other teachers who make adaptations to their practice often did not do so along the lines suggested by the developers. Similarly, Romberg and Price (1981) argue that if an innovation is accepted, it is rarely assimilated into the school in the manner intended by the developer. Pitman and Romberg (2000) report that the form in which teachers will adopt an innovation is contingent upon the value they attach to that innovation and their understanding of how it conflicts with their prior beliefs. Pitman (1981) offers a model for curriculum negotiation (Figure 3.3 below) based on the work of MacDonald and Walker (1976) in which he argues


that the ‘product’ originally devised by a curriculum developer is modified in a series of negotiations with mediators, teachers and students before being adopted. He holds that these modifications are seen as necessary by each of these groups for the survival of the way they have of doing things. His concept of curriculum negotiation had some commonality with concepts from innovation translation; discussed in a later chapter.

Figure 3.3 Pitman’s (1981) model of curriculum negotiation

Innovation in Higher Education Curriculum Bryant et al. (1998), refer to a five-step curriculum design model they have used in the development of pre-service teacher preparation courses. They maintain that the five steps: determine a need, establish teacher competencies, identify the curriculum, organise learning experiences, and evaluate its effectiveness, lead to effective curriculum development. Davis et al. (1998), writing of nursing education, maintain that like any other form of organisational change, curriculum change is not possible without prior ‘unfreezing’ (Lewin 1947; Schein 1961) of faculty interests and values. In similar vein, Stark and Lattuca (1997 :333) posit that change seldom occurs in higher education curricula without some degree of interest, motivation and incentive for change among the academic staff. They note that most higher education curricula operate in an ‘open decision’ environment where changes can be advocated and argued openly. It is a characteristic, however, of such environments that curriculum decisions will have opponents who may strive to work against the changes, either openly or covertly.

World of teachers

Gap between images

World of academic and administrative critics

Implementation idealisation

Projection idealisation

Product idealisation

Product implementation

Motivation: survival of developers Motivation:

survival of mediators

Motivation: survival of work as teachers see it

Product

Product interpretation

Product projection

Motivation: survival of teachers

Motivation: survival of work as developers see it

World of mediators

World of developers

World of students


“The death of a new program may be plotted by its enemies as carefully as its birth was attended by its friends.” (Stark and Lattuca 1997 :334).

This opposition, they note, often results in curriculum changes in higher education reverting to their earlier forms (Stark and Lattuca 1997 :334). Toombs and Tierney (1991) have found that in most higher education institutions individual academics often work alone in designing their courses. Curriculum content is seen, traditionally, as the business of these ‘expert’ academics. This means, Toombs and Tierney contend, that not enough attention is given to the concerns of external interest groups. Research by Hefferlin, on the other hand shows that change in higher education seldom occurs entirely from the inside, but needs some external initiation.

“Academic reform consists far more in the diffusion of educational ideas from one institution to another than in the creation of new ideas.” (Hefferlin 1969 :156)

Busch (1997) also maintains that educational innovations frequently originate from external networks. Stark and Lattuca (1997 :331) contend that routine changes are normally initiated internally, while significant innovations tend to rely on external influences. These externally initiated changes are then transmitted and guided by academic and administrative leaders “who are attuned to these influences” (Stark and Lattuca 1997 :331). The characteristics of leaders of substantial educational change are important to take into account, and Seymour’s (1988) research shows that such leaders need to be communicative, willing to take risks, prone to ask difficult questions, focused on mission and sensitive to external opportunities. A number of writers (including Toombs (1991) and Bergquist (1981)) remark that tinkering with course structure is the most common form of curriculum change in higher education. They argue that this is often because academics feel uncomfortable in discussing the content of the subject material of other academics; course structure is something that is common to all subjects and so less controversial. This poses the question of why there has been so little research on theories of curriculum innovation at the university level. Toombs (1978) believes that the vast scope of the topic, and the nature of higher education, make it unlikely that a general model of university curriculum change can be built. As I have shown however, researchers working at the school level have developed a number of theories of curriculum and curriculum innovation and one typology of these theories (Stark and Lattuca 1997 :376) is to classify them as: structure-oriented theories, value-oriented theories, content-oriented theories and process-oriented theories. Stark and Lattuca (1997 :376) argue that a framework of structure, value, content and process can equally well be applied to higher education. Using the concept of ‘academic plans’ to represent the intended outcomes of university curricula, they offer the model of higher education curriculum change shown in Figure 3.4 below.


Figure 3.4 Factors influencing curriculum

- from Stark and Lattuca (1997 :377) Busch (1997) notes that most attempts to explain curriculum change in higher educational institutions are focused only on the change management actions of ‘key’ individuals like Faculty Deans and Heads of Department. She contends instead that:

“... teaching and learning networks are constructed by a process which creates both knowledge and organization simultaneously. In order to sustain curricular revisions, curriculum planners must attend to an entire network of actors.” (Busch 1997 :6)

Busch argues that to sustain curriculum change it is necessary to develop change management policies aimed at enrolling both human and non-human actors in new networks. Change management and innovation are quite closely related, with researchers writing on innovation in general often making reference to change management theories (Schein 1961; Berlyne 1962; 1965; Kolb and Frohman 1970). Innovation theories are, of course, relevant to all fields of study and not just education. There are two main approaches to modelling the innovation processes: innovation diffusion and innovation translation. Of these, the dominant paradigm by far is innovation diffusion, and my reading suggests that most literature on innovation in education is either implicitly or explicitly based on a diffusion model. I will now outline the theory of innovation diffusion and illustrate how its major premises inform and frame accounts of innovation in education.

Innovation Diffusion Originally a rural sociologist, Rogers published the first edition of Diffusion of Innovations in 1962 and the book, now in its fourth edition (Rogers 1995), has become a classic in this field. As the advertisement on the back cover of the latest edition indicates, the name Everett Rogers is virtually synonymous with the study of the diffusion of innovations to the extent that to many people, diffusion of innovations is Everett Rogers. Reviews of his work (such as those by Linton (1998), Clarke (1998), Larsen (1998) and Hu, Saunders et al.

Academic fields

Frameworks and perspectives

Administering, evaluating and adjusting

Debates

Trends

Learner influences

Faculty evaluation

Student outcomes measurement

Instructional resources and tools

Teaching styles and strategies

Counselling and advising

Student characteristics and learning styles

Status quo reports and curricula trends

Debates and advocacy positions

Historical traditions and perspectives

Social and economic needs

Change and innovation

Program evaluation & long-range planning

Academic Plan Instructional Learners processes Instructional Sequence resources Evaluation Content Adjustment Purpose


(1997)) abound in the literature and it is difficult to find any discussion of innovation diffusion without some mention of his name. Because of the importance of innovation diffusion theory I will take some time now to outline its important aspects. Innovation diffusion is based on the notion that adoption of an innovation involves the spontaneous or planned spread of new ideas. Rogers defines an innovation as:

“... an idea, practice, or object that is perceived as new.” (Rogers 1995 :11)

He stresses that it is the perception that is important; if the idea seems new to the potential adopter then it should be considered to be an innovation. Rogers approaches the topic of innovation diffusion by considering a variety of case studies on topics including: controlling scurvy in the British Navy, diffusion of hybrid corn in Iowa, diffusion of the news, bottle feeding of babies in the third world, how the refrigerator got its hum, Xerox PARC and Apple computer, black music in white America, Minitel in France, the non-diffusion of the Dvorak keyboard, and causes of the Irish potato famine. The prime concern in all these studies is the identification of factors that affect the speed with which an innovation is adopted, or that cause it not to be adopted at all. Apart from the many examples of innovation diffusion studies cited by Rogers (1995), examples by other researchers range across the entire field and include studies of managerial characteristics (Entrialgo, Fernandez et al. 1999), vocational training (Schmidt 1999), creativity (Preiss 1999), information technology outsourcing (Hu, Saunders et al. 1997), the growth of the Internet (Press, Burkhart et al. 1998; Rai, Ravichandran et al. 1998) and information systems innovation (Kwon and Zmud 1987; Kishmore and McLean 1998; Spann-Merchant 1998; Hughes and Sheehan 1999), to mention just a few. Although much of what Rogers has to say involves the adoption, by individuals and social groups, of innovations designed and promoted by others, a consideration of his work with regard to innovation in education, is relevant to this study. In diffusion theory the existence of an innovation is seen to cause uncertainty in the minds of potential adopters (Berlyne 1962), and uncertainty implies a lack of predictability and of information. Diffusion is considered to be an information exchange process amongst members of a communicating social network driven by the need to reduce uncertainty (Rogers 1995). Uncertainty can be considered as the degree to which a number of alternatives are perceived in relation to the occurrence of some event, along with the relative probabilities of each of these alternatives occurring. Those involved in considering adoption of the innovation are motivated to seek information to reduce this uncertainty (Rogers 1995). Diffusion theory contends that a technological innovation embodies information, and so its adoption acts to reduce uncertainty. In illustration of this Rogers cites the innovation of solar panels as reducing uncertainty over future energy costs and reliability of energy supply. The new ideas upon which an innovation is based are communicated over time, through various types of communication channels, among the members of a social system. There are thus four main elements of any theory of innovation diffusion: characteristic of the innovation itself, the nature of the communication channels, the passage of time, and the social system through which the innovation diffuses (Rogers 1995). Attributes of an Innovation Rogers argues that the attributes and characteristics of the innovation itself are important in determining the manner of its diffusion and the rate of its adoption. Borrowing from the work of Thomas and Znaniecki (1927) he notes that it is what potential adopters perceive to be the attributes of an innovation that is the important thing.


In the case of technological innovation, and almost all innovations studied fall into this category, Rogers outlines two components to be considered: a hardware aspect consisting of a tool that embodies the technology as a physical object, and a software aspect comprising this tool’s information base. (This is in line with Fullan and Stiegelbauer’s (1991) contention that many educational innovations have both physical and intellectual aspects.) An innovation like a camera has a hardware aspect: the camera itself, and a software aspect: the film. Rogers notes that although the software component of a technology is sometimes not easy to observe, as in the case of a new washing machine, technology almost always represents a mixture of hardware and software aspects. He acknowledges, however, that some innovations have only a software component. New political or religious ideologies, or the concept of educational quality assurance are ‘idea-only’ innovations of this type. Idea-only innovations are much more difficult to observe, and Rogers remarks that they are thus less often studied by diffusion scholars. He suggests that this may be because their spread is relatively more difficulty to trace. Rogers outlines five important characteristics of an innovation which affect its diffusion: • Relative advantage. This is the degree to which an innovation is perceived as better

than the idea it supersedes. Relative advantage is often expressed in terms of economic profitability, social prestige, or other similar benefits. Rogers contends that an innovation’s relative advantage is positively correlated with its rate of adoption. Fullan and Stiegelbauer (1991) argue that relevance and practicality also affect teachers’ adoption of curriculum innovations.

• Compatibility, or the degree to which an innovation is perceived by potential adopters as being consistent with their existing values and past experiences. Compatibility with what is already in place makes the new idea seem less uncertain, more familiar, and helps to give it meaning. This is important because “the rate of adoption of a new idea is affected by the old idea that it supersedes” (Rogers 1995 :227). Rogers claims that the perceived compatibility of an innovation is positively related to its rate of adoption.

• Complexity, or the degree to which an innovation is perceived as difficult to understand and use. Rogers claims that the more complex the innovation, the less likely it is to be quickly adopted. In support of this conjecture Rogers, Daley and Wu (1980) point out that in the late 1970s, a period of six to eight weeks of extreme frustration characterised the adoption of a new home computer.

• Trialability is the degree to which a particular innovation may be subjected to limited experimentation. Rogers’ research suggests that if a potential adopter is able to ‘play’ with the innovation before being faced with an adoption decision, then adoption is more likely.

• Observability. The more the results of an innovation are visible to others, the more likely the innovation is to be adopted. Rogers cites their high observability in public places and in the media as an explanation for the rapid take-up of video games such as Nintendo, and of cellular telephones.

Attributes of the potential adopter are also seen as an important consideration in the adoption of an innovation. Rogers maintains that these attributes include social status, level of education, degree of cosmopolitanism and amount of innovativeness. A slightly different slant on adoption is offered by Abrahamson and Rosenkopf (1993) who describe what they call the ‘bandwagon effect’. They argue that there are times when people or organisations adopt innovations, not because of their technical properties, but because of the sheer number of others that have already made the adoption. The bandwagon effect would appear to be related to the ‘observability’ characteristics of an innovation discussed above. O'Neill


et al. (1998) make use of this effect in explanation of observed patterns of diffusion of business strategies across various commercial organisations. Nature of the Communications Channels Acts of communication are a necessary part of any change process and an innovation can be seen as a special type of communication concerned with the transmission of new ideas (Kaplan 1991). Communication can be considered to consist of six elements: the source of the message, the content of the message, the channel used, the timing of the message, the purpose of the message, and the location where the message is received (Spann-Merchant 1998). To reach a potential adopter the innovation must be diffused through a communications channel. Channels involving mass media are often the most rapid and efficient means of spreading awareness of an innovation, but interpersonal channels are generally more effective in persuading someone to accept a new idea. This is especially the case, Rogers posits, when the potential adopter can identify easily with the change agent. He uses the term homophily to describe the degree to which the interacting individuals are similar in attributes, such as socio-economic status, education and beliefs. Rogers’ research suggests that the more homophilious (similar) these individuals are, the more effective the communication and the more likely the innovation is to be adopted. An exception occurs where the individuals have an identical technical grasp of the innovation, as in this case no diffusion can occur because there is no new information to exchange between these people. Rogers also proposes that cosmopolite channels of communication (- those from outside the social system) are relatively more important than local channels at the knowledge stage of the innovation-decision process, whereas local channels are important at the persuasion stage21. In line with this, Fullan and Stiegelbauer (1991) note that their research showed that for teachers, other teachers are the preferred source of new ideas. Innovation diffusion makes use of the concept of a change agent, which can be defined as:

“... an individual who influences clients’ innovation-decisions in a direction deemed desirable by a change agency.” (Rogers 1995 :335)

Change agents have to ensure that a need for change is developed, establish an information-exchange relationship, and create an intent for change in the client. This intent must then be translated into action and the adoption stabilised to prevent discontinuance of the innovation22 (Rogers 1995). Another important group involved in the adoption of an innovation is opinion leaders. Rogers (1995) notes that change agents sometimes mistake innovators for opinion leaders, but that whereas opinion leaders must of necessity have followers, innovators are just the first to adopt a new idea. Rogers’ research suggests that followers tend to seek advice from opinion leaders who they perceive as more technically competent than themselves (Rogers and van Es 1964; Rogers 1995). They seek opinion leaders who they see as more innovative and cosmopolite, having higher socio-economic status, more formal education, a greater degree of mass media exposure and greater change agent contact. Two models (Rogers 1995) of communication flow can be considered in relation to the mass media: a hypodermic needle model which postulates that the mass media has an immediate, powerful and direct effect on its audience, and a two-step flow model in which it

21 These stages, which relate to the ‘passage of time’, are discussed later. 22 The similarity of this sequence to that offered in the Lewin/Schein change model (Schein 1961) should be

noted.


is held that opinion leaders first get information from the media and then pass it on to their followers. Rogers argues that an understanding of communication flows through interpersonal networks is enhanced by examining concepts of homophily and heterophily, and reiterates that the exchange of ideas occurs most frequently between individuals who are alike. The role of a change agent is to work through opinion leaders in order to close the heterophily gap with their clients as:

“... in deciding whether or not to adopt an innovation, individuals depend mainly on the communicated experience of others, much like themselves, who have already adopted.” (Rogers 1995 :304)

The experience of near peers is thus important in deciding whether or not to adopt an innovation, but in finding out about an innovation distant acquaintances are more important as they are likely to have information the potential adopter does not already have. Rogers thus proposes that:

“...there is a strength of weak ties component in networks that convey information about an innovation, and a ‘strength of strong ties’ in networks that convey interpersonal influence.” (Rogers 1995 :311)

Early diffusion research was based on a linear model of communication where the innovation is passed directly from a sender to a receiver. In this case the innovation was either adopted as proposed or else it was not adopted at all. In the 1970s, researchers began to study the concept of re-invention of innovations (Rogers 1995). In this sense, re-invention refers to:

“... the degree to which an innovation is changed or modified by a user in the process of its adoption and implementation.” (Rogers 1995 :17)

Rogers (1995) suggests that, in almost all cases, a considerable degree of re-invention does occur and so rather than a linear model of communication, a convergence model would perhaps be more appropriate. This corresponds to Pitman’s (1981) thesis that educational innovations are necessarily distorted and adapted by teachers during their adoption. Whereas linear models may be appropriate to describe certain acts of communication, Rogers offers instead a convergence model in which the participants create and share information with one another in an attempt to reach a mutual understanding (Rogers and Kincaid 1981). He maintains that, when faced with an innovation, people first seek information from near peers. They especially ask for their peers’ subjective evaluations of the innovation. These views are exchanged through a convergence process involving interpersonal networks (Rogers 1995) as the diffusion of innovations is essentially a social process involving the communication of subjectively perceived information.

“The meaning of an innovation is thus gradually worked out through a process of social construction.” (Rogers 1995 :xvii)

Much innovation diffusion research is based on a classical model (Ryan and Gross 1943) in which the innovation originates from some expert source and then diffuses down as a complete package to potential adopters (Havelock 1971; Schön 1971). Rogers says that although originally subscribing to this model, his more recent research has shown that many systems do not operate in this way at all, but rather involve the spread of ideas via peer networks. In this case, there is often a high degree of re-invention as different users adapt the innovation to suit their needs (c.f. Pitman 1981). He maintains however, that for innovations involving a high level of technical expertise, a decentralised diffusion system may be less appropriate than a more centralised system (Rogers 1995 :368). Centralised and decentralised diffusion systems are illustrated in Figure 3.5 below.


Figure 3.5 Centralised versus decentralised diffusion systems - adapted from Rogers (1995 :368)

The Passage of Time Rogers argues that time is involved in three aspects of innovation diffusion: the innovation-decision process, the degree of innovativeness, and an innovation’s rate of adoption. He outlines five main time-dependant steps in the innovation-decision process that the adopter must pass through as: • Knowledge - finding out about the innovation. • Persuasion - forming a favourable or unfavourable attitude towards the innovation. • Decision - the adoption or rejection choice. • Implementation - putting the innovation to use. • Confirmation - seeking reinforcement to continue, or reversing the decision. Rogers (1995) argues that people can only become aware of an innovation by accident since they cannot actively seek an innovation until they knows that it exists. He further argues that people:

“... tend to expose themselves to ideas that are in accordance with their interests, needs, and existing attitudes.” (Rogers 1995 :164)

and avoid those that are in conflict with these. He notes Festinger’s (1957) view that human behaviour is motivated largely by a state of ‘internal disequilibrium or dissonance’, and that people seek to eliminate this uncomfortable state of mind by changing their attitudes, knowledge or actions. This, however, begs the question of how needs are created (Franklin 1990; Tatnall 1993) and whether needs precede finding out about the new idea, or whether some knowledge of an innovation creates the need. Hassinger (1959) has argued that no one exposes themselves to messages about an innovation unless they first feel a need for it. Rogers (1995) makes a number of generalisations about the characteristics of those people who find out about innovations earlier than other people. He contends that these ‘earlier

Adopters

R&D

Change agent

Opinion leaders

Centralised diffusion system

Local innovators Local innovators Local innovators Adopters

Decentralised diffusion system


knowers’ typically have more formal education, higher socio-economic status, more exposure to both mass media and interpersonal channels of communication, more change agent contact, more social participation, and are more ‘cosmopolite’ than ‘later knowers’. Furthermore, in common with many other earlier researchers, Rogers (1995) has found that different individuals in a social system do not necessarily adopt an innovation at the same time. Borrowing from the work of Deutschmann and Fals Borda (1962) he proposes that adopters can be classified in their degree of ‘innovativeness’ into five categories as: innovators, early adopters, early majority, late majority and laggards, and that if the number of individuals adopting a new idea is plotted over time it usually follows a normal, bell-shaped curve (Figure 3.6). Rogers maintains that:

“We expect a normal adopter distribution for an innovation because of the cumulatively increasing influences upon an individual to adopt or reject an innovation, resulting from the activation of peer networks about the innovation in a system.” (Rogers 1995 :259)

When plotted as a cumulative frequency the result is an S-shaped curve and other writers (including Mahajan and Peterson (1985)) have examined and modelled the mathematics of these S-shaped curves.

Figure 3.6 Categories of Adopters - adapted from Rogers (1995: 262)

From his research Rogers proposes a further set of generalisations about the characteristics of earlier adopters of an innovation. In building a picture of these people he contends that earlier adopters typically are more literate and less dogmatic, have more formal education, higher aspirations, a higher degree of social status, more upward mobility, greater empathy, greater rationality, more intelligence, greater knowledge of innovations, greater exposure to mass media and interpersonal channels of communication, more change agent contact, greater social participation, a higher degree of opinion leadership and a more favourable attitude towards science and to change than later adopters. He argues that the earlier adopters are also more cosmopolite, less fatalistic, better able to cope with abstractions, uncertainty and risk, more likely to seek information about innovations, and tend to belong to larger organisations that later adopters. His research also suggests that late adopters are more likely to discontinue use of an innovation, but that the two groups do not seem to display age differences. The Social System In the innovation diffusion paradigm diffusion occurs within a social system in which the social structure constitutes a boundary, and it is inside this boundary that the innovation

Early majority

Late majority

Innovators

Laggards Early adopters

2.5% 13.5% 34% 34% 16%

Number adopting

Time


diffuses. This paradigm thus accepts concepts from the social construction of technology, and is based on the idea that technology is shaped by social factors.

“Technology is a product of society, and is influenced by the norms and values of the social system.” (Rogers 1995 :139)

An important consideration in the social system is the degree of homophily between its individual members. Rogers (1995) argues that when they share similar interests more effective communication can occur between people. He notes however, that when all the people involved have the same technical understanding of an innovation there can be no new ideas and so diffusion cannot occur. Some degree of heterophily is thus required. Research on ‘cultures of teaching’ (Nias 1988; Hargreaves 1992; Hargreaves and Fullan 1992; Sikes 1992) relates to this concept of diffusion within a social system. Rogers maintains that for an idea-only innovation which does not have a material referent, its social construction through interpersonal communication with others is especially important. Abrahamson and Rosenkopf (1997) argue that social network effects bear a measure of responsibility for the extent of innovation diffusions in many organisations. Their arguments also relate to discussions of innovation infusion that will be considered shortly. Generating Innovations: the Innovation-Development Process Rogers (1995) identifies six main phases in the process of developing an innovation: recognition of a need, research to find an innovation to fulfil the need, development of the innovation, commercialisation and marketing, diffusion and adoption, and consequences (anticipated and unexpected) of the innovation. As previously discussed, many of the studies of innovation in schools make use of a research, development and dissemination model (Havelock 1971) very like the one described by Rogers above, and hence subscribe to innovation diffusion. In an example of problems encountered in commercialisation Rogers quotes the case of the failure in technology transfer of the microcomputer from Xerox PARC23 in the 1970s. This research centre had everything going for it: an outstanding collection of R&D personnel, sympathetic management, and an environment where technological innovations were used and encouraged. A lot of good ideas came out of Xerox PARC but few if any of these were commercialised by Xerox. Rogers concludes that the Xerox Corporation’s image of itself as being in the ‘paper copier business’ was an impediment to the transfer of microcomputer technologies from this very expensive R&D centre to Xerox’s manufacturing and marketing/ sales divisions. Information Technology Infusion The adoption, or otherwise, of IT innovations by organisations is of considerable financial and strategic importance, and hence issues involved with IT adoption have always been subject to a considerable amount of research. Whilst the successful adoption of an innovation necessarily implies that it be used to some extent by the organisation, the required level of this use has not been clearly defined in the innovation literature. In recent years a number of researchers (Sullivan 1985; Cooper and Zmud 1990; Zmud and Apple 1992; Saga 1994; Saga and Zmud 1994) have begun to make a distinction between the spread of an innovation among organisations: diffusion, and the embedding of IT deep

23 Pal Alto Research Centre, California.


within a given organisation: infusion. Within a technologically inclined educational institution like RMIT the concept of innovation infusion could have some relevance. The notion of IT infusion can be used (Linderoth 1997) to characterise the situation where the full potential of an IT innovation is being used with beneficial effects by an organisation. It could be described (Saga 1994) as the deep and comprehensive embedding of IT within the organisation so that it is used to its full potential to increase the organisation’s effectiveness. Kishmore and McLean (1998) distinguish between diffusion and infusion by using the dimension of breadth to describe the extent of the diffusion of an innovation among different organisations, and depth to examine how well it has infused into a specific organisation. IT infusion can thus be defined as follows:

“The degree to which IT has penetrated a company in terms of importance, impact, or significance. ... A company with a low degree of IT infusion finds that computers are not strategic to its business. A firm with a high degree of infusion finds that technology is crucial.” (Sullivan 1985 :23)

A model built by Kwon and Zmud (1987) and Cooper and Zmud (1990) outlines IT innovation as a six-stage process involving: initiation, adoption, adaptation, acceptance, routinisation and infusion. The last stage they considered being by no means the least important. How well IT infusion occurs was the subject of research by Saga (1994) who found that the degree to which the organisation was able to re-conceptualise tasks and so relate them to something that could benefit from IT, along with its beliefs about the technology’s usefulness, seemed to be the main determinants of IT infusion. Kishmore and McLean (1998) suggest that looking for the use of words like ‘incorporation’, ‘institutionalisation’, and ‘routinisation’ in an organisation’s printed texts can help to indicate its level of IT infusion. Patnayakuni and Rai (1998) distinguish between technical, administrative and informational infusion.

“Infusion in the technical core is defined as ‘the degree to which tasks are to focus on the efficiency and effectiveness of processes’ ... Infusion in the administrative core is defined as ‘the degree to which collaboration and empowerment are present’ ... Infusion in the informational core is defined ‘as the degree to which management processes are fact-based’.” (Patnayakuni and Rai 1998 :751)

Although there is a relationship between diffusion and infusion it should be noted (Sullivan 1985) that an organisation can have a high level of IT diffusion without having a correspondingly high level of IT infusion. Given the financial benefits of a good information system and the already considerable spread of IT into most organisations, the concept of innovation infusion is likely to become more important in the future. Innovation Diffusion Research Traditions and Topologies Innovation research began in the United States in the field of rural sociology (Ryan and Gross 1950) and has since spread to many different fields and research traditions including education, public health and medical sociology, communications, geography, general sociology, economics, management, information technology and marketing. Rogers (1995) claims however, that despite their different approaches, each ‘invisible college’ has come up with remarkably similar findings including the fact that the diffusion of an innovation seems to follow an S-shaped curve over time and that early adopters generally had higher socio-economic status than late adopters. Rogers notes that in educational research most diffusion studies involved the spread of new teaching ideas such as team-teaching, modern mathematics and programmed instruction in schools, and that data was typically gathered using questionnaires and interviews. In these studies the main unit of analysis tended to be


school systems, teachers or administrators. He remarks that although education represents an important diffusion research tradition in terms of the number of studies that have been completed, it has been less important in its contribution to the theoretical understanding of innovation diffusion. Rogers (1995) offers a typology of the types of analyses encountered in diffusion research indicating that these can be classified into the following groups: earliness of knowing about innovations, rate of adoption of different innovations in a social system, innovativeness of members of a social system, opinion leadership, diffusion networks, rate of adoption in different social systems, communication channel use, consequences of innovation, and other studies. He notes that research on innovativeness accounts for about 58% of all innovation diffusion research. Research Biases and Criticisms of the Innovation Diffusion Model Several critics (Rogers and Shoemaker 1971; Downs and Mohr 1976) warn that a serious shortcoming in diffusion research is its pro-innovation bias, which is the implication that a given innovation ought to be diffused and subsequently adopted by all members of the social system involved, and that the innovation should diffuse rapidly without being either rejected or re-invented. Following this assumption, an innovation must necessarily lead to some form of improvement in the lives of those who adopt it. Rogers (1995) notes that this clearly is not always the case and that a number of innovations, such as cigarettes, nuclear weapons and crack cocaine, could be considered to be ‘bad innovations’ that do not lead to what most people would consider to be improvements. Rogers (1995) warns that pro-innovation bias can sometimes lead a researcher to make unwarranted assumptions that a given innovation should have been taken up, and so waste time trying to find out why it was not. He notes that in much published innovation diffusion research a consideration of pro-innovation bias is often only assumed or implied rather than clearly stated. He maintains that this bias is probably advanced because most studies tend to be of successful innovations where the relative advantage of adoption was high. Another criticism involves what Rogers, and others, call individual-blame bias (Caplan and Nelson 1973; Rogers 1995) where it is automatically assumed that the non-adoption of an innovation is the fault of certain individuals rather than the system of which the individuals form a part. Those individuals who are slow to adopt an innovation are most likely to be individually blamed. Coleman (1958) argues that individual-blame bias results in a focus on the individual as the unit of analysis in diffusion research at the expense of that individual’s network relationships. The converse, system-blame bias, is also a potential problem. In system-blame bias the system is always considered to be at fault and so responsible for the problems of individual system members. A considerable amount has been written on the subject of innovation in general, and educational innovation in particular. In this chapter I have selectively examined several models of how innovation and change are believed to occur, beginning with the ‘research, development and dissemination’ model commonly used in describing many educational innovations. I also reported on change models proposed by Schein (1961), Kolb and Frohman (1970), Fullan and Stiegelbauer (1991), Pitman (1981), and Stark and Luttuca (1997). Given its importance in the literature, however, the bulk of the chapter has been given over to a discussion of the theory of innovation diffusion (Rogers 1995).


Innovation diffusion is a widely accepted theory of how innovation occurs. It is used in many different disciplines and it offers some useful tools for describing innovation processes. Although much of the work on innovation in education is based on innovation diffusion models, in describing the adoption and retention of Visual Basic in the Information Systems curriculum at RMIT I will contend that another model, that of innovation translation (Latour 1986), provides an account which avoids much of the essentialism of diffusion theory. The next chapter deals with innovation translation, informed by actor-network theory.


Chapter 4

Innovation Translation The actor-network approach to innovation theory

An alternative view of innovation to that offered by innovation diffusion is proposed in actor-network theory (ANT). The core of the actor-network approach is translation (Law 1992), which can be defined as:

“... the means by which one entity gives a role to others.” (Singleton and Michael 1993 :229)

A common approach to researching innovation in Information Systems is to focus on the technical aspects of an innovation, and to treat ‘the social’ as the context in which its development and adoption take place. Approaches of this type which contend that only the ‘most appropriate’ innovations are adopted, and that only those ‘sensible people’ who make these adoptions go on to prosper, assume that all outcomes of technological change are attributable to the ‘technological’ rather than the ‘social’ (Grint and Woolgar 1997). At the other extreme social determinism holds that relatively stable social categories can be used to explain technical change (Law and Callon 1988) and concentrates on the investigation of social interactions, relegating the technology to context; to something that can be bundled up and forgotten. This bundling means that fixed and unproblematic properties or ‘essences’ can then be assigned to the technology and used in any explanation of change. In this chapter I set out to describe how innovation translation offers a different perspective on innovation, one which I contend has more to offer to what is being investigated in this study. The chapter begins by describing how diffusion theory, and much Information Systems innovation research, is based on essentialist notions that require the attribution of specific properties to human or technological entities. I discuss difficulties that result when subscribing to these notions and propose the adoption of an actor-network approach using innovation translation as a possible solution. A description of the main tenets of actor-network theory follows, along with details of the mechanisms of innovation translation and how this approach largely avoids the need to resort to essentialist assumptions about people and things. The two models of innovation, although displaying some similarities, have quite different bases which I will proceed to examine and compare.

Essentialist Approaches to Technological Innovation It was shown in the previous chapter that the dominant paradigm in innovation research is that of innovation diffusion, and that most of the studies of innovation in Information Systems and education make use of this approach. Innovation diffusion is based on the notion that an innovation involves the spontaneous or planned spread of new ideas (Rogers 1995) and asserts that a technological innovation embodies ‘information’: some essential capacity or ‘essence’, that is largely responsible for determining its rate of adoption (Chapter 3). A significant problem with an essentialist paradigm like innovation diffusion arises if a researcher tries to reconcile the views of all parties involved in the innovation on what particular essences constitute any given actor. The difficulty is that people often see different ‘essential attributes’ in any specific technological or human entity, and this makes it difficult for a researcher to identify and settle on the ones that allegedly were responsible for the diffusion.


As an illustration of this point Bigum (1998b) contends that the assignment of intrinsic properties to technology, and in particular to computers in an educational setting, has the effect of allocating specific roles to the people and institutions that use them. Building on an argument propounded by Grint and Woolgar (1997), he contends that essentialist accounts which distinguish between human and non-human elements are forced to treat the machine as something with a set of fixed, intrinsic properties, and the human elements as a context within which the technology is used. The problem, he points out, is that there does not appear to be a single essence of computers in education upon which everyone can agree. Some educators see the computer as embodying the ‘future of learning technology’, some as a pointer towards ‘anti-schooler’ discourses, others see it in terms of concerns about the deployment of technology in Western society, and still others in the negative light of all that is bad about dependence on technology. Any attempt at an essentialist approach, Bigum claims, would have trouble explaining how the ‘essential characteristics’ of a computer could be seen quite differently by these different groups. He argues instead for an anti-essentialist approach based on innovation translation from actor-network theory in which, rather than containing essences, both human and non-human entities constitute roles for each other and work towards the establishment of durable assemblages. Such an approach while still allowing the technology to negotiate a role, removes the necessity to make the concession of accepting some innate property within the technology that determines its fate. Anti-essentialism, which Chagani (1998) names as a characteristic of postmodern scholarship, rejects the idea of categorisations like ‘human nature’ and denies the existence in human beings of essences, natures or any other universals that “place a grounded and constant meaning on existence” (Chagani 1998 :2). An essentialist position, according to Haslam (1998), would have it that forms of human diversity: ‘human kinds’ or ‘social categories’, can be understood in ways that relate to the natural domain. In a rather biological way different ‘kinds of people’ are then taken to have inherent, fixed, identity-determining essences, a view that few scholars now accept in relation to humans (Haslam 1998; Epstein 1998). Most of the essentialist versus anti-essentialist debate has been about the presence, or otherwise of essences in humans, but this debate has also been extended to non-humans. Grint and Woolgar (1997) contend that most views of technology attribute an “essential inner core of technical characteristics” (Grint and Woolgar 1997 :9) to the non-human elements, while portraying the human elements as secondary and transitory. Objecting to any implicit endowment of inherent properties in the technology they propose that many other factors need to be taken into account in order to understand the impact of technology.

“These other aspects include our attitudes towards technology, our conceptions of what technology can and cannot do, our expectations and assumptions about the possibilities of technological change, and the various ways in which technology is represented in the media and in organizations.” (Grint and Woolgar 1997 :6)

They contend that contemporary ideas of technology often still rely on the idea of an essential capacity within a technological entity which accounts for its degree of acceptance or rejection. They remark that the idea of Deus ex machina24 is still alive and well accepted in the way in which many people see technology, and argue for an anti-essentialist view of technological innovation. Arguing for a social constructivist approach in which technology is attributed no influence that can be gauged independent of human explanation, they maintain that technology is best thought of as being constructed entirely through human

24 The concept of a ‘god within the machine’.


interpretation. They also reiterate the difficulty of sustaining the idea of a boundary between human and non-human actors, and note that it may be better to think in terms of the human and non-human aspects of technology being linked in some kind of network rather than as separate systems. Bromley (1997) argues that as long as ‘technology’ is seen as a distinct type of entity which is separate from ‘society’ the question will always need to be asked ‘does technology affect society or not?’ One answer to this question is that it does, but this leads us to the technological determinist position of viewing technology as autonomous and as having some essential attributes that act externally to society. The other answer: that it does not, means that technology must be neutral and that individual humans must assign it their own values and decide on their own account how to use it. This view is close to a social determinist position. Bromley maintains that neither answer provides a useful interpretation of how technological innovation operates, and argues against an either/or stance like this. He argues that we should abandon the idea that technology is separate from society. Approaches Involving Social Constructivism and Actor-Network Theory Brey (1997) proposes that rather than relying on some ‘inner technological logic’, technological change is best understood by reference to technological controversies, disagreements and difficulties with which the actors involved in the change are concerned. He argues for an approach using some form of social constructivism, in which the researcher does not need to evaluate claims made by different groups about any ‘real’ properties of the technology being studied. He cautions, however, that if an approach like this is used, one cannot then invoke such properties to explain technological change. Instead, change must be explained by interpretations of the different groups involved in it, after a series of controversies and negotiations. Brey then classifies social constructivist approaches into three groups: strong social constructivism, mild social constructivism, and actor-network theory. In strong social constructivism, which is aligned most closely with the sociology of scientific knowledge (SSK) approach of scholars like Collins (1992), technology is explained as a social construction, and technological change by reference to social practices such as interpretation, negotiation and closure of the actors involved. It supports a division between social, natural and technical entities, but attributes no properties, powers or effects to the technology itself. Approaches using mild social constructivism often go under the name ‘social shaping’. Brey (1997) notes that these approaches also retain conventional distinctions between the social, natural and technical, and attempt their explanations by examining ways that social factors shape technology. Social shaping allows a role for non-social factors in technological change and is willing to attribute properties and effects to the technology although it claims that, as technology is socially shaped, these properties and effects are largely built in through factors relating to the social context (Brey 1997). Latour et al (1992 :56) note that the issue of anti-essentialism, in the sense of there being some difference in essence between humans and non-humans, is a major contention between actor-network theory and the sociological position of SSK. They argue that SSK sees it necessary to recognise in advance the essences of humans and of social organisations, and to distinguish their actions from the inanimate behaviour of technological and natural objects. Actor-network theory sees things quite differently.

“We believe that both essence and differentiation are the result of attribution work and can be studied empirically.” (Latour, Mauguin et al. 1992 :56)


ANT considers both social and technical determinism to be flawed and proposes instead a socio-technical account (Callon and Latour 1981; Latour 1986; Law and Callon 1988) in which neither social nor technical positions are privileged. In this socio-technical order nothing is purely social and nothing is purely technical (Law 1991). What seems, on the surface, to be social is partly technical, and what may appear to be only technical is partly social. ANT deals with the social-technical divide by denying that purely technical or purely social relations are possible. It offers the notion of heterogeneity to describe projects such as the use of a programming language, database management system, barcode scanner, human programmer and operator in the construction of a computer system for use in stock control in a supermarket. The utilisation of heterogeneous entities (Bijker, Hughes et al. 1987) then avoids questions of: ‘is it social?’ or ‘is it technical?’ as missing the point, which should be: “is this association stronger or weaker than that one?” (Latour 1988b :27). Longenecker et al. agree that regarding Information Systems as only technical entities is too simplistic.

“Computer based information systems are complex socio-technical entities that have taken on critical roles in local, national and global organizations.” (Longenecker, Feinstein et al. 1994 :175)

Actor-Network Theory To address the need to treat both human and non-human actors fairly and in the same way, actor-network theory is based upon three principles: agnosticism, generalised symmetry and free association (Callon 1986b). The first of these tenets, agnosticism, means that analytical impartiality is demanded towards all the actors involved in the project under consideration, whether they be human or non-human. Generalised symmetry offers to explain the conflicting viewpoints of different actors in the same terms by use of an abstract and neutral vocabulary that works the same way for human and non-human actors. Neither the social nor the technical elements in these ‘heterogeneous networks’ (Law 1987) should then be given any special explanatory status. Finally, the principle of free association requires the elimination and abandonment of all a priori distinctions between the technological or natural, and the social (Callon 1986b; Singleton and Michael 1993).

“ANT was developed to analyse situations in which it is difficult to separate humans and non-humans, and in which the actors have variable forms and competencies.” (Callon 1999 :183)

In summary, under the principles of agnosticism, generalised symmetry and free association, actor-network theory attempts impartiality towards all actors in consideration, whether human or non-human, and makes no distinction in approach between the social, the natural and the technological. As Callon puts it:

“The rule which we must respect is not to change registers when we move from the technical to the social aspects of the problem studied.” (Callon 1986b :200)

A feature of actor-network theory is its dislike of large scale, ‘obvious’, tautological answers to problems; answers like “the thing doesn’t work because it couldn’t have worked” (Latour 1996 :121) or, in the terms of this study, ‘Visual Basic was adopted because its time had come’, or ‘Visual Basic developed enough momentum to make its adoption inevitable’. It prefers instead to look at the suggestions offered by the actors themselves. It insists that, apart from the capacity of actors to negotiate and enrol other actors, no a priori assumptions are made about the matter under investigation, and attempts an understanding on the basis of studying the set of complex negotiations and trade-offs performed by the actors. It has no problem with complexity because it is through this


complexity that it is able to avoid having to resort to large scale ‘answers’. Law warns against the process of explanation by labelling, noting that any attempt at naming does analytical work. It “strains to perform simplicity” (Law 1997 :12) and pushes entities towards singularity. He warns that as complexity is lost in the process of labelling we should be loath to resort to it. In actor-network theory, an actor is any human or non-human entity that is able to make its presence individually felt (Law 1987) by the other actors. An actor is made up only of its interactions with these other actors (de Vries 1995), and Law (1992) notes that an actor thus consists of an association of heterogeneous elements constituting a network. Callon (1986a) argues that an actor can also be considered, at times, as a black box, as we do not always need to see the details of the network of interactions that is inside it. The concept of a network is an important one in actor-network theory and will be further discussed in the next chapter. ANT also attempts to do away with binaries like far/close, macro/micro and inside/outside (Latour 1997). The point is not whether the various elements of a network are in close physical proximity or not. Rather it is how they are interconnected that matters. In considering macro/micro distinctions Latour (1997 :3) maintains that one network is never ‘bigger’ than another, but simply ‘longer’ or more intensely connected. Concepts like outside or inside make no sense as a network is made up only of interconnections; it has only a boundary without an inside or an outside. What is important is whether or not a connection has been established between elements. In ANT the passage of time also loses much of its importance and becomes just a consequence of the formation of alliances between actors rather than a fixed explanatory framework (Latour 1991). Latour argues that for every ‘socio-technical imbroglio’ (Latour 1988) two dimensions are involved in the formation of its definition: the number of people who are convinced that it can be considered as an uncontroversial black box, and what sorts of translations it must undergo to convince still more people of this. Once a network is formed however, that is not the end of the story as networks are always unreliable and can become unstable. Callon (1987) further proposes that entities become strong and stable by gathering a ‘mass of silent others’ to give them greater strength and credibility. A network becomes durable partly due to the durability of the bonds that hold it together, but also because it is itself composed of a number of durable and simplified networks.

“The solidity of the whole results from an architecture in which every point is at the intersection of two networks: one that it simplifies and another that simplifies it.” (Callon 1987 :97)

In ANT, materiality and sociality are seen as producing themselves (Mol and Law 1994), but networks are fragile and transient things and are only able to extend their life and become more durable by being inscribed in material form (Dent 1996). Entities that compose networks are often converted into inscriptions or devices (Callon 1986a) such as documents, reports, academic papers, models, books, and computer programs. Latour uses the term ‘immutable mobile’ to describe these things which, when they are moved around, remain stable and unchanged (Singleton and Michael 1993; Mol and Law 1994). An immutable mobile helps to extend the network by enrolling new actors.

“Strength does not come from concentration, purity and unity, but from dissemination, heterogeneity and the careful plaiting of weak ties.” (Latour 1997 :2)


Latour (1997) notes that actor-network theory is not about traced networks, but about the activity of network tracing. He maintains that a network cannot exist independently of the act of tracing it, and that it should be thought of not so much as a thing, but as the recorded movement of a thing. He contends that there is no difference between the explanation of some project, and telling the story of how a heterogeneous engineer (Law 1987) mobilises actors, and a network subsequently surrounds itself with new resources. Of networks, he notes that:

“... by their very growth they become more and more of an explanation of themselves.” (Latour 1997 :8)

Actor-network theory, or the ‘sociology of translations’ (Callon 1986; Law 1992), is concerned with studying the mechanics of power as this occurs through the construction and maintenance of networks made up of both human and non-human actors. It is concerned with tracing the transformation of these heterogeneous networks (Law 1991) that are made up of people, organisations, agents, machines and many other objects. It explores the ways that the networks of relations are composed, how they emerge and come into being, how they are constructed and maintained, how they compete with other networks, and how they are made more durable over time. It examines how actors enlist other actors into their world and how they bestow qualities, desires, visions and motivations on these actors (Latour 1996). Law and Callon put it this way:

“Our object, then, is to trace the interconnections built up by technologists as they propose projects and then seek the resources required to bring these projects to fruition.” (Law and Callon 1988 :285)

The Innovation Translation Model Callon et al. (1983) propose that translation involves all the strategies through which an actor identifies other actors and arranges them in relation to each other. Latour (1996) speaks of how ‘chains of translation’ can transform a global problem, such as the transportation needs of a city like Paris or, in the context of this study, like the design of the RMIT business programming curriculum, into a local problem like continuous transportation, or use of the data control in Visual Basic. The model of translation as proposed in actor-network theory proceeds from a quite different set of assumptions to those used in innovation diffusion. Latour (1986) argues that the mere ‘possession’ of power by an actor does not automatically confer the ability to cause change unless other actors can be persuaded to perform the appropriate actions for this to occur. The notion that power is an attribute that can be possessed by an actor is an essentialist one, and Latour contends that rather than this it is the number of other people who enter into the situation that indicate the amount of power that has been exercised (Latour 1986). He maintains that in an innovation translation model the movement of an innovation through time and space is in the hands of people, each of whom may react to it in different ways. They may accept it, modify it, deflect it, betray it, add to it, appropriate it, or let it drop (Latour 1986). He adds that this is true for the spread of anything from goods and artefacts to claims and ideas. In this case the adoption of an innovation comes as a consequence of the actions of everyone in the chain of actors who has anything to do with it. Furthermore, each of these actors shapes the innovation to their own ends, but if no one takes up the innovation then its movement simply stops; inertia cannot account for its spread. Instead of a process of transmission we have a process of continuous transformation (Latour 1996) where faithful acceptance involving no changes is a rarity requiring explanation.


“Instead of the transmission of the same token – simply deflected or slowed down by friction – you get ... the continuous transformation of the token.” (Latour 1986 :286)

McMaster et al. (1997) add that innovations do not wait passively to be invented or discovered, but are instead created:

“... from chains of weaker to stronger associations of human and non-human alliances. ... Each actant translates and contributes its own resources to the shape and ultimate form of the emerging black box.” (McMaster, Vidgen et al. 1997 :4)

This occurs, they note, by virtue of the ‘relative convergences’ of their respective interests. The amount of control that can be exercised by any individual actor over this process is, of necessity, limited as translation “entails metamorphosis and loss of sovereignty” (McMaster, Vidgen et al. 1997 :4) no matter how much this actor wants to retain control. Latour (1986) stresses that it is not just a matter of each of the actors in the chain either resisting the innovation or transmitting it in the same form that they received it, but that their shaping of the innovation is essential for its continued existence. In this they are actors, not just clients, and everyone involved translates, or shapes the innovation according to their own needs. In doing this the converging interests of these actors, that at first are only “an assembly of disorderly and unreliable allies”, slowly evolves into “something that closely resembles a black box” (Latour 1987 :130-131). The addition of each new ally contributes to the ultimate form of the emerging black box (McMaster, Vidgen et al. 1997) as the chain is strengthened and the network lengthens over space and time due to the translation of the innovation. A translation model requires the focus to be on understanding how actor-networks are created, strengthened and weakened, rather than on causes and effects. The key to innovation is the creation of a powerful enough consortium of actors to carry it through, and when an innovation fails to be taken up this can be considered to reflect on the inability of those involved to construct the necessary network of alliances amongst the other actors (McMaster, Vidgen et al. 1997). Getting an innovation accepted calls for strategies aimed at the enrolment of others in order to ensure the creation of the black box. Latour (1986) maintains that this is done by ‘interesting’ others and then getting them to follow our interests, so becoming indispensable to them. This process is facilitated if other possibilities are first blocked off.

“The work of generating interest consists in constructing these long chains of reasons that are irresistible, even though their logical forms may be debatable.” (Latour 1996 :33)

As an example of the innovation translation approach, Latour (1991) describes a hypothetical innovation relating to the return of hotel keys. In many European hotels guests are encouraged to leave their room keys at the hotel desk by the attachment of large cumbersome weights to these keys. Latour proposes that a hypothetical hotel manager wishing to convince his guests to leave their room keys at the hotel desk, may have begun by issuing verbal requests to guests when they checked in. The probable result was that some guests did as they were asked but that others took no notice and, as a follow-up, he puts written notices in all hotel rooms. This time a few more of the guests follow the advice, but not all. Finally, to convince the last few remaining recalcitrant guests he decides to attach a large metal weight to each set of keys. This does the trick and all keys are returned. At each stage of this ‘program of action’ more of the guests are convinced, and as the program has caused a change in guest attitude it can be considered to have been effective against the ‘anti-programs’ of resistance by some guests. But the order that was obeyed by customers after the addition of weights to the keys is no longer the same as the original order; at each stage it has been translated into a new form. Latour argues that in


describing the adoption of an innovation it is necessary to consider both the succession of actors that transport the innovation, and the succession of transformations that it undergoes.

“Innovations have to interest people and things at the same time; that’s really the challenge.” (Latour 1996 :56)

Innovation Translation and Innovation Diffusion In comparing the diffusion and translation models, Latour (1986) contends that in a diffusion model an innovation is endowed with its own form of inertia and propelled from a central source. This enables it to move through space and time without the need for further explanation and makes it unstoppable except by the most reactionary interest groups.

“... the initial idea emerges fully armed from the head of Zeus. Then, either because its brilliant inventor gives it a boost, or because it was endowed from the start with automatic and autonomous power, it sets out to spread across the world. ... Finally, with the help of some courageous individuals who are open to technological progress, it ends up triumphing, at the price of a few adjustments, thus covering in shame those who hadn’t known enough either to recognise it or welcome it.” (Latour 1996 :118)

In fact what needs to be explained, he contends, is its acceleration or slowing down which must then be due to people: an effective change agent or a backward culture. Diffusion models, he notes, define three important elements in the movement of an innovation: the initial force with which it is launched, the innovation’s inertia, and the medium through which it moves. Once the innovation has been pointed out to people then it should just be a matter of time before everyone, except the most immovable, recognise its advantages (McMaster, Vidgen et al. 1997). The advantage of a diffusion model is that anything can be easily explained by reference to the initial force or the resisting medium (Latour 1986). Innovation diffusion has had considerable success in describing how innovations move, or diffuse, through large populations either to be adopted or to be rejected. This approach lends itself to studies such as the relative rates of adoption of Visual Basic by programmers in different countries around the world, and how they were convinced to make adoption decisions. Innovation diffusion has been useful in explaining the adoption, or otherwise, of curriculum innovations across whole school systems but few studies have used this paradigm in attempting to explain innovations that have occurred within a particular site such as an educational institution or academic department. There are occasions, however, when diffusion does not occur despite the excellence of the idea or the technical quality of the innovation, and the diffusion model finds these difficult to explain. The non-diffusion of the Dvorak keyboard is just such an example and Rogers (1995) suggests that the Dvorak keyboard failed, despite its ‘obvious superiority’ over the QWERTY keyboard, because of ‘vested interests’ supporting its rival. Actor-network theory, on the other hand, would argue that the Dvorak keyboard was not adopted because there were just too many things attached to use of the QWERTY keyboard; it had too many associations to make it feasible for the Dvorak keyboard to un-attach them. Latour (1996) contrasts innovation diffusion with the translation model in which the initial idea hardly counts and the innovation is not endowed with autonomous power or propelled by a brilliant inventor. The innovation has no inertia, and moves only if it interests one group of actors or another. Its movement cannot be caused by an initial impetus as there is none. It is instead a consequence of energy given to it by everyone in the chain. When the innovation does interest a new group they transform it a little or perhaps a lot. Latour notes that, except in rare cases, there can be “no transportation without transformation”, and that:


“... after many recruitments, displacements and transformations, the project, having become real, then manifests, perhaps, the characteristics of perfection, profitability, beauty, and efficiency that the diffusion model located in the starting point.” (Latour 1996 :119)

Latour (1986) remarks that instead of seeing the transmission of the same token which may perhaps have been slightly deflected or slowed down as the diffusion model would have it, the translation model posits the continuous transformation of this token into new forms by all those who touch it.

Diffusion Translation Innovation A technology perceived to be new by

the potential adopter. A technology that has yet to be ‘black-boxed’.

Communication Communication channels can be categorised as cosmopolite or localite, and mass media or interpersonal. Innovations are transferred through these channels.

Translations are made by actors in enrolling the innovation.

Time Speed of decision to innovate, earliness of adoption and rate of adoption are important.

Network dynamics in enrolment, control, and dissemination are what matter.

The Social system

Homophily versus heterophily. Sharing of interests of human actors.

Interessement between actants, both human and non-human, and goals. Black boxes form when interests move in the same direction.

The Technology Changes are made to the form and content of the technology as a result of experiences during implementation (re-invention).

The technology is translated through being enrolled, regardless of whether its form or content is modified.

Socio-technical stance

The social system and the technology are separate. Diffusion is the adoption of technology by a social system. Technology transfer requires the bringing together of social and technical elements.

The social system and the technology are inseparable. Successful innovation and technology transfer gives the appearance of separation, but this is merely evidence that the actor-network has stabilised

Figure 4.1 Innovation diffusion versus innovation translation - adapted from McMaster et al. (1997)

While the translation approach is quite different to the pre-1980s classical view of innovation diffusion in which an innovation is either adopted or not, there seems to be a degree of commonality between aspects of innovation translation and Rogers’ decentralised diffusion system shown in Figure 3.5. This decentralised system is much more network-like and allows the possibilities of acceptance, rejection and re-invention of the innovation. Nevertheless, the basic essentialist tenets of innovation diffusion - that there is some property in the innovation, the society, or the potential adopter that facilitates diffusion, still differ radically from the translation view in which it is the potential adopters who hold the key in their actions. McMaster et al. (1997) argue that diffusion theory is firmly rooted in ‘high modernism’ and as such has an overwhelming desire to link cause and effect. They note that the translation model is not overly concerned with explanations, but in studying the mundane translations that arise. The main differences between the two theories of innovation are summed up in Figure 4.1 above. As an example of how actor-network theory might be applied to an information systems implementation, consider the adoption of Java in a particular World Wide Web systems


development project in a situation where the consultants had no previous experience of this language. An innovation diffusion approach would, in outline, begin with a consideration of the characteristics of Java including its evolution from C++, its degree of object-orientation, the portability of its applications, and so on, and how these characteristics might help or hinder its adoption. It would then look at the channels through which information about the innovation reached the developers: the computer press, university or training courses, friends from other companies, etc, and how effective these were in delivering the message. Next it would consider aspects of the development company relating to its programming ‘culture’; things like what programming languages had been used in the past, the background of the programmers, and the type of applications they had previously developed. On the other hand, innovation translation would concentrate on issues of network formation. It would investigate the human and non-human alliances and networks built up by the consulting company, their programmers, Java, the potential users, and other actors involved in the implementation. It would concentrate on the negotiations that allow the network to be configured by the enrolment of both human and non-human allies, and would consider Java’s characteristics only as network effects resulting from association. Actor-network theory would suggest that it is not any innate properties of Java that are important, but rather network associations such as the extent to which a potential adopter has been enrolled in Java’s possibilities for use in the creation of Web applets and portable applications, that are the significant factors in its adoption. It would look at the process of re-definition in which the programmers tried to seek compromises from Java, and how Java sought to impose definitions of portable applications and Web programming on them; how it ‘interested’ the programmers and then got them to follow its interests, so becoming indispensable to them. In this case what is then finally adopted for this task is not Java as such, but a translation of Java in which it becomes a programming language for use in Web applications.

Mechanisms of Translation An actor-network is configured (Grint and Woolgar 1997) by the enrolment of both human and non-human allies, and this is done by means of a series of negotiations in a process of re-definition in which one set of actors seeks to impose definitions and roles on others (Callon 1986b). Translation can be regarded as a means of obliging some entity to consent to a ‘detour’ (Callon 1986a) that takes it along a path determined by some other entity. Law (1987) uses the term ‘heterogeneous engineer’ to describe the entity that designs and creates these detours. A heterogeneous engineer is then able to speak on behalf of other actors enrolled in the network. The process of translation has four aspects or ‘moments’ (Callon 1986b), the first of which is known as problematisation, or ‘how to become indispensable’. In this stage, a group of one or more key actors attempts to define the nature of the problem and the roles of other actors so that these key actors are seen as having the answer, and being indispensable to the solution of the problem (McMaster, Vidgen et al. 1997). It involves suggesting an equivalence (Law 1997) between two problems: the one proposed by the enrollers and the other by those being enrolled, and requiring those who wish to solve the problem to accept the solution proposed by the other. In other words, the problem is re-defined (translated) in terms of solutions offered by these actors (Bloomfield and Best 1992) who then attempt to establish themselves as an ‘obligatory passage point’ (Callon 1986b) which must be negotiated as part of its solution. They attempt to persuade the other actors that they all


have the same interests (Callon and Latour 1981) and that the answers to their own problems lie in the solutions proposed by the persuaders (Grint and Woolgar 1997).

“More specifically, one actor can make itself indispensable to another by translating a problem of the latter in terms of a solution owned or within the orbit of the former.” (Bloomfield and Best 1992 :541)

To pass through the obligatory passage point the other actors must accept a set of specific conventions, rules, assumptions and ways of operating laid down by the heterogeneous engineer. If this happens then the formation of a stable network will ultimately result. The second moment is interessement, or ‘how allies are locked in place’ and is a series of processes which attempt to impose the identities and roles defined in the problematisation on the other actors. It means interesting and attracting an entity by coming between it and some other entity (Law 1986a). Here the enrollers attempt to lock the other actors into the roles proposed for them (Callon 1986b) and to gradually dissolve existing networks, replacing them by a network created by the enrollers themselves (Grint and Woolgar 1997). It thus attempts to stabilise new identities for the other actors (Singleton and Michael 1993). If the interessement is successful then the third moment, enrolment or ‘how to define and coordinate the roles’ will follow through a process of coercion, seduction, or consent (Grint and Woolgar 1997), leading to the establishment of a solid, stable network of alliances. Enrolment, however, involves more than just one set of actors imposing their will on others; it also requires these others to yield (Singleton and Michael 1993). Finally, mobilisation or ‘are the spokespersons representative?’ occurs as the proposed solution gains wider acceptance (McMaster, Vidgen et al. 1997) and an even larger network of absent entities is created (Grint and Woolgar 1997) through some actors acting as spokespersons for others. Mobilisation requires that these supposed spokespersons are properly able to represent the others and will neither betray them nor be betrayed by them (Callon 1986b). Of course, not all entities will just willingly consent to the proposed detours (Callon 1986a), and in understanding the path taken by an innovation it is necessary to examine the resistance offered by the actors it is able to mobilise and those it rejects or that reject it (Latour 1991). To define the relationship between themselves many actors make use of intermediaries such as texts, technical artefacts, humans with specific skills, and money (Callon 1991). These intermediaries then constitute the ‘form and substance’ (Callon 1992) of the interactions. A network becomes durable when actors feel no need to spend time opening and looking inside black boxes, but just accept these as given. Innovation translation thus offers an approach to theorising innovation that has the advantage of not having to resort to the essentialist notions that are inherent in the diffusion model. An innovation translation approach, informed by actor-network theory, avoids the need to consider the social and the technical, and thus human and non-human actors, in different ways. The next chapter will argue that actor-network theory, and hence innovation translation, provide a suitable methodological approach to this study.


Chapter 5

Methodology The socio-technical nature of IS curricula

This chapter provides a methodological frame for my study and describes how it was performed. It begins with a consideration of Information Systems curriculum as a study of the interaction of people with computer technology, and relates the difficulties inherent in giving due regard to both the human and non-human contributions to IS curriculum innovation. A solution is sought in actor-network theory which is then compared with a number of related research traditions in Information Systems and education. The later part of the chapter describes the research process: how the data was collected and analysed. In systems theory, a system is defined as a group of elements that are integrated with the purpose of achieving some common objective (Emery 1969; Kendall and Kendall 1992). An information system is a complex entity comprising computer hardware, software, people, procedures and data, integrated with the purpose of collecting, storing, processing, transmitting and displaying information (Tatnall, Davey et al. 1998a). The dictionary defines something that is ‘complex’ as being characterised by a combination of interconnected parts, many of which may not be easily separable (Macquarie University 1981) and an information system certainly fits this definition (Bonnici and Warkentin 1995; Agarwal, Krudys et al. 1997). Building an information system is a difficult task, partly due to the problem of ascertaining the requirements of the intended users, but also because of the complexity of human-machine interactions (Banville 1991), and this complexity is reflected in the difficulty of building these systems to operate free from error and to perform as intended (Thomsett 1993). The study of Information Systems is concerned with the ways people build and use computer-based systems to produce useful information, and so has to deal with issues involving both people and machines - with the multitude of human and non-human entities that comprise an information system (Checkland 1981). Studies in Information Systems face the problem of how to handle complexities due to interconnected combinations of computers, peripherals, procedures, operating systems, programming languages, software, data and many other inanimate objects; how they all relate to humans and human organisations, and how humans relate to them (Davis, Gorgone et al. 1997). IS curricula also face the problem of how to deal with rapid, constant and significant changes in computer technology, and differ from most university studies in that they are applied curricula with a high level of dependence on current technology which is in a state of rapid evolution. As a consequence, these curricula need frequent revision (Cougar, Davis et al. 1995). By definition, courses in Information Systems involve the study of a particular machine, the computer, and how humans build systems to make use of this machine to assist in operating and managing their organisations (Tatnall 1993). An Information Systems curriculum typically covers topics ranging from systems analysis, design and programming through to managing the implementation and use of information systems. My research question relates to one aspect of IS curriculum: computer programming. It is concerned specifically with how the programming language Visual Basic found a place in the RMIT Information Systems curriculum, and why it has remained there despite serious challenge. As set out in the first chapter, this is an investigation into how this curriculum innovation occurred, how Visual Basic pushed its way past the other programming languages already present in the curriculum and, in a period of only a year or


two, came from being novel and innovative to an ‘obvious choice’ for use in RMIT Information Systems courses. As seen in Chapter 2, most accounts of IS curriculum provide an overview of the development of complete courses and concentrate on issues like course goals and content, availability of computing and library facilities, student career possibilities, choice of topics and the sequencing of subjects. Few examine the details of individual subjects or look at the nitty gritty of issues like how the choice of, say, a systems analysis methodology, a database modelling approach, or a programming language, was actually undertaken. Papers discussing programming languages and why they are chosen by different organisations tend to consider issues like the features of different languages, and their popularity in the market place, and the same is true of papers discussing systems methodologies and database modelling. My research does not involve surveys of the features or popularity of programming languages nor does it dwell on how the Business Information Systems degree at RMIT was designed, although it does discuss some of the departmental politics involved in this as they relate to the adoption of Visual Basic. Instead, it concentrates on the decisions that were taken to include Visual Basic in this curriculum: who made them and on what basis they were made. In this, it concentrates on the details rather than providing an overview of the more commonly reported course development process with curriculum documents gaining formal accreditation by moving from one committee to the next until the course is finally approved. It investigates the detail of how the changes occurred as it is here that I trace the interactions between people and other people, and between people and machines that I maintain are the key to an understanding of what happened. To those of us involved in research and teaching in Information Systems it is clear that curriculum innovation and change in this area is complex, and anything but straightforward (Longenecker and Feinstein 1990; John 1997). All curriculum innovation is complex (Kemmis and Stake 1988; Boomer, Lester et al. 1992; Fullan and Hargreaves 1992; Fullan 1993) but in IS curriculum innovation this is particularly due to the involvement of a large number of human and non-human actors, as I will now proceed to show. Science Studies, exemplified by the work of Bruno Latour, argues that scientific research is not the logical top-down process that it is often represented as being (Latour 1987). In similar vein, academic papers dealing with changes in Information Systems curriculum tend to concentrate on the final result of the innovation and, by omission of the details, inadvertently make the process of change appear obvious, straightforward and carefully planned. I will contend however that like scientific research it is nothing of the sort. The difficulty with accounts based on a top-down, linear approach to tracing curriculum change is that all the negotiations, politicking, and behind the scenes work that has gone into making the change possible have been hidden from all those not involved in it, and all that remains to be seen afterwards is the ‘official’, sanitised version; the version that shows this change as a tidy, straightforward and logical process. In retrospect it may appear that the designers were wise and thoughtful, and worked carefully towards a solution that was accepted gladly by everyone, but this appearance is deceptive. It is deceptive because it conceals the complexity of the innovation process in failing to acknowledge the different roles played by many of the host of human and non-human actors involved. I will argue that if we want to understand how IS curriculum is built, and how the human and non-human interactions involved contribute to the final product, then we need to use approaches that allow the complexity to be traced, and not diminished by categorisations (Law 1999 :1-14) or assumptions about intrinsic attributes of humans and non-humans.


Finding wisdom after the event is not, of course, confined to Information Systems curriculum change and there are plenty of other examples of complex situations or processes being made to appear simple, carefully planned and well organised by the use of this device, whether done intentionally or otherwise. Even in a supposedly straightforward and logical field like accounting Humphrey and Scapens indicate that recent literature has challenged claims to the existence of any “inherent accounting rationality or neutrality” in its history (Humphrey and Scapens 1996 :2), and quote Arrington and Francis (1989) who describe it as a:

“... complex web of economic, political and accidental co-occurrences that mirror neither technical rationality, nor a necessary progress.” (Arrington and Francis 1989 :2)

IS curriculum provides an illustration of this point in which a less than obvious process seems logical and straightforward when viewed in retrospect, in the case of program-design. Programming texts (eg Juliff 1986; Robertson 1993; Shackleton and McConville 1998) usually advocate that good program design should pursue a top-down process using a structured methodology in which the programmer follows a number of logical steps in order to create the computer program. By omitting to describe any other less structured program-design approaches, texts such as these often infer that this is the way that professional computer programmers work and that programming is thus a straightforward process, even if quite a difficult one. One tool intended to assist in the structured design of a computer program is pseudocode which is used to outline the logic of a program before the language code is finally written. Use of pseudocode is intended to force the programmer to think through the logic of the program before beginning to write any of the actual code on the computer. Structured program-design methodologies are intended to reduce the programmer’s “intellectual load” when handling “size-induced complexity” (Shackleton 1998 :18-47) and to reduce the distractions caused by having to worry too much about the implementation detail at the start, before moving on later to write the code in a programming language. Experience has shown (Ratcliff and Siddiqi 1985) that this is generally good advice and that programmers who follow it will, in most cases, end up producing good programs. Unfortunately, however, many programmers do not work in this way (Cusumano and Selby 1997; Sahay 1997; Davey and Tatnall 1995) and it is not uncommon for them to use individual, bottom-up and intuitive techniques and then to write the pseudocode after their program is working in order to fulfil project documentation requirements (Cusumano and Selby 1997). This approach, however, makes it look to an outside observer as though they had everything well thought out in advance. In relation to the work of these programmers, the retrospective representation of a semblance of order and structure results in a misleading view of the processes followed in writing a computer program. They make it look a good deal simpler and more well-structured than it actually was. Suchman (1987) argues that all actions are primarily ‘situated’ and must be taken in the context of their particular circumstances. She also contends that these situated actions are essentially ad hoc and warns against putting too much store in an account of some action constructed after the event from plans of how it was supposed to happen.

“Reconstructed in retrospect, plans systematically filter out precisely the particularity of detail that characterizes situated actions, in favour of those aspects of the actions that can be seen to accord with the plan.” (Suchman 1987 :ix)

On the surface, many lecturers’ recollections of the progress of a curriculum innovation often see it as having proceeded in a ‘natural’ and straightforward manner. For example, the view of many of the RMIT Information Systems academics not closely involved with the teaching of programming is that Visual Basic was introduced at RMIT by Fred, and was


adopted because it represented “a new direction in programming” and because Fred had investigated all the alternatives and found VB to be the “best language available” (Henry 1997; Paul 1997b). While superficially this sounds like a plausible explanation, it represents an oversimplification of the complex process involving negotiations and alliances that, in the next few chapters, I will show occurred. Following Suchman’s position, these somewhat simplistic after-the-event explanations ‘filter out’ just that detail that is essential to see what did happen rather than what appears to have been planned. If simple explanations like this are accepted as representing all that there is to IS curriculum innovation, then an incomplete picture of the complex process of negotiations and trade-offs that actually occur will be the result. In this thesis I will argue that IS curriculum innovation follows no predetermined path and that representing it as straightforward and well planned hides the complexity of this process by overlooking or ignoring the parts played by many of the actors. I will argue that the complexity of IS curriculum is due in large measure to the interconnected parts played by the various human actors but also by a multitude of non-human entities such as computers, student laboratories, software, programming languages, textbooks and so on. I will further argue that this complexity will only be seen if it is reported in all its glorious ‘messy reality’ (Hughes 1983). IS curriculum innovation is a complex undertaking and any representation that makes it appear straightforward and structured through the use of explanations that rely only on the formal part played by this or that committee, and this or that university accreditation procedure, obscure almost all of the important details of translation and transformation that occur as an innovation progresses. Simple accounts have their purpose, but any simplification comes at a cost. As I will argue, an analysis based on the sociology of translation also simplifies, but does so in a manner which self-consciously seeks to trace the interplay of interests of the researched and the researcher. Importantly, this research takes contributions from both human and non-human actors. Programming languages play a key part among the many non-human actors in IS curriculum change, and as actors their many associations constitute a complexity that requires careful tracing.

“Software entities are more complex for their size than perhaps any other human construct because no two parts are alike. ... A scaling up of a software entity is not merely a repetition of the same elements in larger sizes, it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some non-linear fashion, and the complexity of the whole increases much more than linearly.” (Brooks 1987 :11)

Along with many other things in IT however, the tools used in software development are themselves constantly changing. Programming languages such as Visual Basic come out in new and more powerful versions with additional features every couple of years, and dealing with these new features adds to the complexity of working with a programming language (Brooks 1987). While new programming language versions are often claimed to offer improvements like more intuitive interfaces (Communique 1990) and sometimes even to be simpler for users to work with, their adoption adds complexity to the process of curriculum change (Cougar, Davis et al. 1995) by requiring those teaching them to spend time learning what is new and determining how the new features affect what they currently teach. Upgrades and new languages contribute to the need for frequent changes to IS curriculum and require the almost constant effort of IS academics to keep abreast of them. But it is not just programming languages that get updated as programming paradigms and methodologies also undergo quite radical change. A few years ago the object-oriented programming paradigm was seen as a novelty, whereas today it is increasingly becoming something that must be included in any Information Systems course (Hardgrave and Douglas 1998). A variety of different object-oriented design methodologies have been


available since the late 1980s, but in 1997 a new modelling tool known as Unified Modelling Language (UML) was developed to deal systematically with the problems of object-oriented design (Rational Software Corporation 1997). Similarly, prior to the release of Visual Basic, event-driven programming was confined mainly to a few applications like process control (Baron 1986), but with many applications and operating systems now being event-driven some knowledge of event-driven programming is becoming increasingly important to those involved in the creation of microcomputer applications (Harriger and Lisack 1998). Event-driven programming has thus become another important new programming paradigm which is increasingly finding its way into Information Systems curricula. A few years ago neither object-oriented nor event-driven programming had a significant place in the IS curriculum, but changes in technology have led to each of these language-types gaining a place. The difficulty inherent in finding the new material an appropriate place, and in removing other material to allow for this, underlies the complexity of Information Systems curriculum innovation. The problems for IS curriculum caused by the rapidity of change in information technology are significant, and are experienced in few other fields of study. IT is now integrated into most academic fields and so new software versions and hardware upgrades must be considered as one aspect of any curriculum development. Where the study of Information Systems is different is that software, hardware and systems are its object of study and when they undergo changes, these changes can fundamentally affect the range of things that must be considered and the choices that need to be made in designing the curriculum. I will argue that because this technology is fundamental to Information Systems these rapid changes in technology result in the addition of new actors, and changes in the roles of actors and entities already present. It is not just the changes in programming languages, paradigms and methodologies however, but something about the presence of the technology itself that is especially significant. Many areas of study look at the impact of certain artefacts on humans; a study of the effects of television on young people requires some examination of the TV set itself, and investigation of the role of the motor car on patterns of employment and habitation also necessitates some consideration of transportation technology. But an item of software is much more than just an artefact that, once created, remains unchanged.

“The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture: they are superseded by later models, or essential changes are incorporated into later-serial-number copies of the same basic design. ... Both are much less frequent than modifications to fielded software. In part, this is because the software of a system embodies its function, and the function is the part that most feels the pressures of change.” (Brooks 1987: 2)

During execution, a computer program is what Latour (1993) calls a ‘hybrid’ (and has some similarity to what Haraway (1991) calls a ‘cyborg’) as both human and non-human parts in its operation are blurred in such a way that it is difficult to distinguish one from another. When it is running, the program consists of the contributions of one or more computers, an operating system, a programming language such as Visual Basic, the efforts of one or more programmers, possibly a data-communications network, a visual display, a keyboard, a mouse, and the program’s users. This raises the main methodological issue for this study: how to deal with the complexity found in Information Systems curriculum innovation without simply filtering it out and


ignoring the parts played by many of the human and non-human actors involved, as has been done in most of the other studies.

How this Research is Framed Shulman (1988) contends that when we speak of research methodology we are really speaking of a family of methods which share the characteristics of a ‘disciplined inquiry’. The word ‘discipline’ is used here to refer not only to the ordered, principled nature of the investigation, but also to the “principles of regularity or canons of evidence” (Shulman 1988) employed by the investigator. Methodologies differ, he notes, in the way they formulate their questions, how they define the content of their domains, how they organise material conceptually, and the rules they accept for creating and verifying knowledge. The disciplined inquiry is conducted in such a way that its argument can be examined by others without reliance on the eloquence of the writing (Cronbach and Suppes 1969). Kellehear (1993) differentiates between methods, which he describes as ways of proceeding and of collecting information, and the techniques which are used in applying the chosen method. As this study involves curriculum innovation in university courses in Information Systems, in the sections that follow I will argue that a suitable research methodology must be one attuned to the study of technological change and that it must be cognisant of the need to consider the complexity due to the intertwined contributions from both humans, and non-human entities like software companies, computer hardware, programming languages, academics, system design methodologies and student laboratories, to innovation and the making of curriculum. I will argue that to see how this innovation occurred it must also be able to handle complexity and allow the reporting of all the ‘messy reality’ (Hughes 1983) without oversimplifications resulting from a priori decisions on what to include and what to omit. The approach that seemed best suited to this is that of actor-network theory (ANT), a choice that was determined when I decided to undertake my doctoral studies with the group working in technology in education at Central Queensland University. When writing up my masters dissertation on the curriculum history of Business Computing in Victorian universities (Tatnall 1993) several years ago I briefly explored ANT as a possible means of handling the contributions to curriculum by both humans, and non-human entities like governments, tertiary institutions, computer companies, computer hardware and operating systems. Although I did not make much use of ANT in my dissertation at that time I did gain sufficient familiarity with its premises to see later that it could offer an appropriate framework for this research topic. When starting on my doctoral studies I took a considerable leap of faith and decided to explore an actor-network approach to investigating the socio-technical nature of curriculum innovation in Information Systems. As I began to investigate how Visual Basic was adopted at RMIT it became increasingly clear to me that to relegate this programming language to a passive role and to give all the action to RMIT academics would be to show only one side of the story. It seemed to me that an approach that allowed some of the non-human entities a slice of the action, as actor-network theory does, might prove useful in providing insights into the negotiations and trade-offs that were already becoming apparent in my research. Further investigation, reading, and reflection supported this decision. As described in Chapter 4, actor-network theory (ANT) asserts that the world is full of hybrid entities (Latour 1993) containing both human and non-human elements, and that nothing is purely social or purely technical. One could question, for instance, which of the contributions to a piece of software are due to some aspect of the computer hardware or the


compiler and programming language tools, and which are solely the result of human interactions. Actor-network theory developed around problems associated with attempts to handle socio-technical ‘imbroglios’ (Latour 1993) like electric cars (Callon 1986a), scallop fishing (Callon 1986b), Portuguese navigation (Law 1987), and supersonic aircraft (Law and Callon 1988), by denying that either wholly human or wholly non-human entities exist. It deals with the social-technical divide by denying its existence, regarding the world as heterogeneous (Chagani 1998). Latour contends that a major difficulty in considering how technology and society interact is the lack of suitable words, as long as we consider the two as acting separately. He argues that this dividing line should be abandoned in our consideration of the contributions of human and non-human actors.

“Contrary to the claims of those who want to hold either the state of technology or that of society constant, it is possible to consider a path of an innovation in which all the actors co-evolve.” (Latour 1991 :117).

In deciding to use actor-network theory I have been conscious that it is seen by many people as a ‘novel’ approach from Science and Technology Studies that will need some justification. As my topic straddles the fields of Information Systems and education, in the pages that follow I will look at the main research traditions of each of these fields in order to show how they handle issues like those discussed, and to relate their differences and commonalities. In particular, I will look at how various methodologies handle the socio-technical and the complexity introduced by a consideration of the interweaved contributions to curriculum innovation of both human and non-human actors. I will examine these methodologies and make these comparisons because actor-network theory has not yet been much used in educational research (eg Nespor 1994; Gilding 1997) and so requires a careful mapping. This will come in part from an initial analysis with respect to some of the better known approaches to studying Information Systems and curriculum innovation, and in part from this study itself in which by making use of the ANT framework I have been able to explore these relationships in practice. Each field of academic inquiry is characterised by its own preferred and commonly used research methodologies. Shulman (1988) remarks that in educational research, the most commonly used approaches involve the quantitative methods of experimental, quasi-experimental, correlational and survey research. To these Jaeger (1988) adds case study, ethnography, philosophical and historical inquiry methods. In a survey of published MIS articles Orlikowski and Baroudi (1991) found that 96% of their sample, taken from selected IS journals, adopted a positivist perspective (Kolakowski 1972) while the remainder were interpretive. Building on a research taxonomy developed by Hamilton and Ives (1982), Farhoomand (1992) classifies IS-related research papers published in a similar set of journals in the 1980s into five categories: case study, survey, field test, experimental and non-empirical research. He defines non-empirical research as consisting of tutorials and conceptual works that rely on secondary sources, or the author’s experience to support their conclusions. Farhoomand reported that 57% of his sample consisted of empirical research with case studies and surveys constituting the majority of this. More recent examination of the literature would however, suggest that the percentage of interpretive research published since that time has increased markedly. In the late 1980s, Galliers and Land (1987) deplored the tendency of IS researchers to accept the primacy of traditional, empirical approaches that they saw as more appropriate to the natural sciences than to studies of organisational use of information. In line with this, Hirschheim (1992) has argued for a shift in IS research towards the acceptance of methodological pluralism. This plea follows that of Nissen et al. (1991), and Achterberg et


al. (1991) who argued, at an IFIP25 working conference on IS research in 1990, for a broader perspective than had previously been seen. Partly as a result of these efforts, since the early 1990s qualitative research has gained considerably in legitimacy and is now used much more extensively in investigating information systems. A methodology can be regarded as a philosophical framework, or ‘point of view’ (Deely 1990), within which a set of methods can be systematically applied (Guba and Lincoln 1988). Guba and Lincoln (1994) advise that there are four different philosophical perspectives that underlie qualitative research: positivism, post-positivism, constructivism and critical theory. In relation to Information Systems research, Orlikowski and Baroudi (1991) offer three: positivist, interpretive and critical research. Myers (1997) describes the stance taken by positivist researchers in Information Systems as based on the assumption that reality is objectively given and that it can be described by reference to measurable properties that are independent of the researcher. Interpretive IS researchers, on the other hand, consider that reality can only be accessed through social constructions such as language, consciousness and shared meanings. Critical research makes the assumption that social reality is historically constituted and that people are constrained in their actions by various forms of cultural and political domination (Myers 1997). In regard to research traditions in Information Systems, Myers (1997) outlines four as being particularly significant: case study research, ethnography, grounded theory and action research. • Case Study Research. According to Orlikowski and Baroudi (1991) and supported by

Alavi and Carlson (1992) case study research is the most commonly used qualitative approach in Information Systems. They contend that as IS research topics commonly involve the study of organisational systems a case study approach is often quite appropriate. Many of the case study researchers in Information Systems takes a positivist perspective (Benbasat, Goldstein et al. 1987; Lee 1989; Yin 1994), but some instead adopt an interpretive stance (Walsham 1993; 1995) and others, like Kaplan (1988), advocate a middle course involving a combination of qualitative and quantitative methods.

• Ethnography. After some early work, such as that undertaken by Suchman (1987) and Zuboff (1988), the prominence of ethnography as a suitable approach to Information Systems research has risen. Ethnography has been used especially in research where the emphasis is upon design, computer-supported cooperative work, studies of Internet and virtual communities, and information-related policies (Star 1995).

• Grounded theory is an “an inductive, theory discovery methodology” (Martin and Turner 1986) which seeks to develop theory that is grounded in data that is systematically gathered and analysed and involves “continuous interplay” between data and analysis (Myers 1997). Orlikowski (1993) argues that in Information Systems research situations involving organisational change, a grounded theory approach can be useful as it allows a focus on “contextual and processual” elements as well as on the actions of key players.

• Action research (Lewin 1946) has been described as proceeding in a spiral of steps where each step consists of planning, action and evaluation of the result of the action. It is seen as aiming:

“... to contribute both to the practical concerns of people in an immediate problematic situation and to the goals of social science by joint collaboration within a mutually acceptable ethical framework.” (Rapoport 1970 :499)

25 International Federation for Information Processing


While action research has been embraced in fields like organisational development and education (Kemmis and McTaggart 1982; 1988), apart from a few notable exceptions in the work of scholars like Checkland (1991) and Baskerville (1998) it has had less application in Information Systems (Myers 1997). A variant of action research that is, however, gaining acceptance in Information Systems is Soft Systems Methodology.

Of the approaches to research that are common to education and Information Systems, in the absence of actor-network theory I would probably have drawn on ethnography, case study research and soft systems methodology. In order to locate actor-network theory in both the IS and education research fields I will now elaborate the approaches that bear some resemblance to ANT. Soft Systems Methodology Soft systems methodology (SSM) developed by Peter Checkland (1981; 1988; Checkland and Scholes 1991) and his colleagues from Lancaster University attempts to give due recognition to both human and technological aspects of a system, and is claimed to be useful for the analysis of systems where technological processes and human activities are highly interdependent (Finegan 1994). Although originally intended for the analysis of Information Systems, Rose (1997) contends that SSM has application as a social research tool, especially in situations where the focus is on organisational decision making. SSM has been explicitly identified by Checkland (1991) as an action research methodology. Traditional approaches to systems analysis are based on a technique of top-down decomposition where problems are solved by fragmenting them into separate parts and then deriving a solution for one part at a time (Kendall and Kendall 1992). Soft systems methodology involves a more holistic approach which is intended to incorporate the human element of such systems into the systems design work. It is claimed to be most appropriate in the analysis of systems that are messy, poorly defined, or especially complex (Finegan 1994). Checkland (1981) proposed that work organisations should be seen as consisting of a technology system (hard) and a human activity system (soft). Soft systems methodology is then used to analyse and describe the relevant parts of the human activity system and how this interacts with the technology system. It thus acknowledges both human and non-human aspects of Information Systems, but considers these to be entirely separate types of entities. The basis of soft systems methodology is a comparison between the world as it is, and some models of the world as it might be (Dick 1998). It attempts to keep these two worlds separate while ensuring an appropriate mapping between them (Wood-Harper, Corder et al. 1996). Beginning with a detailed, unstructured study of the system containing the problem, models are developed of how the system might ideally work. These ideal models are then compared with the real situation and differences between them become the basis for discussion of how the system could be improved. SSM can be thought of in terms of a seven stage process in which both the logic and the culture (Dick 1998) of the situation are taken into account. Checkland (1981) expresses the seven stages in this way:

1. The problem situation; unstructured. The researcher begins by investigating and ‘experiencing’ the problem situation whilst making as few assumptions about its nature as possible.


2. The problem situation; expressed. A detailed description, or ‘rich picture’26, of the problem situation is developed. This picture tries to capture people’s relationships and value judgements (Checkland and Scholes 1991) as well as the logic of the situation.

3. Root definitions of relevant systems. The ‘essence’, or essential nature, of each of the relevant real systems is considered under the following headings: � Customers/Clients - those who benefit from the system. � Actors - people who carry out activities that transform inputs into outputs. � Transformation - the core processes in the human activity system that cause the

conversion of inputs into outputs. � Weltanschauung or world view - the image or model of the world, held by

members of the organisation under investigation, that makes this particular human activity system important.

� Owner - the entity with the power of veto. � Environmental constraints - from outside the system boundary.

4. Making and testing conceptual models. From the root definitions arrived at in the previous stage the researcher develops models of how a system like this might ideally function. These idealisations take no account of how the system currently operates.

5. Comparison of the conceptual models with reality. Identification of how the conceptual models differ from the real situation is done so that possible changes can be suggested.

6. Identification of feasible and desirable changes. Changes are only considered feasible if they are technically possible and also fit into the culture of the organisation. They are considered desirable if they represent an improvement in the eyes of the customer or owner.

7. Action to improve the problem situation. These desirable and feasible changes are finally put into practice.

Although taking complex systems as its unit of analysis, like its cousin systems analysis, the goal of soft systems methodology is to create order out of chaos. Its aim is to simplify these systems to a level where the ‘essential ingredients’ (Checkland 1988) stand out and the less relevant details are removed or concealed. Because of the difficulty in building even quite straightforward information systems (Thomsett 1993), SSM needs to simplify in order for the system that is to be constructed to have any change of fulfilling its purpose. If it took all the small ‘irrelevant’ details into consideration the system would be too complex to build. Soft systems methodology thus handles complexity by filtering out anything that the system builder judges will not contribute to the construction of a better system. Systems theory requires that what is considered to be outside the system can have no bearing on the investigation (Emery 1969) and so it is necessary to define the bounds of the system so that some entities are seen as being within it and others as being outside. Examples studied using soft systems methodology then are both bounded and particular; SSM looks at specific cases with the aim of providing solutions to them. Ethnography The framework of anthropological studies is the concept of culture. Ethnography consists of attempts to describe culture, or aspects of it (Bogdan and Biklen 1992). The purpose of ethnographic research in education lies in the description of socio-cultural activities in order to uncover social, cultural and normative patterns (Burns 1994). Ethnographic research involves building up a picture of the way of life of some identifiable group of

26 Similar to Geertz’ (1979) description of ethnography in the next section.


people (Wolcott 1988), and is a classical sociology that had its origins in anthropology whose main use was in the study of exotic cultures (Tesch 1990). Ethnography represents an holistic way of studying human life (Tesch 1990) in the sense that the ethnographer participates, for an extended period, in the lives of the people being studied, watching to see what happens and collecting whatever data may be available (Hammersley and Atkinson 1983; Jacob 1987). It makes extensive use of less structured and more ‘creative’ (Douglas 1985) interview techniques than does the anthropological sociology from which it is derived. Goetz and LeCompte (1984) proffer that: • Ethnographic research strategies elicit phenomenological data and represent the world

view of the participants being investigated. • These strategies are empirical and naturalistic. • Ethnographic research is holistic, seeking to construct descriptions of total phenomena. • Ethnography is eclectic, and researchers use a variety of techniques to collect data. Ethnography is a search for patterns and meanings and why people behave in individual ways (Shipman 1988). Wolcott (1988) notes that anthropologists always study human behaviour in terms of cultural context, looking for how this relates to a generalised description of the way of life of an interacting group. He further notes that this interacting group of humans is always notably ‘strange’ to the observer, based on the presumption that the researcher’s capabilities for observing, recording and analysing are enhanced in unfamiliar settings. Ethnography is open-ended and organised to maximise the chances of being able to observe the unexpected. Wolcott notes that researchers making use of ethnography in education face the problem of:

“... trying to conduct observation as though we were in a strange new setting” (Wolcott 1988 :190)

Geertz (1979) defines ethnography using the term ‘thick description’, and ethnography provides these rich, thick descriptions of complex situations in order to foster the search for patterns within the culture being investigated. The final ethnographic report then concentrates on the patterns it reveals, rather than the complexity itself. The focus of ethnography is the study of “human behaviour in a cultural context” (Wolcott 1988 :188) and so it pays little heed to the role of non-human entities except as they relate as artefacts which may affect human behaviour. In an ethnographic account Visual Basic would be relegated to the status of a simple artefact and not permitted any active role in the innovation process. Grint and Woolgar (1997) comment that one way out of the problem of dualism in ethnographic studies is to make the distinction between the technical and non-technical the object of study itself by using:

“... the interpretive/ ethnomethodological strategy of turning the dualism into a topic to be studied rather than just a resource to be drawn upon.” (Grint and Woolgar 1997 :67)

No one method is associated exclusively with ethnography, which makes use of a variety of techniques including participant observation, interviewing, and analysis of written resources (Wolcott 1988). It uses these techniques in an attempt to discern patterns through the study of regularities (Tesch 1990). Wolcott notes, however, that no anthropologist would ever rely solely on a single observation, instrument, or approach, but would make use of methodological triangulation (Stake 1995 :114) and obtain information in many ways wherever possible (Wolcott 1988). Callon (1986a) argues that sociology and anthropology have failed to account for the influence of science and technology because they have sought explanations from within the surrounding society rather than from within science and technology. Like most other


approaches, ethnography looks at the world from a human viewpoint and credits non-humans only as part of the context of the study. It puts a prior boundary on any study by considering technology separately from the ‘cultural context’ it is posited to operate within. Callon objects that:

“... the development of scientific knowledge and technical systems cannot be understood unless the simultaneous reconstruction of the social contexts of which they form a part is also studied.” (Callon 1986a :20)

Case Study Methodology A case study involves the detailed examination of a single setting or a particular event (Merriam 1988), and its main concern is with the detail and complexity of the case, which it treats as a bounded system (Stake 1988). It focuses on the unity or totality of this system, which is regarded as complex and dynamic. The aim is to focus on a case, and not a whole population, in order to gain an understanding of its complexity. Along these lines, a classic definition of case study research is offered by Goode and Hatt:

“The case study then is not a specific technique; it is a way of organizing social data so as to preserve the unitary character of the social object being studied.” (Goode and Hatt 1952 :331)

Yin (1984) regards a case study as the preferred method for examining questions that ask how or why of contemporary events, or when the relevant behaviours cannot be manipulated. He says that case studies use many of the same techniques as a history, but add direct observation and systematic interviewing. Either a single case or multiple cases may be examined. Case study evidence can come from documents, archival records, interviews, direct observation, participant-observation or physical artefacts (Yin 1984). As with most other forms of research, case study analysis usually consists of a search for patterns in the multitude of data that has been collected (Stake 1988). Researchers can reach new meanings about cases both through direct interpretation of individual instances, and through the aggregation of instances until something enlightening emerges about the case. The purpose is to make it understandable. The goal of a case study is particularisation, rather than generalisation (Stake 1995) and the primary aim of performing a case study is not to see how the case under investigation differs from others, but simply what it is and what it does, with the emphasis being on interpretation. Stake (1995) lists three different kinds of case study: the intrinsic case study where there is an interest in learning about the case itself, the instrumental case study where the purpose is to understand something else, and the collective case study in which several instrumental cases are studied so as to gain a better understanding of something else. He contends that a case should be treated as an integrated system in which it does not matter if the purpose is irrational or the parts work well together. The important thing is that the case is seen as a complex, functioning thing (Stake 1995). Two sorts of issues are considered in a case study: etic issues which are brought by the researcher from outside, and emic issues brought up by the actors and arising from within the case (Stake 1995). In formulating a case study it is necessary to set boundaries, then to seek out certain issues or themes, and in this way it differs from ethnography which is open-ended. The case study boundaries are set by the researchers and also by others who care about the system (Stake 1988). These boundaries can be reset during the study as the case becomes better known, but the study will always be bounded. Although bounded, however, the study can be large or small and Burns (1994) speaks of a continuum ranging from the individual subject right up to the ethnographic study.


How Actor-Network Theory Handles Complexity A major issue in this study is how to understand the complexities of IS curriculum innovation. A common method of handling complexity in all subject areas lies in simplification, but in this case the danger with simplification is that it runs the risk of removing just those things that constitute the description I want by concealing the parts played by many actors (Suchman 1987). I have argued that without this detail any understanding of IS curriculum innovation tends to be superficial and lacks the necessary detail which would allow a more holistic account. Of course some simplification is necessary in order to represent the infinite possibilities of any complex situation and all research methodologies offer ways of simplifying complex social phenomena. The question here is which details to include and which to leave out, and who is to decide. In this respect, an appropriate research approach needs to ensure that complexities are not lost “in the process of labelling” (Law 1999 :9). It is a feature of actor-network theory that the extent of a network is determined by actors that are able to make their presence individually felt (Law 1987) by other actors. The definition of an actor requires this and means that, in practice, actors limit their associations to affect only a relatively small number of entities whose attributes are well defined within the network (Callon 1987). This simplification is only possible if no new entities appear to complicate things, as the actor-network is the context in which the significance and limitations of each simplified entity is defined (Callon 1986a). If a new element is added, or if one is removed, then some of the other associations may be changed as it is the juxtaposition of actors within the network that is all-important.

“The simplifications are only possible if elements are juxtaposed in a network of relations, but the juxtaposition of elements conversely requires that they be simplified.” (Callon 1987 :95)

In an object-oriented programming environment each component of the computer program can be considered as an object (Parsons and Wand 1997) with its own properties, methods and actions. In common with the encapsulation of objects in object-oriented environments the actors, or ‘heterogeneous entities’ (Bijker, Hughes et al. 1987), encountered in actor-network theory have attributes and methods and may themselves be composed of other objects or actors. So, when looked into carefully an actor itself consists of a network of interactions and associations. In the same way a network may be simplified, or ‘black-boxed’, to look like a single point actor (Law 1992).

“... if a network acts as a single block, then it disappears, to be replaced by the action itself and the seemingly simple author of that action.” (Law 1992 :385)

The entry of new actors, desertion of existing actors, or changes in alliances can cause the ‘black boxes’ (Callon 1986a) of networked actors to be opened and their contents reconsidered. A network relies on the maintenance of its simplifications for its continued existence. These simplifications are under constant challenge and if they break down the network will collapse, perhaps to re-form in a different configuration as a different network. An actor is not just a ‘point object’ but an association of heterogeneous elements themselves constituting a network, so each actor is also a simplified network (Law 1992). An actor can, however, in many ways also be considered as a black box, and when we open the lid of the box to look inside it will be seen to constitute a whole network of other, perhaps complex, associations (Callon 1986a). In many cases details of what constitutes an actor - details of its network - are a complication we can avoid having to deal with all the


time. We can usually consider the entity just as an actor, but when doing this though it must be remembered that behind each actor there hide other actors that it has, more of less effectively, drawn together (Callon 1987). This means that any changes affect not just this actor, but also the networks it simplifies (Callon 1987). It is, likewise, often also possible to ‘punctualise’ (Law 1992) a stable network and so consider it in the form of a single actor. Whenever possible it is useful to simplify, to an actor, a network that acts as a ‘single block’ to make it easier to deal with. An actor then:

“... can be compared to a black-box that contains a network of black-boxes that depend on one another both for their proper functioning and for the proper functioning of the network.” (Callon 1987 :95)

The important thing to note about the use of black-boxing for simplification is that the complexity is not just put into the black box and lost as it is always possible, and indeed necessary, to periodically reopen the black box to investigate its contents. The complexity is punctualised (Law 1992 :385), but not lost.

Uses of ANT and Innovation Translation Theory As I have shown, actor-network theory offers advantages over the other methodologies considered in its handling of the complexities due to the contributions of human and non-human entities, of avoiding the difficulty of needing to find a dividing line between these, and in its ability to avoid having to assign either humans or the technology an ‘essence’. Although ethnography and case study methodology are both useful in handling complex situations, neither is especially useful in tackling socio-technical problems, and neither can manage the notion of technological-human hybrids which is a key feature of actor-network theory. An ethnographic approach would restrict any explanation of the reasons for adoption of Visual Basic at RMIT to those involving RMIT’s ‘social context’ (Callon 1986a) and exclude the possibility that some of the explanation might lie in the technology itself. It would not allow the technology other than a passive role, and allowing some of the actors to give agency to Visual Basic, or to Microsoft Corporation would not fit with the use of an ethnographic approach. Case studies are also considered to be situated in a particular social context, and issues of how technological entities interact with this social context are considered only from the perspective of the case. Soft systems methodology presents an interesting approach in taking seriously the parts played by both human and non-human aspects of a system, but its consideration of these as entities of fundamentally different types one of which - the human, takes positive action while the other - the technological, is the passive instrument, presents problems. To have used SSM in this study would have meant including Visual Basic and RMIT in the technology system. These entities would then have been seen to have acted to constrain the actions of human actors like Fred, Paul and Rebecca, whose roles will be traced later in the thesis. Use of SSM would not allow Visual Basic or RMIT to be seen as taking any active part in the curriculum innovation in which RMIT academics would instead have all the running. It would also mean deciding in advance which non-human entities should be considered as being important. Doing this would have resulted in the assignment of particular roles to the non-human actors in advance, bringing an unacceptable measure of a priori simplification to the phenomenon I wanted to study. An investigation of these other approaches thus reinforces my contention that actor-network theory is the most appropriate approach for use in this study. Although there have been several other studies of curriculum innovation, such as Nespor (1994), Gilding (1997), Bigum (1998b; 1998a), and Busch (1997), which have used a translation rather than a diffusion model, such studies are relatively rare. A search through


the literature has revealed no other studies of a specific curriculum innovation introduced largely through the actions of a single lecturer rather than as part of an institutional policy decision that make use of an innovation translation approach. Use of this approach thus makes my study quite different to most others. Actor-network theory has been used to investigate the success of a number of technological innovations and, in particular, to describe a number of notable failures. The list that follows gives an indication of the wide range of studies considered. Law (1986b; 1987) has used actor-network theory to describe the successful Portuguese exploration down the African coast to trade in India, and the unsuccessful TSR2 project (Law 1988; 1988; Law and Callon 1992) to build a revolutionary military aircraft in Britain. Callon (1986b) has used it to describe the ‘domestication’ of scallops in St Brieuc Bay, Brittany and the failure of the Renault car company to develop a successful electric car in France (Callon 1986a). Singleton and Michael (1993) have written of the part played by general practitioners in the UK Cervical Screening Programme. Grint and Woolgar (1997) have used ANT, and other approaches, to explain the Luddite rebellion and the events surrounding introduction of weaving technology into the United Kingdom in the early nineteenth century. Bigum (1998b; 1998a) has described the introduction and use of computers in schools and Gilding (1997) how university students build expert systems. Busch (1997) has applied actor-network theory to medical school curriculum and Lundberg (1997), Mol and Law (1994) and Prout (1996) to hospitals and other things medical. Star and Griessemer (1989) have applied it to projects in museums, and Vidgen and McMaster (1996) to car parking systems. Latour (1988a) has used actor-network theory to discuss the achievements of Louis Pasteur, some of the processes undertaken by scientists in their research and their laboratories (Latour 1987), the simultaneous invention of the Kodak camera and the mass market for amateur photography (Latour 1991), and analysis of the conception and ultimate failure of the revolutionary Parisian public transportation system known as Aramis (Latour 1996). More specifically, innovation translation has been used to describe the fate of a range of innovations, a selection of which will now be mentioned. A book review by Pinch (1998) describes Simmie’s (1997) examination of how changes occur in regional economies. An innovation translation approach to the formation of attitudes by farmers and ‘field-level bureaucrats’ on issues of farm pollution is discussed by Lowe and Ward (1997), and in the same book (Goodman and Watts 1997) an article by Whatmore and Thorne (1997) investigates the globalisation of coffee marketing. A review of this book by Kayatekin (1998) argues that although the actor-network approach to innovation translation used in these papers, and several others, offers valuable insights, it is still somewhat controversial and problematic. Other general examples of the use of an innovation translation approach include a description by McMaster et al. (1997) of the failure of the IT Department in a UK City Council to adopt a structured systems design methodology. In one of the few papers on the use of actor-network theory in curriculum innovation, Busch (1997) contends that to sustain educational change requires developing policies that consider the enrolment of both human and non-human actors in a new network to support the change. Gilding (1997) gives another example in his study of how university students came to understand the building of knowledge-based systems, concluding that both the teacher and the students extended power to the technology by roles they assigned to it. Although not directly related to curriculum innovation Nespor (1994) uses actor-network


theory to describe how an American university made use of its physical space in different ways to mobilise the communities of Physics and Management. As far as I am aware, the only other similar study that looks at the fine detail of a relatively small curriculum project, however, is that conducted by Gilding (1997) on student construction of expert systems. Criticisms of Actor-Network Theory There appear to be several main criticisms of actor-network theory. To begin, there is the criticism (Grint and Woolgar 1997) that it is not always sufficiently clear where the boundaries of a network lie or whose account of a network is to be taken as definitive. Grint and Woolgar (1997) note that the analyst’s story seems to depend on a description of the ‘actual’ network as if this was objectively available. Radder (1992) expresses some concern with what he sees as the goal orientation of ANT; its tendency to look towards stabilisation, black-boxing, and control. He asks of the nature of the stabilisation process, and questions from whose point of view it is seen, pointing out a tendency in ANT to look at things from the viewpoint of the ‘winners’; the successful actors. He argues that a bias to do this is built into ANT’s definition of an actor as:

“... any element which bends space around itself, makes other elements dependent upon itself and translates their will into a language of its own.” (Callon and Latour (1981 :283), quoted from Radder ( 1992 :181))

Under this definition, Radder contends, there are only winning actors. A second criticism relates to ANT’s treatment of human and non-human actors. A critique by Collins and Yearley (1992) claims that:

“The deprioritization of social that gives an autonomous voice to ‘things’ disguises the fact that these voices in actuality depend upon the mediation of human actors.” (Collins and Yearley (1992) quoted from Singleton and Michael (1993 :231))

They suggest that ANT concedes too much to realist and technical accounts. In reply, Callon and Latour (1992) claim that technological artefacts are implicated in the very fabric of the social and are “social relations viewed in their durability and cohesion” (Singleton and Michael 1993 :231). Also in relation to its treatment of human and non-human actors, Lee and Brown (1994) propose that actor-network theory’s very liberalism and democracy mean that it has no ‘Other’. Whereas much of sociology has put anything non-human or non-social outside its disciplinary boundaries and made it ‘Other’, ANT has not. They assert that ANT’s success in challenging the human/non-human dualism puts it at risk of:

“... stretching the Nietzschean world view27 and the discourse of liberal democracy to cover everything.” (Lee and Brown 1994 :774)

and in doing so risk the production of “yet another ahistorical grand narrative and the concomitant right to speak for all” (Lee and Brown 1994 :774). Thirdly, Grint and Woolgar (1997) argue that ANT retains a degree of residual technicism in its need to sometimes refer to ‘actual’ technical capacities of a technology. They quote Callon’s (1986a) analysis of the attempts at building a French electric car, in which they claim that he makes reference to the ‘unfortunate tendency’ of the catalysts to become quickly contaminated. They note that the anti-essentialist approach of actor-network theory would point to this ‘actual property’ being treated as a construction. Brey (1997) claims that by assigning properties and effects to technologies, actor-network theory has some

27 In the Nietzschean world view all categorisations of things in the world are considered to be solely the

result of human activity. This would apply to categorisations such as that of humans versus non-humans.


similarities to the social shaping approaches and suggests that the notion of inscription (Akrich 1992) could be seen as a metaphor for the ‘politics of artefacts’ (Winner 1977; 1985). Despite these minor reservations, however, Grint and Woolgar note that actor-network theory points to the possibility of an understanding of technology that does not rely on the presence of a ‘god within the machine’. Other criticisms of ANT (Scott 1991; Slezak 1994) can also be found, but most are only partial, many cover approximately the same ground, and some reflect only a limited reading of the ANT literature. None of this criticism is sufficiently serious to deter me from basing the methodology of this study on the use of actor-network theory, and some of the criticism, as I will argue, is a useful basis for reflecting on my analysis. An investigation of the complex socio-technical processes by which the specific content of an Information Systems curriculum is selected, legitimised and kept up to date, is the subject of this study. It involves an investigation not just of the formal statements of content that appear in documents like Faculty handbooks, but the ‘messy reality’ (Hughes 1983) of the selection of content by individual lecturers from subject to subject and from semester to semester. Specifically it is concerned with the adoption, and retention, of Visual Basic by the Department of Business Computing at RMIT. In an area such as this, an area so dependent on the use of technology, actor-network theory offers considerable advantages over other approaches, and so is the approach adopted in this study. This is an actor-network study in innovation; a study in curriculum innovation by translation.

The Author’s Place in this Study The extent to which a researcher brings some of their own intellectual baggage to an investigation, and how the background of a researcher affects their research, are questions that cannot readily be answered with any certainty. My use of an actor-network approach in this study means that I must, inevitably, be considered to have become a part of the networks of association that I am describing. As I cannot separate myself from my own values and background I will declare them here, for as Stake says:

“Research is not helped by making it appear value free.” (Stake 1995 :95) The major difficulty I faced during this study was that my prior knowledge of Visual Basic and many of the human actors involved could have led me to have formed set views about them, to categorise them, to assign essential attributes to them. But actor-network theory requires that the analyst come to a study having made no such a priori assumptions about the actors and networks. Much as I would like to think that I can forget my previous knowledge, this is an unrealistic hope and the best that I can do is to recognise it and make every effort to deal with its consequences. Fred, one of the most important actors in this story, is now a Senior Lecturer at RMIT and it is in that context that he enters the story. Like me however, Fred began his teaching career in secondary education and I first met him in 1974 when we began teaching together at Watsonia High School. We have been friends and colleagues now for twenty-five years. In the late 1970s and into the 1980s Fred and I shared a common interest in computer education, wrote two Computer Science textbooks and co-operated on several commercial programming jobs. Since both making the move to tertiary education we have continued to be colleagues, even if at different universities. We have also presented several conference papers together, and jointly authored several textbooks on Management Information Systems, Systems Implementation and Visual Basic. In a new and initially quite small curriculum area such as this I had also known many of the Information Systems academic


staff at both PIT and RMIT before beginning this study. I researched the beginnings of Information Systems in Higher Education for my Master of Arts and these investigations meant that I was no stranger to a number of academic staff in the Department of Business Information Systems at RMIT and the corresponding department at PIT. As a consequence, even before beginning interviews and data collection I had some idea of what was going on in Information Systems curriculum development and with the use of Visual Basic in the curriculum at RMIT. I discovered Visual Basic a little after Fred, and in conjunction with some work I was doing with him. What initially interested me about VB was its integrating capabilities and its ability to act as the ‘glue’ to stick together applications containing program code with database and spreadsheet data. In 1994 I introduced Visual Basic in a third year Information Systems subject at Victoria University to do just this. At that time I would probably have ‘categorised’ Visual Basic as an integration, or scripting language (Ousterhout 1998) after working, and negotiating, with it for some time. Actor-network theory does, however, not allow the categorisation of actors as this leads to explanations based on this categorisation. I have thus made a serious attempt to set aside these categorisations and not let them affect my account of what the other actors said. This background knowledge, and my close friendship with Fred, have been both an advantage and a potential problem. Knowing a little of the background of the Department made interviewing RMIT Information Systems staff easier and I was able to anticipate some of the likely areas of interest and then ask questions of any actors connected with these. There is, however also a danger here as some prior knowledge means that it is quite possible to think you know something that you do not. Knowing that my own background could potentially influence my judgement on the nature and importance of what was going on in the curriculum innovation I was investigating I have been at particular pains to ensure that any such influence was reduced as much as possible. I have attempted never to act on assumptions that I did not later check. In attending to problems of this sort, Goodson (1991 :135) suggests that ‘triangulation’, through multiple interviews and the examination of written documents can assist, at least in part. In actor-network theory however, the aim is not to get to a single truth but to move towards an understanding of how negotiations led to the positions occupied by each of the actors. The important thing is to make sure that all actors - both human and non-human, are ‘consulted’ and that their viewpoints are represented faithfully.

Research Methods Actor-network theory has no unique set of methods with which it is associated, but makes use of many of the same techniques as ethnography and case study. The main advice on method suggested by the proponents of actor-network theory is to “follow the actors” (Callon 1986a; Callon 1991; Latour 1996) and to let them set the framework and limits of the study themselves. In investigating the adoption of Visual Basic at RMIT, following Latour (1996) this involved the murder mystery-like approach of asking questions of lecturers, laboratories, computers, Course Advisory Committees, the Head of Department, programming languages, Microsoft, IS courses, and professional societies involved in the innovation in an attempt to ascertain their level of involvement. In common with case study techniques the other main piece of advice from Aramis is to allow time for reflection and organisation of the data. Latour’s book (1996) tells the story of Aramis simultaneously from several different perspectives using a number of different ‘voices’. A young engineer and the sociologist, Norbert, conducting the investigation carry the story line. The engineers and administrators who worked on Aramis speak through both


interviews and documents. The ‘author’ interjects from time to time to provide a sociological commentary, and later Aramis speaks on its own behalf. In the book, each voice, or ‘reality’ (Wertheim 1997) is identified by the use of a different typography. This style of writing provides an interesting and novel approach, elements of which have been adapted to the reporting of this study. A technique the young engineer describes is how Norbert would organise “meetings and confrontations” (Latour 1996 :6) in the evenings after the interviews to discuss the events of the day and to determine which actor to follow next. The sources of data used in Aramis are principally interviews and documents. Norbert suggests an approach to the young engineer by which these should be selected:

“You see my friend, how precise and sophisticated our informants are … They know everything They’re doing our sociology for us, and doing it better than we can; … just follow the players.” (Latour 1996 :10)

This piece of advice has been discussed before, and is common to Latour’s other writings and to those of Callon. The first question however is ‘Who are the actors?’ The answer Norbert provides to this is:

“As soon as somebody’s name is mentioned, you call him up, you make an appointment, and you go and see him.” (Latour 1996 :38)

He was, of course, not just referring to human actors.

The Process of Gathering and Analysing Data As with any research project, an investigation of the literature was where this study began. As already discussed I soon identified that most Information Systems curriculum literature relates to the content of IS courses; of what should be, and is being taught. Very little has been written describing the process of how decisions are made in determining curriculum content, particularly by individual lecturers, or on how researchers proceeded to gather their data. As a consequence, not much of the literature was useful in planning the collection of data or in the provision of useful directions or techniques. Of greater use was Latour’s (1996) description of the approach used in studying the successes, and ultimate failure of Aramis to be adopted as a new public transport system for the Petite Ceinture district in Paris. Latour relates Aramis’s fate in the form of a detective story, starting at a point where some preliminary information was available, asking questions, identifying actors, and following these actors in the directions they themselves suggested. In my study a starting point was found in Fred, and interviews with Fred pointed to other actors. Interviews of the human actors were of two types:

• the formal, tape-recorded variety, and • quick, informal, return-question sessions intended to elicit specific information.

Non-human actors were ‘interviewed’ firstly by asking humans about them, secondly by collecting written material in the form of product notes, advertising brochures, newspaper and magazine articles, reviews and academic papers, and thirdly by observing other actors negotiate with them. Given that all the written materials come from within the network represented by the non-human actor concerned, they must all tell something about this actor, or network of actors. Of course what one written account, the view of one actor, might tell may contradict the account of another actor as human actors will probably see the non-human under investigation from a variety of different perspectives. But ANT accepts this in line with Latour’s (1996) concept of relativistic sociology in which each actor


operates from within its own frame of reference, and the researcher finds out about the story from their perspective. The formal interviews with the human actors were semi-structured, or what Yin (1984) calls ‘focused’, with a list of possible questions being prepared before hand to suggest the general direction. In question here is who should identify the key issues: the interviewer or the interview subject. ANT requires that it should be the interview subject who determines the issues, and to allow this to happen a good deal of freedom was allowed to these people in determining the way they answered each question. The direction followed by the interview was then adjusted in response to this. My agenda was always to try to ask questions to find out about how networks were formed that facilitated the adoption of Visual Basic. I asked about things that previous interviewees had spoken of, and things that I guessed might have helped or hindered VB’s adoption. For instance, Fred speaking of the possible affects of RMIT’s process of Educational Quality Assurance on curriculum change created a whole new list of actors to interview. I tried to get at how actors assigned or accepted roles, and how they saw the roles performed by others; anything at all that might have a bearing on the study. Examples from some of the interviews, which were tape-recorded, will be given shortly. As soon as possible after each interview I typed up as near to a verbatim transcript of each tape as was possible, showing both my questions and their answers. The interviewee was then presented with a copy of the transcript and asked to check it for accuracy to see if it truly represented what they had meant. Any suggested changes were then finally incorporated into the transcript. Although making extensive use of a computer in many activities I did not attempt the use of text analysis software in handling this material. After the interviews, and sometimes after the transcripts were complete, in some cases I found it was necessary to again contact the interviewee for clarification of a particular point, or to tease out some aspect of an inter-relationship. Another problem of course, is the classic difficulty of the interviewer affecting the nature of the data he is trying to obtain. A parallel with the case of Schrodinger’s Cat, a mythical beast from quantum mechanics, may be appropriate. In quantum theory the making of a measurement inevitably affects the object being measured: Heisenberg’s Uncertainty Principle (Hawking 1989 :58-60; Jungk 1956). There is no way around this, although the degree to which it is a problem depends on the scale of the phenomenon. With interviews of this type all that the interviewer can do when enrolling the interviewee into his research network is to be aware of this difficulty and take as much care as possible not to lead the subject into making particular responses.

Ethical issues in data gathering and reporting In conducting this research every effort was taken to ensure that it was approached ethically, and in broad agreement with Central Queensland University’s Guidelines for the Conduct of Research. All (human) participants in the study were volunteers from the RMIT University community selected on the recommendation of the small group of actors identified at the beginning of the study on the basis of their knowledge of, and involvement in, the curriculum innovation under consideration. All were issued with an information leaflet advising them of the nature and purpose of the research, and all signed the standard consent forms. In an attempt at fairness and consideration to participants, each interview was conducted sensitively in an open, non-threatening, non-confrontational style. Few participants had any objection to being identified by name, but for the benefit of the few who were reluctant to have their names mentioned the identities of those interviewed


have been concealed by the use of pseudonyms. I acknowledge the impossibility of completely disguising the identity of every participant, particularly from other academics at RMIT, even by the use of pseudonyms. Given this constraint, however, I have made every effort, consistent with the need to accurately report the data obtained, to protect privacy and minimise any possible harm that might be caused to any individual involved in the study. I have done this by careful consideration of the use of language used to describe their contribution, and by omitting any non-critical details that I judged might compromise any individual. Actor-network theory requires that agnosticism (Callon 1986b) be maintained in the treatment of all actors, whether human or non-human, and a consideration of the ethical issues of the study would not be complete without an attempt to relate these issues also to the study’s non-human participants. While some of these matters, such as obtaining informed consent for example, cannot easily be applied to non-humans, other issues can. Issues like that of minimisation of harm can apply to non-humans, and care can be taken to ensure that these actors are treated fairly and sensitively. All original data, including tape recordings and interview transcripts, has been retained for safe keeping in a locked filing cabinet. Actors in this study A number of actors were interviewed; the humans with the aid of a tape recorder, and the non-humans with the assistance of intermediaries or other actors to speak on their behalf. The following list gives only the main actors28 interviewed as to include details here of all the other actors would not be practical.

� Fred Senior lecturer at RMIT - three tape recorded interviews and several short discussions

� John Head, Department of Business Computing at RMIT - tape recorded interview and several short discussions

� Paul Senior lecturer at RMIT - two tape recorded interviews and several short discussions

� Rebecca Senior lecturer at RMIT - two tape recorded interviews and several short discussions

� Stephen Senior lecturer at RMIT - tape recorded interview and several short discussions

� Henry Lecturer at RMIT - tape recorded interview and several short discussions

� James Senior lecturer at RMIT - interview and several short discussions

� Patricia Senior lecturer at RMIT - tape recorded interview

� Donald Chair, Department of Business Computing Course Advisory Committee and also an academic from Deakin University

- tape recorded interview (and other interviews from previous research)

28 Pseudonyms are used throughout the study with real names concealed as far as possible.


� Jean Member, Department of Business Computing Course Advisory Committee and also an academic from Victoria University

- tape recorded interview

� John Bowden Director of Educational Program Improvement (and EQA), RMIT - tape recorded interview, several academic papers

� Roy Faculty of Business Director of Teaching Quality, RMIT - tape recorded interview

� Visual Basic Programming language - information from: Microsoft Web pages, Alan Cooper’s Web

pages, Fred, Paul, textbooks, programming manuals, personal knowledge, VB software, newspaper and magazine articles, journal articles

� Pick Operating system and programming language - information from: Stephen, Fred, Paul, Pick Systems Web pages

� Alice Computer simulator and low-level programming language - information from: James, conference proceedings papers, Alice

manual, Alice software, Rebecca, John

� RMIT RMIT University - information from: John, Fred, Stephen, James, Geoff, Gerry

Maynard, Donald, John Bowden, Jean, Course Advisory Committee, RMIT Web site, RMIT history books, Faculty handbooks

� PIT Phillip Institute of Technology - information from: Fred, John, Gerry Maynard, Donald, Jean,

Faculty handbooks

� RMIT EQA Educational Quality Assurance system - information from: John Bowden, Roy, Fred, Paul, Rebecca,

Patricia, John, journal articles, RMIT Web site, RMIT publications

� CAC Department of Business Computing Course Advisory Committee - information from: Donald, Jean, John, Fred, Paul, internal

department memos

� Curriculum Information Systems curriculum at RMIT - information from: Fred, John, Paul, Rebecca, James, Stephen,

Patricia, Faculty handbooks, course accreditation documents, Course Advisory Committee, course and subject documents, ACS accreditation documents

In this study interview data has been referenced in the same way as other material, with a textual reference such as (Fred 1988) indicating an interview with Fred. Further details of the interview are given in the Bibliography. The account that follows gives an indication of how the research progressed, tracing the research process chronologically as far as possible. From a fairly obvious starting point the research went off on several different tracks as a number of leads were followed. Some turned out to be more important than originally thought, others less so. The answers to some questions led to new questions while others suggested that previous interpretations needed to be modified. For instance, interviews with Henry (1997) and Bob (1997), a visiting scholar from the United States, suggested that a new network in object-oriented


technology was in the process of forming in response to curriculum innovation in this area. I had known little of the extent of this network and it suggested a whole new set of questions to ask of several of the human actors including Fred and John, and some new non-human actors to interview.

Figure 5.1 The Research Process

The Research Process The research process followed was far from linear and was not just simply a matter of collecting data, analysing the data, then writing it up. The process could better be seen as an iterative one, something more like that shown in Figure 5.1 above. The approach was to search continually for new actors and to investigate how these actors formed alliances to create or strengthen their networks. It involved continually asking questions like: ‘which networks now exist?’, ‘to what extent are these networks durable?’, ‘are they in contention with other networks?’ As questions are asked more questions are

Overview of the adoption of Visual

Preliminary identification of actors

Analyse networks and alliances

Interview actors to gather data

Final write up

Build up whole picture

Begin writing up of analysis

Look for translations

Look for missing links

New actors or alliances identified

New actors or alliances identified

Identify ‘key moments’ for ANT treatment


suggested by the answers, and the process goes on. Once the first actors were identified and interviewed, networks and new actors emerged. It was then necessary to ‘loop back’ to interview these new actors and to analyse the networks and alliances that had formed. Sometimes this analysis uncovered additional new actors that had to be interviewed, and the process looped again. Translations of Visual Basic into different forms that led to adoption and a search for missing links caused more loops, in each case requiring more interviews. So the process went on. In the next few pages I will give examples of each of these stages, and how they resulted in the conduct of more interviews. As writing up progressed, it became apparent that the complete study was too large to subject all parts of it to an actor-network analysis. I decided instead to identify a number of key moments; particular events which seemed, to the actors, to be crucial in forming the actor-networks of interest, and to make use of an actor-network approach to describe just these moments. Although the role of the researcher in deciding which key moments to include must be acknowledged, the choice was not arbitrary. In identifying these key moments, I made every effort to allow the actors themselves to identify what they saw as pivotal and important. Overview of the Adoption of Visual Basic As I already knew that Fred used Visual Basic in his teaching at RMIT, talking with him seemed the best place to start this investigation and in July 1997, Fred and I had several informal discussions. I was keen to get an idea of the basic story and to identify some of the important actors so I began by establishing the current situation regarding the place of Visual Basic in the RMIT curriculum. I determined that it is presently used in two subjects: the elective *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ and the core subject $SSOLFDWLRQV'HYHORSPHQW�,,. Fred also mentioned that there was an on-going discussion in progress on the need to introduce object-oriented programming somewhere in the degree course. He was concerned about the effect this might have on the use of Visual Basic. When asked how Visual Basic had been introduced Fred said that it was formally introduced into the curriculum only after the merger. He mentioned that he had ‘discovered’ VB while at Phillip Institute and had been ‘playing around’ with it there. At RMIT before the merger the main programming languages used were Alice - a machine/assembly language simulator, and Pick/BASIC. RMIT did not then use Visual Basic. At this stage it was possible to identify a number of actors that probably had a place in the story.

$FWRUV LGHQWLILHG�$FWRUV LGHQWLILHG�

- WKH WZR WHUWLDU\ LQVWLWXWLRQV 3,7 DQG 50,7� 9LVXDO%DVLF� WKH VXEMHFWV ZKHUH 9% ZDV WDXJKW� 3LFN�%$6,&�$OLFH� DQG )UHG�

)XUWKHU LQWHUYLHZV DQG LQYHVWLJDWLRQV VXJJHVWHG�)XUWKHU LQWHUYLHZV DQG LQYHVWLJDWLRQV VXJJHVWHG�

- )UHG VXJJHVWHG WKDW 6WHSKHQ � WKH OHFWXUHU ZKR KDGLQWURGXFHG 3LFN�%$6,&� -DPHV � WKH GHVLJQHU RI $OLFH�-RKQ � +HDG RI 'HSDUWPHQW� DQG 3DXO DQG 5HEHFFD �DFDGHPLFV FXUUHQWO\ WHDFKLQJ WKH VXEMHFWV XVLQJ 9%�ZRXOG EH ZRUWK LQWHUYLHZLQJ�

- )UHG DOVR VXJJHVWHG WKDW DQ LQYHVWLJDWLRQ RI 50,7·VV\VWHP RI (GXFDWLRQDO 4XDOLW\ $VVXUDQFH �(4$� ZRXOG EHXVHIXO�

It seemed likely that significant networks had formed around Pick and Alice and that it would be worthwhile investigating their formation and maintenance. From the way Fred


described it, EQA appeared to be having a significant affect on curriculum development at RMIT and so it looked worth finding out more about this also. This seemed a good place to look next, so a formal interview on EQA was arranged with Fred for early August. Actors and Networks in Information Systems at RMIT The notion of a heterogeneous network is used to deal with the interconnected character of the social and the technical (Law and Callon 1988) and to argue that society, agents, organisations, technology and machines are all network effects (Law 1992). An actor, or actant, is an abstraction that assists in the analysis of situations involving heterogeneous entities (Law 1992). The important thing about these actors is that they must be able to make their presence individually felt (Law 1987). If they exert no noticeable effect or they make no difference, then it is not necessary to acknowledge their existence. An actor can be anything, as long as it is the source of an action, or activity is granted to it by others (Latour 1997). There are three principal actors/networks in this study: Visual Basic, Fred, and RMIT. Each of these actors made its presence individually felt, but in quite different ways. Visual Basic, in its MS-DOS form, attracted Fred’s attention and then evolved to meet changing needs. After discovering VB, Fred played with it in several subjects at PIT, then spoke for its adoption in the RMIT curriculum. RMIT itself made its presence felt by taking the formal adoption decision to allow VB into its curriculum, but doing so on the basis of negotiations within its own network. A large cast of supporting actors worked to assist, and to oppose, these actors in finding Visual Basic a place in the RMIT curriculum. The Head of Department, although needing to maintain impartiality, generally supported the adoption. Other academic staff were at first dubious and had the potential to oppose. Most soon became supporters. Computing Services and the RMIT student laboratories were willing to try something new and when they found it created no problems they accepted it. The Course Advisory Committee was not against Visual Basic, being a ‘real’ programming language used by the computer industry, but were in a position to make their presence felt if they had not approved the adoption. Actor-network theory has little to do with the study of social networks which is concerned only with the interactions of individual human actors (Latour 1997). In ANT, a network is defined by the presence of both human and non-human actors that work to create associations (Courtial, Cahlik et al. 1994) and relationships between themselves (Mol and Law 1994). The RMIT Information Systems curriculum, for instance, is a network containing the RMIT Department of Business Computing, the Head of Department, Fred, other academic staff, curriculum documents, student laboratories, Computing Services, software, programming languages, text books, the Course Advisory Committee, and students. A feature of actor-network theory is its ability to punctualise (Law 1992) a network to consider it as an actor; to black-box it. ANT will do this when the internal details of a network’s operation are not being investigated. In this way when we speak of the RMIT Information Systems curriculum we are really speaking of the actions of the whole cast of actors which it subsumes. At any convenient later stage the lid of the black box can again be opened and its component actors and intermediaries further examined.

“An actor-network is simultaneously an actor whose activity is networking heterogeneous elements and a network that is able to redefine and transform what it is made of.” (Callon 1987 :93)

The distinguishing thing about an actor-network (de Vries 1995) is that each actor is made up only of its interrelations with other actors, and nothing has any intrinsic features of its


own about which we need be concerned. The term actor is used to means both action and behaviour (Latour, Mauguin et al. 1992) and to define an entity only by those actions in which it is engaged. Latour (1997) maintains that there is nothing but networks, and that nothing exists between these networks; that there is no ‘aether’29 to fill in the space. De Vries (1995) illustrates this point with a quote from Nietzsche:

“The properties of a thing are its effects on other ‘things’. If I remove all the relationships, all the ‘properties’, all the ‘activities’ of a thing, the thing does not remain”. (Nietzsche, quoted in de Vries (1995))

Latour (1997) describes ANT as simultaneously rejecting the need to consider any form of naturalisation, socialisation, or textualisation as these represent attempts at filling in the space between the networks. As networks have no in-between and do not need to be filled in there is nothing to be gained by adopting one of these approaches rather than another. Although human actors can become a source of action in their own right, non-human actors must have activity granted to them by others (Latour 1997). We must then question how Visual Basic acts and how it can evolve into new forms. The answer is that it depends on what you mean by Visual Basic. If you mean the shrink-wrapped package containing a CD, licence agreement and manual that sits on the shelf of the software retailer, then obviously this cannot possibly adapt or take any action at all, except perhaps to look attractive to a potential buyer. What actor-network theory takes a non-human actor like Visual Basic to be is, however, quite different. ‘Visual Basic the actor’ is the punctualised form of ‘Visual Basic the network’ which contains a large number of other actors, including: the Microsoft Corporation, Bill Gates, teams of software development engineers, computers, the C programming language (in which VB is written), marketing people, sales surveys, management staff, administrative staff, advertisements, customers, and so on. What actors such as John or Fred are getting at when they later speak of Visual Basic evolving into a more object-oriented form30 is that engineers from Microsoft, on advice from the Microsoft marketing department and consumers, make changes to VB that they estimate will bring more sales by fitting it better for current or future markets. It is convenient to speak of Visual Basic adapting, but what happens is that some of the actors that constitute VB, some of the actors inside VB’s black box, grant this activity to VB. This is not much different from saying that when we speak of a car changing direction to avoid a pedestrian the driver grants the car action by turning its steering wheel. Interviewing Actors and Gathering Data Fred’s (1997a) interview provided an overview of how EQA worked at RMIT as he saw it. He described how RMIT had adopted a process of Educational Quality Assurance31 in late 1994 in response to the Commonwealth Government’s Quality Rounds. He maintained that EQA at RMIT prevents ‘ill-considered’ curriculum changes by requiring all changes to be discussed by the Course Teams and to go through a formal process. He indicated his belief that ‘good’ changes would not be hampered by EQA. Fred admitted, however, to being a fan of the EQA process and that as he had worked as an EQA Reviewer for a couple of years he may have had a different view of its benefits and problems than some others in the department. He suggested that I should also speak with Paul (Course Coordinator of the Degree), Rebecca (Course Coordinator of one of the Graduate Diplomas) and Patricia (Course Coordinator of the other Graduate Diploma). Fred said that as they had to chair the 29 Latour’s reference here is to the Michelson-Morely experiment (1887) in physics which showed that light

could propagate through space without the necessity of a propagation medium or ‘aether’. 30 See Chapter 10. 31 See Appendix A.


Course Team meetings required by EQA, these people could probably give a better indication of the effect of EQA on curriculum development than he himself could. Paul’s course (Bachelor of Business in Business Information Systems) was to undergo a Quality Review in late 1997 and this was creating a great deal of work for him. As a consequence he was, at that stage at least, not especially happy with EQA. Paul (1997a) described how EQA works with a course like the degree. He suggested that a major feature of EQA was the Course Team meetings that occurred once a month and at which curriculum changes were discussed. He said that this part of EQA worked well but that the administrative load required of the Course Coordinator in keeping the detailed records on all comments, suggestions, complaints, evaluations and changes was too great. He indicated his belief that EQA acts to slow down curriculum development. Rebecca’s course (Graduate Diploma in Applied Information Systems) was also due for a Quality Review later that year. At her interview Rebecca (1997a) suggested that EQA offers no real benefits for curriculum development. Patricia’s course (Graduate Diploma in Business Systems) was reviewed the previous year and so she was a little more relaxed, if cynical, about the EQA process (Patricia 1997). Like Rebecca, she believed that EQA had no beneficial effect on curriculum development, but added that she thought it probably had no effect at all. It was thus not clear, at this stage, to what extent EQA would be significant to this study.

- 6R (4$ LV LPSRUWDQW DQG GRHV KHOS FXUULFXOXP FKDQJH�RU(4$ VORZV GRZQ FXUULFXOXP FKDQJH� RU(4$ KDV QR HIIHFW RQ FXUULFXOXP GHYHORSPHQW DW DOO�

- )XUWKHU LQYHVWLJDWLRQ RI (4$ ZLOO EH QHFHVVDU\�

- (4$ ZDV RQO\ LQWURGXFHG LQ �� VR SUREDEO\ KDG QRHIIHFW RQ WKH FXUUHQW FRXUVH GHVLJQ PRVW RI ZKLFKEHJDQ EHIRUH WKLV WLPH�

- ,W LV OLNHO\ WKDW (4$ ZLOO DIIHFW IXWXUH FXUULFXOXPFKDQJHV�

- 6RXUFHV RI OLWHUDWXUH RQ (4$ ZHUH LGHQWLILHG�

- 7ZR PRUH SHRSOH WR EH LQWHUYLHZHG� -RKQ %RZGHQ �'LUHFWRU RI WKH (GXFDWLRQDO 3URJUDP ,PSURYHPHQW JURXSDW 50,7� DQG 5R\ � WKH IRUPHU )DFXOW\ RI %XVLQHVV'LUHFWRU RI 7HDFKLQJ 4XDOLW\�

- (4$ LV D SRVVLEOH DFWRU WKDW PD\ DIIHFW FXUULFXOXPLQQRYDWLRQ�

Investigating Pick/BASIC and Alice Networks at RMIT Before the Merger Before these EQA interviews could be completed however it became necessary to find out more about programming while those involved had the time to talk with me. This was opportune also as it had not been possible to arrange an interview with John Bowden until the following month. An interview with Stephen (1997) revealed that he had been involved with Pick, and its programming language Pick/BASIC, since its introduction at RMIT in the mid 1980s. He described how and why Pick was chosen, and why it has remained an important actor. It quickly became clear that Stephen had championed Pick in the curriculum at RMIT both before and during the merger, and that he continued to be a significant supporter of Pick. Apparently a quite durable Pick network existed. This would need further investigation.


James was still a little bitter that Alice had lost its place in the curriculum (James 1997). Like Pick, Alice was introduced in the mid 1980s and was a significant actor before the merger, but not now. The question of how this happened would need to be investigated.

- $OLFH DQG 3LFN DUH HYLGHQWO\ ERWK LPSRUWDQW DFWRUV�

- 7KHUH LV D QHHG WR IROORZ XS WKH IRUPDWLRQ DQG�DSSDUHQW� EODFN�ER[LQJ RI WKH 3LFN QHWZRUN�

- ,V WKH 3LFN QHWZRUN DV GXUDEOH DV LW VHHPV" :K\ LVWKLV"

- 1HHG WR VSHDN WR RWKHU SHRSOH DERXW 3LFN� 6SHDN WR-RKQ DERXW 3LFN GXULQJ WKH PHUJHU� RWKHU DFDGHPLFVWDII� &RXUVH $GYLVRU\ &RPPLWWHH�

- )LQG RXW DERXW WKH ODQJXDJH 3LFN�%$6,& LWVHOI�

- /RRN IRU DQ\ GRFXPHQWDU\ LQIRUPDWLRQ DERXW 3LFN DQGLWV �DSSDUHQW� VXFFHVV DW 50,7�

- +RZ GLG WKH VWUHQJWK RI VXSSRUW IRU 3LFN DIIHFW WKHLQWURGXFWLRQ RI RWKHU ODQJXDJHV� HVSHFLDOO\ 9%"

- )LQG RXW DERXW WKH $OLFH SURJUDPPLQJ ODQJXDJH�

- :K\ GLG $OLFH ORVH LWV SODFH LQ WKH FXUULFXOXP"

- ,W LV EHFRPLQJ DSSDUHQW WKDW WKHUH ZLOO QHHG WR EH DVHFWLRQ RI WKH ILQDO DFFRXQW GHDOLQJ ZLWK SURJUDPPLQJDW 50,7 EHIRUH WKH PHUJHU�

Discussions on Object-Oriented Programming: Network Formation On the suggestion of John in a brief meeting in the corridor one day, Henry was the next person to be interviewed. John suggested Henry as he does not teach programming and so has a different perspective on this curriculum area. In the interview Henry (1997) confirmed the importance of Pick, but indicated that he had not been at RMIT long enough to know much about Alice. He spoke of a debate going on at this time on the need to introduce object-oriented programming into the curriculum and that if this material goes into the final programming subject as seems likely, then this may have an effect on the place of VB in the penultimate subject. Bob (1997), a Visiting Professor from the USA, had catalysed the debate which was now engaging many of the teachers of programming along with the Head of Department.

- 7KHUH DSSHDUV WR EH DQ ¶22�WHFKQRORJ\· QHWZRUN LQIRUPDWLRQ� 7KLV ZLOO QHHG IXUWKHU LQYHVWLJDWLRQ�

- 22 WHFKQRORJ\ LGHQWLILHG DV DQ DFWRU WKDW PD\ DIIHFW9%·V ORQJHYLW\ LQ WKH FXUULFXOXP�

- 1HHG WR LQYHVWLJDWH 9%·V FUHGHQWLDOV DV DQ 22 ODQJXDJHDQG DV D ODQJXDJH WKDW FRXOG EH XVHG DV D OHDG�LQ WR22 SURJUDPPLQJ�

- ,W DSSHDUV WKDW WKHUH ZLOO QHHG WR EH D VHFWLRQ RI WKHDFFRXQW GHDOLQJ ZLWK WKH FXUUHQW GHEDWH RQ REMHFW�RULHQWHG SURJUDPPLQJ DQG KRZ 9% KDV UHWDLQHG LWV SODFHLQ WKH FXUULFXOXP�

Introduction of Visual Basic and How its Network Formed Following suggestions by John and Fred the next group of actors to be interviewed where the lecturers now teaching with Visual Basic: Fred, Paul and Rebecca. Paul is now a Senior Lecturer at RMIT but had originally been a Secondary School Teacher and had followed Fred from Whittlesea Technical High School to PIT and finally to RMIT. Paul thus knew a


good deal of the background of what Fred had been doing with Visual Basic and so was interviewed next. Paul (1997b) spoke a little of Fred using VB at Phillip and how he had acted as a tutor in some of the subjects where Fred experimented with VB. He suggested that Fred himself would be the best one to remember all the details. Paul clearly confirmed Fred as the principal instigator of Visual Basic at PIT and RMIT. He also spoke of the strength of Pick and how its place in the RMIT curriculum seemed quite secure despite frequent challenges. Rebecca (1997b) is also a Senior Lecturer but was at RMIT, rather than PIT, before the merger. Like Paul, she currently teaches into the two subjects using Visual Basic in the degree. Rebecca confirmed that Visual Basic was not used at RMIT before the merger. She herself knew of its existence in the early 1990s but had not made any serious use of it until she saw Fred using it at PIT at the time of the merger. She also agreed that Fred was the ‘force behind the introduction’ of Visual Basic. Being a lecturer at RMIT in the late 1980s, Rebecca was able to shed more light on how Stephen, and others, had built up the Pick network by recruiting allies from the Course Advisory Committee and from industry. There appears to have been no significant counter to Pick, at least in its early days, and a major consideration appears to have been the ‘niche market’ that teaching Pick/BASIC provided for RMIT students. But Pick is under some challenge now. Rebecca also spoke of Alice and of its role in programming. Having presented a couple of papers at CEGV32 conferences with James on Alice and computer simulators she knew quite a lot of Alice’s background. She suggested that Alice had outlived its usefulness as this level of assembly language and machine detail was no longer needed by Information Systems students.

- )ROORZ XS WKH &RXUVH $GYLVRU\ &RPPLWWHH·V UROH LQVWUHQJWKHQLQJ WKH 3LFN QHWZRUN� ,W DSSHDUV WKDW WKLVZDV VLJQLILFDQW�

- :KDW LV WKLV QLFKH PDUNHW WKDW 3LFN FODLPV" ,V WKLVLPSRUWDQW"

- 3LFN DQG 6WHSKHQ� $OLFH DQG -DPHV DUH FRQILUPHG DVLPSRUWDQW DFWRUV�

- )UHG FRQILUPHG DV WKH KHWHURJHQHRXV HQJLQHHU �/DZ�� ZKR EXLOW XS WKH 9% QHWZRUN ERWK DW 3KLOOLS,QVWLWXWH DQG DW 50,7 DIWHU WKH PHUJHU�

- $OLFH LV QRW XVHG QRZ EHFDXVH LW KDV ¶RXWOLYHG LWVXVHIXOQHVV·�

The interview with Fred (1997b) was an important one, as after speaking with Paul and Rebecca there were now some things that needed to be confirmed and filled out. This was to be another overview discussion of the whole story from VB’s introduction at PIT to the present time. Fred was asked when and how he learned about VB when he was at Phillip Institute, and how and why he introduced it there. He indicated that it was in conjunction with some work he had done with his son George that he had first encountered Visual Basic. Fred confirmed interpretations of the earlier informal discussions and spoke more of how he had ‘played’ with Visual Basic in several subjects at PIT in the early 1990s. He also spoke of the merger, and of the struggles involved in building the new degree course during that period. He suggested that John would know more of the curriculum battles that had been fought as part of the merger.

32 Computing in Education Group of Victoria - a group of teachers mainly concerned with

Computer Education at the school level.


Fred also handed over minutes of meetings, discussion papers and memos that he had retained from the time of the merger discussions and the building and accreditation of the new degree course. John was Head of the Department of Business Computing at Phillip Institute immediately before the merger, and followed up in this role at RMIT during and after it. In a long discussion (John 1997) on the broad sweep of curriculum development at RMIT he was able to describe many of the interactions that had occurred and to suggest an interpretation for these events. He gave his views on how EQA affected the curriculum, suggesting that Fred was right and that it had become an important actor and would be so into the future. He also confirmed that EQA took no part in the course design during the merger, but would affect future course developments. John was able to provide confirmation of what several of the others had said, plus some frank insights into the politics of the merger. He also suggested discussions with some members of the Course Advisory Committee. As a teacher of programming himself John was able to shed some light on why Pascal, used at PIT, had not been adopted at RMIT. He suggested that this related to RMIT’s culture of using only ‘real’ examples of what is used in industry and commerce. Although Cobol must be seen as a ‘real’ programming language it has fallen from grace in the curriculum and John suggested that this was partly due to its image among the students and academic staff as ‘old hat’, and partly due to the difficulty it had fighting for a space against Pick.

- 7KH FDVW RI DFWRUV KDV QRZ HQODUJHG WR LQFOXGH )UHG�*HRUJH �KLV VRQ�� 3DXO� 5HEHFFD� 3DWULFLD� -RKQ�6WHSKHQ� 3LFN�%$6,&� -DPHV� $OLFH� &RERO� 3DVFDO� 06�'26� 4XLFN%DVLF� 9% IRU '26� FRPSXWHU JUDSKLFV�FRPSXWHU VFUHHQV� :LQGRZV� 9% IRU :LQGRZV� 50,7�&RPSXWHU 6HUYLFHV� VWXGHQW ODEV� &RXUVH $GYLVRU\&RPPLWWHH� DQG SRVVLEO\ (4$�

- 7ZR PRUH VWDJHV DUH VXJJHVWHG IRU WKH VWRU\� KRZ )UHGLQWURGXFHG 9% DW 3KLOOLS ,QVWLWXWH EHIRUH WKH PHUJHU�DQG KRZ WKH QHZ FRXUVH ZDV GHYHORSHG GXULQJ WKHPHUJHU�

Follow-Up Interviews and Data Gathering Concurrently with these interviews, a study of the EQA literature from RMIT and elsewhere showed that a lot of people do think that EQA has an effect on how curriculum development works. When he became available, an interview with John Bowden, Director of the Educational Program Improvement group at RMIT which oversees the EQA process (Bowden 1997a) filled in a lot more of the gaps here and showed what RMIT saw as the benefits of EQA and why it was introduced. Bowden acknowledged that mistakes had been made in the implementation of the EQA process at RMIT, and that these accounted for some of the suspicion with which it is now held. He added his weight to the view that EQA has had a significant effect on curriculum development since its introduction. Roy, the Faculty of Business Director of Teaching Quality (Roy 1997), had a lot to do with implementing EQA at a more local level and provided a Faculty perspective on how EQA works. He also confirmed EQA as an important actor in new curriculum developments at RMIT, but indicated that it would not have played a significant part in curriculum innovations that took place before about 1995. In the next few months a lot of follow-up work took place beginning with a collection of the Faculty handbooks from the present time, back to those from Phillip Institute and RMIT in the years before the merger. As far as they were available, subject outlines of the


programming subjects were also collected. The handbooks and subject outlines showed the progression of programming languages and added detail to some of the interview material. The development history of Pick, Alice and Visual Basic was also investigated. None of these languages stood still during the period of the study; Pick and Visual Basic responding by changing in what they saw as directions that would make them more popular in the commercial world, and Alice by adding more features to become a better simulation. Follow-up questions were asked of Fred, Paul, Stephen and John on details of what they had said in their interviews.

- (4$ LV FRQILUPHG DV DQ LPSRUWDQW DFWRU LQ UHODWLRQ WRIXWXUH FXUULFXOXP GHYHORSPHQW DW 50,7� ,W LV DOVRFRQILUPHG WKDW LW KDG QR HIIHFW RI WKH GHYHORSPHQW RIWKH SUHVHQW FRXUVH EHIRUH ��

- ,W LV QRZ FOHDU WKDW WKH FXUULFXOXP GHYHORSPHQWSURFHVV WKDW OHG WR WKH DGRSWLRQ RI 9% LQYROYHGVHYHUDO VWDJHV�

¾ )UHG GLVFRYHUV 9% DQG H[SHULPHQWV ZLWK LWV XVHDW 3KLOOLS�

¾ 7KH VLWXDWLRQ ZLWK 3LFN DQG $OLFH DW 50,7 EHIRUHWKH PHUJHU�

¾ 7KH SURFHVV RI PHUJLQJ WZR LQVWLWXWLRQV DQG WZRFRXUVHV WR SURGXFH D FRPPRQ FXUULFXOXP�

¾ :K\ 9% KDV VXUYLYHG DQ 22 FKDOOHQJH WR UHPDLQ LQWKH FXUULFXOXP�

- ,W ZDV GHFLGHG WR DWWHPSW WR DQDO\VH DQG WHOO WKHVWRU\ XVLQJ WKHVH IRXU SKDVHV�

- 0HPEHUV RI WKH &RXUVH $GYLVRU\ &RPPLWWHH QHHG WR EHLQWHUYLHZHG�

- 0RUH TXHVWLRQV QHHG WR EH DVNHG RI )UHG� HVSHFLDOO\DERXW WKH GLVFRYHU\ DQG H[SORUDWLRQ RI 9% DW 3,7�

At this time a preliminary write-up of the four phases of the study was begun. This included much of the data gathered, but with little analysis. The question now was: how are the accounts from each of the actors to be analysed? Another re-reading of actor-network literature regarding analysis suggested some possible approaches and I set out to identify and describe each of the actors and to further investigate the construction of networks through problematisation, interessement, enrolment and mobilisation33 of these actors. Most of the data on the second phase - Prior Claimants at RMIT - had now been collected, thanks to contributions from John, Stephen, James, Rebecca and the RMIT Faculty handbooks and similar materials. This was next written up and analysed, with frequent returns to the interview transcripts and also to ask more questions of several of the actors. Both now and later the advantage of having some previous knowledge of RMIT, PIT, Visual Basic, and a number of the people involved became significant. I found that this previous knowledge meant that I had been able to cover a lot of material I needed in the original interviews and that I could come back to this now. This meant that the number of times I had to go back to the interviewees for more information was not as great as it might otherwise have been.

33 See Chapter 4.


Interviewing the Course Advisory Committee John, Fred and others had suggested that I should take a look at how the Course Advisory Committee operated, so the next interviews were with two of its members. Jean has been a member of the Course Advisory Committee for a considerable period of time and indicated in her interview (Jean 1998) that she also chaired the committee on a number of occasions when required. She noted that she had also been a member of the corresponding committee at Phillip Institute before the merger. Jean gave her views on how the committee operated, who the key people were, and what influence they had. Donald (1998) was Chair of the Course Advisory Committee during the period of the merger. He was able to loan copies of minutes and other documents that proved useful in seeing what the Committee had discussed on programming languages and, in particular, what they thought made a language most suitable for study in the RMIT Information Systems curriculum. It was quite clear that the committee was concerned that, as far as possible, only ‘real programming languages’34 were used. Donald also spoke of the importance of the ACS course accreditation process and described something of the history of RMIT’s earlier disagreements with this process (Juliff 1990; Maynard 1990; Geoff 1992). The ACS involvement added three more actors: the ACS, the various model curricula used for comparison purposes to evaluate the course, and Geoff - the former Head of Department.

- 1HZ DFWRUV DGGHG� &RXUVH $GYLVRU\ &RPPLWWHH� 'RQDOG�-HDQ� *HRII� $&6� PRGHO FXUULFXOD�

- $&6 DFFUHGLWDWLRQ SURFHVV LV LPSRUWDQW DQG VKRXOG EHIXUWKHU LQYHVWLJDWHG ZLWK -RKQ�

More Follow-Up Interviews I now had most of the material required for the third phase - The Merger, but was still missing some potentially important details of phase one - Discovery of VB at Phillip Institute. This called for another formal interview with Fred (1998) which began by asking what aspects of VB had initially interested him. He described first using the MS-DOS version and then moving to the Windows version when the student labs at PIT where changed over to Windows. He indicated the subjects at PIT where he had experimented with Visual Basic, and how he had done this. He said that he saw quite early that VB should fit well into the PIT curriculum, particularly after it added a Data Control that provided the ability to access other databases. A number of other informal interviews and discussions were conducted during the analysis. John, in particular, was accosted in the corridor on a number of occasions for confirmation of an idea or two to fill in a gap. There were also several other short meetings with Fred and Paul to establish details of the early days at PIT and what happened during the merger. Short discussions were held with several other teachers of programming including Wally, who described a study he had done comparing Delphi with Visual Basic. One of the last interviews was with Fred and Paul to discuss how the move to object-oriented programming had affected Visual Basic. The Information Systems curriculum at RMIT has undergone a great deal of change over the last few years but most of the staff now look forward to period of relative stability, at least for a couple of years, given the durability of the current programming language networks.

34 See Chapter 10.


Reporting the Study This chapter has described how I framed this study in terms of innovation translation, informed by actor-network theory. I have examined how the use of an actor-network approach works to minimise the problems that derive from attributing essential essences to humans and non-humans, how to handle the social/technical divide inherent in other methodologies, and how this led me to adopt actor-network theory in this study. I have also described how the research was conducted, attempting to retain a flavour of all the messiness involved in collecting and analysing the data. In the next few chapters I will relate the details of the study and analyse the adoption and retention of Visual Basic. To attempt to tell the story in the order that the data was gathered and the analysis performed would make it very difficult for a reader to follow. To make it easier to understand the formation and maintenance of networks and how some of these networks moved towards durability while others collapsed, the study will be reported in the following chapters in roughly a chronological order. I did consider whether to report the study this way might act to hide some of its complexity, an issue with which, as I have already noted, I was particularly concerned. I decided, however, that on balance this would not be the case. Telling the story in a chronological order might hide some of the complexity of the research process, but that process has been outlined as it happened in this chapter. I judged that to have told the story in the order I learned it would have run the risk of making it too difficult for a reader to appreciate and to follow. Hence the chronological approach. In line with ANT’s principles of agnosticism, generalised symmetry and free association (Callon 1986b), I have written to give agency to the non-human actors in the study. At times, writing in this way makes some of the expression sound a little strange, and may lead a reader with little previous exposure to actor-network theory to think that what is being suggested is that non-human actors are able to initiate action in their own right. On the contrary, however, this writing should be seen as an actor-network shorthand to indicate that such actions result from negotiations within the network that this non-human actor punctuates. As I pointed out in the first chapter, given my place in the story and the research approach used, in the next few chapters I will make use of the first person in the course of this account.


Chapter 6

Discovery and Exploration Entry of VB into the curriculum at Phillip Institute of Technology In 1999, alongside Pick/BASIC and Java, Visual Basic has become an accepted part of programming in the Information Systems curriculum at RMIT. Over the last four or five years the adoption of Visual Basic has changed the way programming is seen and understood at RMIT: it has changed the nature of business programming. This thesis examines how such change came about. It raises questions of the extent to which it was triggered by the merger with Phillip Institute, and what was understood by business programming before the merger. It examines how Visual Basic managed to redefine business programming from the approach offered in character-based procedural programming languages, to its own form of graphical, event-driven programming. The answers to these questions reveal something of the complexity of curriculum innovation in Information Systems and are the subject of the next few chapters. The first step in determining how Visual Basic achieved an enduring place in the Information Systems curriculum at RMIT was to investigate how it first entered the curriculum. It was to determine who, at RMIT, first found out about Visual Basic: who ‘discovered’ it. As discussed earlier, Fred is today seen as the foremost spokesperson for Visual Basic at RMIT (Paul 1997b) and so seemed a likely actor to follow in a search back to the starting point. In an early interview Fred (1997b) spoke of how he currently used Visual Basic in two subjects at RMIT, and of first finding out about Visual Basic while a lecturer at Phillip Institute before the merger with RMIT. As the only programming languages used in Information Systems at RMIT (City) before the merger were Pick/BASIC, Alice and Cobol (Stephen 1997) what had happened at Phillip Institute looked a promising place to start. The story of how Visual Basic (VB) was introduced into the Information Systems curriculum at RMIT and how it gained a durable place within this curriculum has a number of strands, each of which tells of a different series of related moments in the adoption of VB. As outlined in Chapter 1 the story will be told in four parts: Discovery and Exploration, Prior Claimants, The Merger, and Surviving an Object-Oriented Challenge in this, and the next three chapters. This first part of the study relates to discoveries and experiments with the teaching of Visual Basic at Phillip Institute of Technology (PIT) several years before PIT’s merger with RMIT. It begins in 1989 with the appointment of Fred to a lecturing position in the Department of Accounting and Electronic Data Processing (EDP)35 at Phillip Institute of Technology and investigates how Fred came across Microsoft Visual Basic; how he discovered it, and how he introduced it into the Information Systems curriculum at PIT. In common with the later parts of the account this first strand contains some elements of general narrative along with a description of several key events which I deem to be critical to the formation of the actor-networks of interest to the study. Given that the story as a whole is far too big to subject in its entirety to an actor-network analysis, I have used an

35 In 1990, the Department’s name was changed to ‘Department of Accounting and Business Computing’.


actor-network approach to describe just these key events; these important moments36. How Fred found out about Visual Basic is the first important moment of this story and constitutes the ‘Discovery’ of the chapter title. How he then became convinced that VB’s very different style of programming should be considered, investigated and eventually adopted in his teaching - ‘Exploration’, is the second important moment and will be described later in the chapter.

Problems when Programming with Graphics in MS-DOS Not long after his arrival at Phillip Institute, and with the encouragement of the Institute, Fred began to get involved in working on a number of small commercial programming projects on a private basis. The Institute encouraged work of this kind as it saw this as providing an avenue for academic staff to gain “experience of the business computing environment” (John 1997). It was through one of these commercial projects that Fred discovered Visual Basic. This section constitutes an actor-network-informed account of how, in the course of attempting to solve a programming problem unconnected with his teaching (Hefferlin 1969; Busch 1997; Stark and Lattuca 1997), Fred discovered Visual Basic and was enrolled by it; the first key event of the study. Fred (1997b) recollected that his first experience of Visual Basic was in late 1992, three years after his move to PIT, when he was working privately with his son George on a small commercial programming project in an MS-DOS environment37. When interviewed, Fred said he had forgotten the exact details of the project except that it was to be programmed in Microsoft QuickBasic, but George thought it involved a system for storing customer records in a local garage (George 1999). One aspect of the project required the display of a variety of different sized fonts, and some pictures, on the computer screen. George recollected that the client had two computers, one with a monochrome screen and the other with a high resolution colour screen. Displaying anything other than standard text on the computer screen presented considerable difficulties when using an MS-DOS programming language like QuickBasic as each different type and resolution of computer screen required a different MS-DOS screen-driver38. Unlike computers such as the Apple Macintosh, which is based on a propriety design inaccessible to other companies, Intel-based machines39 take an ‘open architecture’ approach which allows the inclusion of various third-party products such as mice, graphics cards and display screens. While this generally lowers the price of these products to the consumer, in the 1980s and early 1990s it also encouraged a diversity of standards that led to the need for special software, such as screen and other device-drivers, to link these up. The purpose of these screen-drivers was to achieve cooperation between the computer and a specific type of screen. It was to map the text from an area of computer memory onto the particular screen’s hardware and so cause some parts of the screen to appear bright, or to display a particular colour, while others remained dark. The goal of the screen-drivers was to induce the appropriate parts of the screen to change luminescence according to the wishes of the program running on the computer; to act as an ‘intermediary’

36 The language used in these sections thus reflects that used in actor-network accounts and some of it may, at

first reading, appear a little strange to anyone unfamiliar with ANT. 37 MS-DOS programming environments were largely non-graphical, offering just standard text on the display

screen. Programming in such environments was thus predominantly character-based rather than graphical. 38 A screen-driver is a computer program provided by the manufacturer of the computer’s graphics card. Its

purpose is to add a graphics capability to the MS-DOS operating system. 39 So called ‘IBM compatible’, MS-DOS / Windows computers.


(Callon 1991 :134) to get the screen and the program working together. The computer user then sees this interplay of light, dark and colour as text and pictures on the screen. There was, however, no single standard for computer screens and a colour screen, or one of a larger size or higher resolution, required more memory to be set aside and a different set of screen-drivers than a monochrome or lower resolution colour screen. Each of the different standards: CGA, EQA, Hercules Graphics and Monochrome Display Adaptor (MDA), required different screen-drivers to operate correctly. Each screen type jealously guarded its own standards, and steadfastly refused to listen to commands coming from screen-drivers intended for other types of screen. As a type of device-driver, these screen-drivers had to act as a ‘go-between’ linking the screen hardware, through the MS-DOS operating system, to the programming language and then, via the program, to the user. These screen-drivers also differed from one version of MS-DOS to another. Writing a program in an MS-DOS programming language like QuickBasic required locating and loading the correct screen-driver for the type of screen that would be used when the program was run, and persuading it to operate as required. Differences in screen-drivers that the program had to take note of meant that it was almost impossible to write a program that would make different fonts, or a picture, look the same on each type of screen. The difficulty was further compounded by the fact that not all organisations using a particular program also used the latest version of MS-DOS. This meant that a programmer equipped with this version of the screen-driver still could not rely on the assistance of the display screen used by this organisation unless it happened to be of the same type. This problem with screen-drivers did not arise if all that a programmer needed to put onto the display screen was text in a normal font; this much was included in the operating system and was standard between screens. But when a program was also required to include graphics, or to display fonts of different types or sizes, the problem became significant and could not easily be resolved by simple programming. A commercial programmer thus had to take account not only of the program’s specifications, but also of the different display screens on which the program might run, and different MS-DOS versions of the screen-drivers required for use with these screens. The programmer needed to enrol these screen-drivers, and hence the associated display screens, as allies. Failure to do so meant that cooperation between the program and the display screen would not follow, and the program would not necessarily work as intended. One simple solution was for the programmer to specify in advance the screen type and resolution required for use by the program; to require use of a specific-screen driver as an ‘obligatory passage point’ (Callon 1986b). The user would then have to obtain a monitor with this type of screen before using this program. There was no great difficulty in ‘forcing’ the enrolment of specific monitor screens in this way, but it did not solve the general problem of persuading other screen-types and screen-drivers to voluntarily come along and be part of the solution as well. A solution of this type would have worked in a specific instance, but prevented the program being generally used on different computers. Defining the screen problem in this way; what Callon (1986b) calls ‘problematisation’ would then have required convincing the program’s users that, as their problem could be solved by purchasing the ‘right’ monitor, a general solution that would solve this problem for all screens was not relevant to them. This presented a problem in contrast to the more usually held view that ‘compatibility’ was a good thing and that ideally everything, including programs, should be interchangeable between microcomputers (Stephen 1997). Writing a program that will only work on a specific computer configuration would have severely limited its commercial usefulness and few programmers would have seen this as a satisfactory answer. For a program to be of much commercial use it needs to be able to


work with different screens and different versions of MS-DOS, taking us back to the need to enrol all the screen-drivers into a stable network that would cooperate in performing this task for monitors of each type. Unfortunately, enrolling the screen-drivers as allies in this way was not an easy task. Like Aramis’ non-material couplings (Latour 1996) and the TSR2’s turbine blades (Law and Callon 1988), neither of which could be persuaded by their builders to work as required, these actors were not yet ready to cooperate in the formation of a stable network. They each saw their purpose40 as providing a solution to the specific problem of mapping text and graphics onto the particular screen type they represented, not as working together to do this for all types of display screen. The single screen-type problematisation offered by the screen-drivers was soon to change as Microsoft Windows came onto the scene. Windows changed things by enrolling all the screen-drivers as part of the operating system itself, so ensuring that they would always be willing to cooperate in mapping text and graphics onto the screens that they represented and spoke for. Microsoft managed to convince screen, and other device-drivers, that their best interests would be served by allying themselves with Windows, rather than attempting to continue to stand alone with MS-DOS. It did this by convincing the screen-drivers of the market-potential of Microsoft Windows over MS-DOS, and that to stand alone and not join Windows in the future would mean a much reduced role for them41. The MS-DOS version of Visual Basic, that Fred was about to come across, was also able to achieve the same end and to ensure the cooperation of the screen-drivers in providing consistent output for each type of display screen. VB was able to enrol these actors and make them fall into line and do what they were told by the programmer. Fred and George needed to gain the cooperation of two different screen-drivers: EQA and Hercules Graphics as allies in completing their programming project but found this task very difficult to perform using QuickBasic. They were on the look-out for a better alternative which VB was about to present in redefining their problem for them.

Visual Basic 1.0 for Windows

On the 20th May 1991 Microsoft announced the release of Visual Basic 1.0 for use with Windows 3.0, which had become available just over a year earlier (May 1990), and after Bill Gates had spoken of the advantages of having a common macro language for all applications42 in his keynote address ‘Information at Your Finger Tips’ at Comdex (Gates 1991). The press release described Visual Basic (VB) as “a graphical application development system for Windows 3.0 that combines visual design tools with a powerful, general-purpose programming language and Windows .EXE compiler.” (Microsoft 1991a) Although its language component was based on Microsoft QuickBasic, Visual Basic was an entirely different type of programming language to others available at that time (Microsoft 1991a).

Fred’s Discovery of Visual Basic for MS-DOS When Fred and George found they were making little progress solving the graphics screen-driver problems George, who was completing first year Computer Science at Melbourne

40 The expression here is an example of how ANT grants agency to non-human actors, as discussed in Chapter

5. 41 By 1999 the proliferation of screen types has reduced considerably, but this has not been the case with

printers and other peripherals. The issue of device-drivers for these is still important. 42 This came to pass in the form of Visual Basic for Applications (VBA) with the release of Office 95. Visual

Basic has many uses and this, of course, is just one of them.


University at the time, remembered seeing a recent review in a computer magazine of a new Microsoft product called Visual Basic for MS-DOS. George knew of the existence of Microsoft Visual Basic for Windows, which had been released the year before, but had not used it as neither he nor Fred had seen much point in using Microsoft Windows before that time.

Visual Basic 1.0 for MS-DOS

VB for MS-DOS became available in October 1992. It contained many of the same features as Visual Basic for Windows except that it operated in an MS-DOS non-graphical environment. It made use of a mouse and used a toolbox of controls like that offered in Visual Basic for Windows. The program code was the same, meaning that a program developed in VB for Windows could be easily converted for use in MS-DOS, and vice-versa. The MS-DOS version of Visual Basic was released in both a standard version, and an enhanced professional edition with extra custom controls (Microsoft 1991b).

Microsoft QuickBasic (which by then had reached version 4.5) was discontinued in April 1993 after being completely superseded by Visual Basic for MS-DOS (Communique 1993).

Before finding out about Visual Basic for MS-DOS, Fred had become a competent QuickBasic programmer and he and QuickBasic had been involved in a quite stable MS-DOS, character-based programming43 association. For a number of years Fred had written computer programs in a variety of character-based programming languages, but principally in one version or another of Basic. For the last five or more years Microsoft QuickBasic had been his programming language of choice (Fred 1998). Fred remarked:

“I had a long history in teaching Basic and we had the messing around with QuickBasic - the Microsoft product, to do that commercial programming, whatever it was.” (Fred 1997b)

For Fred, until this time programming had meant writing code in order to put text onto the computer screen for a user to look at and interact with. Writing a computer program meant designing the solution algorithm and then typing the code into an editor, compiling the program, and running it. It had almost nothing to do with graphics and was little concerned with screen design. The approach proposed by Visual Basic of using graphical objects containing their own in-built code to design a functional screen, and then basing the program logic around this, was totally new to Fred and was at odds with his former character-based programming approach. George was also a competent programmer in QuickBasic, but his studies in Computer Science had recently forced him to look at other programming languages including LISP and Pascal44 and so his personal views on programming were not quite as well formed and stable as those of his father. George was still trying to determine what programming meant to him and so was on the look out for new developments and different ways of doing things (George 1999).

43 Character-based, or text-based programming was the common type of programming before languages like

Visual Basic came onto the scene. It involved typing all program code into an editor then compiling (or interpreting) and running the program. In a character-based program is was possible to represent the entire program and all its actions by a printed listing of its program code.

44 For an easy-to-follow description of many of the different programming language used until the mid 1980s, see Baron (1986).


In particular, George remembered that Visual Basic for MS-DOS was supposed to have a single set of graphics-drivers that worked as ‘calling routines’ that acted through the operating system rather than going directly to the screen devices themselves. As ‘calls’ to the MS-DOS operating system these graphics-drivers would then be able to work with any type of display screen and it would no longer be necessary to have a different set for each type of screen. Visual Basic for MS-DOS had enrolled these screen-drivers by incorporating them as a part of its own actor-network, and when you installed Visual Basic for MS-DOS on your hard disk you also automatically installed all the device-drivers ready for use with a variety of different display screens. VB for MS-DOS had overcome the reticence of the device-drivers to cooperate with each other and had succeeded in incorporating them into its own network. It had convinced them of the advantages of working with it, and so enrolled them into a new network - Visual Basic for MS-DOS - that contained both a programming language and other programming elements including device-drivers that would constitute a complete integrated development environment (IDE45). It would now no longer be necessary for programmers to make all these associations and connections themselves. In its problematisation of programming, VB for MS-DOS had enlisted allies to persuade programmers of its use.

Figure 6.1 Visual Basic for MS-DOS; design screen for Wotan’s Cake Price Calculator

This was enough inducement to George and Fred to give Visual Basic a try. VB’s re-definition of programming in which a programming language was granted the ability to call graphics-drivers through the MS-DOS operating system interested (Latour 1986) both George and Fred. VB’s problematisation of graphics programming appeared to them to fit well with their commercial programming problem in the way that they saw it. The solution suggested by VB for MS-DOS offered considerable inducement or, as Callon (1986b) would say produced an interessement for Fred and George to move away from QuickBasic

45 - consisting of an editor, interpreter and debugger.


and to adopt Visual Basic in its place. After purchasing Visual Basic for MS-DOS and trying it out it was not long before Fred and George found that it did indeed provide a good solution to their graphics problem. Visual Basic for MS-DOS had successfully enlisted the assistance of the screen-drivers as allies in its bid to make the various display screens follow the wishes of the programmers in displaying graphics. Fred and George decided to drop QuickBasic and, in its place adopt Visual Basic for MS-DOS in their commercial programming project. Visual Basic had successfully enrolled them to its view of “visual programming” (Fred 1998). A consequence, unexpected to Fred who had always been reluctant to use Microsoft Windows which he saw as unnecessarily complex, was that he soon began to like the visual aspects of VB and the different type of programming style it represented (Fred 1997b). While George’s main interest in Visual Basic had been in solving the specific graphics display problem, Fred began to see another side to it, leading to the formation of a ‘Fred + VB for MS-DOS’ hybrid (Latour 1993)

“It was the different type of programming style that got me interested. The fact that you could easily put things together. ... But VB for MS-DOS also had drag and drop controls in it so there was that aspect as well - it was a different type of programming environment as well as the fact that it had the screen-drivers that worked. ” (Fred 1998)

Fred liked the fact that VB allowed the programmer to easily put a program together in a short time and a program, what is more, that looked really good on the screen.

“Now as soon as you start using the thing, painting screens and whatever, all of those input and print statements that take so much effort to get looking nice in other languages, of course are done automatically in VB.” (Fred 1997b)

“Microsoft Visual Basic Programming System for Windows is a powerful, easy-to-use development system. Visual design tools, an event-driven programming language, and debugging tools allow you to create applications that take full advantage of the Windows graphical environment. Visual Basic combines a powerful programming language with visual design tools for creating graphical programs. Ease of use and high productivity make the Microsoft Visual Basic system the easiest way to create and integrate applications for MS Windows.” (Microsoft 1991b)

VB problematised (Callon 1986b) programming tasks quite differently to other languages Fred had been used to, by using drag and drop controls46 and event-driven code47 in place of a character-based environment and the use of procedural code48. As few other programming languages at the time used anything like this approach Visual Basic could then make no claim to being similar to language used extensively in business programming49, and Fred found that its initial attraction was more on a personal level50. Although he had always

46 Constructing a Visual Basic program begins with building a user-interface screen by dragging objects, such

as text-boxes and command buttons, to appropriate places on the screen. Programming in Visual Basic is discussed more fully in Chapter 8.

47 Code that is executed when the user performs an ‘event’ such as clicking on a button, typing in some text, or moving the mouse (- see Chapter 8).

48 In contrast to the user-driven approach of an event-driven language like Visual Basic, program execution in a procedural language proceeds sequentially through the code in a manner that is predetermined by the programmer.

49 That is to being considered ‘real’ (see Chapter 10) 50 Fred was, of course, not alone in seeing potential in the use of visual environments and graphic user

interfaces for the PC; interfaces like those used by the Apple Macintosh. Research by the US-based research company Temple, Barker & Sloan Inc. in the late 1980s (Communique 1990) showed that, compared with


enjoyed the challenge represented by programming, he found that using VB was “more fun” than normal programming. The fact that it was not yet seen as being a ‘real’ language was not an issue to Fred at this stage although it would become quite important when he later introduced VB at RMIT. Fred as a Teacher, Programmer and Heterogeneous Engineer From discussion with other RMIT academic staff it became apparent quite early in the investigation that Fred had, intentionally or otherwise, engineered the entry of Visual Basic first into the curriculum at PIT and then later at RMIT (John 1997; Paul 1997b). It was also clear that looking only at ‘Fred; the actor’, concealed important attributes of ‘Fred; the network’. This section examines the alliances and associations that Fred was able to draw on; it examines ‘Fred the network’ to see what other actors he brought along with him to help him engineer the entry of Visual Basic into PIT’s curriculum. Before becoming an Information Systems academic, Fred spent over fifteen years as a secondary school mathematics and science teacher but, after encountering programming in his science degree at Monash, had always maintained an interest in computing. While teaching at Bendigo High in the early 1970s he commenced, but never completed, a graduate diploma in computing at Bendigo College of Advanced Education (Fred 1997b). From 1974 to 1978, Fred and I taught together at Watsonia High School where we used the DEC-10 computer at nearby La Trobe University to run a punch-card-driven student-preference allocation program, and a DEC-Deamon minicomputer to introduce year-11 mathematics students to programming concepts using DEC-Basic. In 1978 Fred, who was then a member of the Ministry of Education’s Secondary Mathematics Committee, obtained an ‘Innovations Grant’ for the school to purchase one of the new Apple II microcomputers. Fred and I then devised a &RPSXWHU $ZDUHQHVV subject for our year-10 students. The subject was team-taught, and involved business uses of computers, social issues concerned with the use of computers in commerce and industry, and a good deal of programming in Applesoft Basic, the programming language supplied with the computer. At the time, of course, computer professionals regarded the Apple II as a ‘toy’ (Woodhouse 1992), and Applesoft Basic was not much used in the computer industry and was certainly not considered to be a programming language many professional programmers would use. The time of the ascendancy of the microcomputer in business had not yet come and until it did the credibility of this machine for business programming was low. Although this commercial credibility later became an issue in introducing microcomputers and microcomputer programming languages into the Colleges of Advanced Education (Tatnall 1993), it was not an issue in the school context; no one really believed that our purpose there was to turn out business programmers. After transferring to Whittlesea Technical High School in the late 1970s, Fred continued to make use of Applesoft Basic and, a little later, Microsoft QuickBasic for MS-DOS (Fred 1998). He used these languages both in his teaching, and in some contract programming work done outside the school context. Fred worked hard at Whittlesea to find a place for computing in the school curriculum. He worked to gain allies, including Paul whom we will encounter later in the story, to help him with this task.

character-based systems, people working on computers with a graphic user interface (GUI) could work faster and better, with greater productivity and a lower level of frustration and that they experienced lower fatigue, were better able to explore and were able to learn more of the systems’ capabilities. The GUI was certainly a step towards more ‘people-oriented computers’ (Lindgaard 1994).


During the 1980s, Fred’s younger brother Mike commenced work as a professional programmer using mainly Pick systems and the Pick/BASIC programming language51. Fred’s oldest son George, who was at high school at that time, was also very interested in programming. As a consequence of all this, by the time Fred took up a position at Phillip Institute of Technology in 1989 he was certainly no stranger to programming, or to the programming language Basic. To fully open Fred’s black-box and examine Fred as a network, at the start of this story you would find: a set of interactions associated with teaching mathematics, business uses of computers, computer programming, the Basic programming language, and QuickBasic in particular. It also included a link to Pick programming through his brother Mike which would come to be quite important later during PIT’s merger with RMIT.

Phillip Institute of Technology Before following the translation of Visual Basic any further I will first examine the curriculum at Phillip Institute that it was about to enter. In the late 1960s, in line with the recommendations of the Martin Report52 to establish a series of Colleges of Advanced Education (CAEs) in Australia (Rasmussen 1989), the tertiary departments of Preston Technical College joined the newly formed Victorian Institute of Colleges to become Preston Institute of Technology. The new Institute began setting up a campus in Bundoora, with the non-tertiary remnants of the Technical College remaining on the old Preston campus53. From the beginning, Preston Institute of Technology saw its prime role as serving the tertiary training needs of industry and commerce in the northern suburbs of Melbourne (Phillip Institute of Technology 1990). Like most other former technical colleges, Preston Institute formed a view of the sort of tertiary education it could, and should provide, on the basis of the mission in ‘applied higher education’ set out for the new CAEs by the Martin Report and endorsed by the Commonwealth Government. With this definition of its mission in hand, Preston Institute’s courses were initially focused around the applied disciplines of engineering, applied science and business. Teaching in computing at Preston Institute began in the Applied Science Department and was taken up by the Business Studies Department only in the late 1970s (Tatnall 1993). In the early 1980s another Government review of tertiary education resulted in Preston Institute of Technology merging with the State College of Victoria (SCV) at Coburg54 to become Phillip Institute of Technology (Maynard 1990). The new Institute then had campuses at Bundoora and Coburg and over the next few years the School of Business moved into newly built premises at the Coburg campus alongside the School of Education. This merger caused no radical change in the way the institution saw its mission. As both the former institutions had an applied focus, this focus continued into the new institution. Phillip Institute of Technology defined the problem of providing appropriate higher education in the northern suburbs of Melbourne in much the same way as had Preston Institute, and this was to serve the tertiary training needs of industry and commerce in this region. In its Information Systems curriculum, Phillip Institute was very much a typical CAE. While university computing courses at that time were usually in Computer Science, and

51 See Chapter 7. 52 See Appendix A. 53 This later became Preston TAFE, and is now known as Northern Melbourne Institute of TAFE. 54 Formerly known as Coburg Teachers College.


tended to be more theoretical with the only application areas considered often being things like real-time monitors, operating systems and compilers (Juliff 1990), CAE courses tended to be very much more practical (Maynard 1990). In line with how the Institute had defined what it meant by higher education, the Information Systems curriculum at PIT was also much more closely related to the needs of industry and commerce than most university courses. Juliff (1992) suggests that while the designers of university courses never saw the need to be relevant to the business world, those in the CAEs considered this to be extremely important. Curriculum in Information Systems at PIT was, therefore, directed primarily towards the business applications of computing. The merger with SCV Coburg resulted in the addition of a School of Education and several smaller units concerned with social work, but had little effect on the role or operations of the School of Business or other parts of the Institute. Over the years that it had been operating Preston Institute had formed a view of its purpose and place in education. As a teaching unit within Phillip Institute of Technology, the Department of Accounting and Electronic Data Processing (EDP), which Fred joined in 1989 accepted and represented the educational point of view of the Institute (John 1997; Tatnall 1993). The department sought to ensure that its Information Systems curriculum related well to what it perceived as the needs of the business community it represented in the northern suburbs of Melbourne; it represented and spoke for the Institute on this matter (John 1997). As a way of ensuring that the Institute was successfully fulfilling its mission, each department at PIT was required to set up a Course Advisory Committee with representation from industry and commerce (John 1997). These committees could potentially play a significant role in determining the curriculum, but this depended on the actions of the particular committee and department concerned and some were more effective in articulating their views on curriculum than others (John 1997). The Department of Accounting and Business Computing55 was, as its name suggests, a composite department with the majority of its work being in accounting and only seven out of twenty-five academic staff teaching Information Systems. To all practical purposes, in its curriculum development activities the department acted as two separate entities: an accounting curriculum entity and an Information Systems curriculum entity. These separate entities then represented and spoke for the Department in the development and implementation of their respective curricula, each having little to do with the other. The one point of intersection between these two entities was the Head of Department, otherwise they operated in curriculum development almost as two separate departments. In Information Systems curriculum development the group of seven IS academics, along with the Head of Department can be seen as representing the department and able to speak for the department. As there was only a single Course Advisory Committee to serve the disparate needs of the whole department, the majority of the committee’s members were accountants. Furthermore, of the small number of committee members who did have an interest in computing, two were academics from other tertiary institutions and only two had computer industry affiliations. As a consequence, useful industry input on Information Systems curriculum from this committee was quite limited (Jean 1998). Unlike the department, however, the committee only ever acted as a single entity and did not break into separate groups to discuss curriculum matters. The accountants, probably a little cautions about their level of understanding of Information Technology, rarely made suggestions regarding Information Systems, and the only regular input came from the other IS academics (Jean

55 As the Department of Accounting and EDP had now become.


1998). The influence of this committee on the Information Systems curriculum at PIT was thus quite small. Information Systems at Phillip Institute of Technology The recommended formal process of course design at PIT involved the Course Advisory Committee and members of the academic department that was proposing the course (Fred 1997a). In the early 1990s, the Bachelor of Business in Business Computing at Phillip Institute of Technology was an applied course oriented largely towards turning out business programmers and so many of its subjects had a programming flavour. In 1992 it required students to undertake twenty-four subjects, including eleven core business subjects consisting of two accounting subjects, two economics subjects, two business law subjects, two management subjects, two quantitative methods subjects, and the core computing subject ,QWURGXFWLRQ WR 'DWD 3URFHVVLQJ. In addition, the computing specialisation contained nine subjects, five of which were devoted to programming (Phillip Institute of Technology 1992).

3URJUDPPLQJ 3ULQFLSOHV (- taught using Pascal56) %XVLQHVV ,QIRUPDWLRQ 6\VWHPV�$%XVLQHVV ,QIRUPDWLRQ 6\VWHPV�%%XVLQHVV ,QIRUPDWLRQ 6\VWHPV�&'DWD 6WUXFWXUHV DQG $OJRULWKPV (- taught using Pascal)&RPPHUFLDO 3URJUDPPLQJ�$ (- using Cobol) &RPPHUFLDO 3URJUDPPLQJ�% (- using Cobol)&RPPHUFLDO 3URJUDPPLQJ�& (- using Cobol)&RPSXWHU +DUGZDUH DQG 6\VWHPV 6RIWZDUH LQ ,QIRUPDWLRQ 6\VWHPV

Students then had to choose four electives, and could choose them from those offered by any Faculty in the Institute. Of the seven available Information Systems electives, three were directly related to programming:

$VVHPEO\ /DQJXDJH 3URJUDPPLQJ (- language unspecified) )RUWUDQ 3URJUDPPLQJ (– Fortran 77)2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ (– C, Unix)&RPSXWHU *UDSKLFV&RPSXWLQJ 3URMHFW1HWZRUNV LQ ,QIRUPDWLRQ 6\VWHPV([SHUW 6\VWHPV DQG %XVLQHVV 0RGHOOLQJ

$VVHPEO\ /DQJXDJH 3URJUDPPLQJ, 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ and &RPSXWHU *UDSKLFV were new electives that were introduced in 1990/91. ,QWURGXFWLRQ WR 'DWD 3URFHVVLQJ which, as a core subject was compulsory for all business students, included a section introducing students to programming. This subject was originally taught using a version of Basic but in the late 1980s was changed to use the dBase III+ programming language in an attempt to increase the subject’s relevance to business students, as dBase was very popular in commerce and industry at that time (Fred 1998). Despite the relative ineffectiveness of the Course Advisory Committee (John 1997), academics in the Department were attuned to the Institute’s view of education and so considered the relevance of their curriculum to the needs of industry as being very important . John, who was at that time a Principal Lecturer,

56 Where shown in bold, programming language names are specifically mentioned in the Faculty handbook

meaning that this language must be used. It could only be changed after a formal alteration was made to the handbook.


indicated that the department took this into consideration when choosing programming languages. Apart from Pascal, which was justified for a few years in a couple of subjects on the grounds of being a good language to introduce programming concepts to computing students, all programming was taught in ‘real’ programming languages; those commonly used in business (John 1997). Business Programming at Phillip Institute At PIT Fred found he was teaching in a course involving a good deal of programming. When he started at Phillip Institute there were very few Information Systems electives; not enough, Fred judged, to meet student demand as many Business students were having to resort to taking Computer Science electives.

“The difficulty was that we had a very small intake and hence we didn’t have a very large teaching staff and hence everybody was doing everything. The degree had four electives in it but we didn’t have four elective subjects for students to choose from. So they were going out to Computer Science and coming back very dissatisfied; the quality of students in Computer Science at that stage was very much lower than the quality of the business students. The kids wanted to do things like assembly language, and had to go over to Computer Science to do it. But they came back having added two numbers together after a semester, whereas when we later got our elective in place, my class were able to check the words in a sentence against a dictionary as their first project, and their second project was writing a TV game.” (Fred 1997b)

Fred had now been at Phillip Institute long enough to have an idea how curriculum development operated there. He had also worked himself into a position to have some influence on the curriculum having volunteered for, and being given, administrative responsibility within the Department for coordinating the development of new computing subjects and putting together new courses in Information Systems. Fred remarked that:

“The reason that happened was that out of the seven people in the department – that was the entire teaching team, including John – no one really had the energy to do new subjects, but I did.” (Fred 1997b)

With his new responsibilities, over the next year or so Fred thought about the experience of his students not being able to get what they wanted from Computer Science, and proposed three new electives: $VVHPEO\ /DQJXDJH 3URJUDPPLQJ, &RPSXWHU *UDSKLFV, and 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ. Fred now believed that he understood the needs of his students, and the requirements of the tertiary institution, well enough to represent the views of each and so to be able to design suitable electives. Further explaining the need for new electives Fred said:

“I was always on the lookout for subjects students would be interested in, and that would also be of value to their careers. So assembler was the first I think, then graphics programming and then the operating systems programming subject to given them Unix and C. The staff was fairly volatile and in a two or three year period we would have employed three or four new teaching staff. I went for my first six years at PIT without doing the same subject for two semesters in a row. It was an interesting time!” (Fred 1997b)

Fred suggested that the rapid turnover of staff and the subsequent changes in teaching duties of many academics, along with a lack of development time, made it easier for him to make the changes he saw to be necessary. The three new subjects Fred introduced were additions to the curriculum and so did not have to make any assault on, or even enter into any negotiations with, existing Business subjects, making their entry into the curriculum much more straightforward than would otherwise have been the case. The new subjects did,


however, act as an interessement (Callon 1986b) to weakening the association of Fred’s students with Computer Science and entice them back to Information Systems. The programming languages in this course were taught in two main streams with 3URJUDPPLQJ3ULQFLSOHV and 'DWD 6WUXFWXUHV DQG $OJRULWKPV being taught using Pascal, and &RPPHUFLDO 3URJUDPPLQJ�$, &RPPHUFLDO 3URJUDPPLQJ�% and &RPPHUFLDO 3URJUDPPLQJ�& taught using Cobol. There was also the Faculty core computing subject, ,QWURGXFWLRQ WR 'DWD 3URFHVVLQJ� that amongst other things covered a little bit of programming in dBase which Paul (1997b) said was to demonstrate database concepts to the students and also to give students an idea of what programming might involve. Paul indicated that the intention was to do this fairly painlessly using a “4GL-type approach”57 using very little code, and so get a lot done rapidly. In addition, %XVLQHVV ,QIRUPDWLRQ6\VWHPV�$, % and & made some use of dBase IV as a prototyping tool for use in systems design. Therefore in 1992 an Information Systems student at PIT would have started with dBase IV, before moving on to Pascal and Cobol. The first programming elective was 2SHUDWLQJ6\VWHPV 3URJUDPPLQJ which was then taught using C and Unix. The $VVHPEO\ /DQJXDJH 3URJUDPPLQJ elective was taught in VAX assembler. All this was before Fred discovered Visual Basic, but the alliances and associations he had made put him in an excellent position to later work towards incorporating VB in the curriculum.

Exploration: Teaching Experiments with Visual Basic In what can be described as the second key moment of this story, Fred then set out alone (Toombs and Tierney 1991) to try to interest others in using Visual Basic, beginning with his students. He approached this task cautiously as although he himself had been enthused by VB and saw great advantages in its use he still had to convince himself that VB was teachable, and was right for his students. At the time that his discovery of Visual Basic for MS-DOS was going on, Fred’s teaching at PIT involved programming in Cobol on the VAX, and Pascal in MS-DOS on the laboratory PCs. He remarked that in writing a program in each of these languages, everything you wanted to add to a form to display to the user had to be instigated by a separate line of program code.

“There was an alternative in VAX Cobol which allowed you to do screen painting. I was teaching this in Cobol at the same time Visual Basic came around. The VAX screen painter was a horrible grunky thing, but it did produce the screens. They would have a parameter name - you know something like $PX2#35, and that would be the thing the programmer had to type in to get the screen displayed. Comparing that to VB was just chalk and cheese.” (Fred 1998)

In late 1992 Fred discovered Visual Basic in a commercial programming job in the first key moment of VB’s entry into the curriculum. After a short engagement in which he investigated Visual Basic to see what it could do Fred became convinced of its benefits. He was persuaded by VB’s redefinition of programming that provided a solution to his graphics problem, and in which the programmer positions objects on the screen in order to create a user-interface and the basis of a program. Fred saw VB’s sort of programming as “refreshingly different” (Fred 1998) to the character-based style of programming he was use to using, and was enrolled.

57 Fourth Generation Languages (4GL) are generally used alongside database management systems and are

intended to be comparatively easy to use by specifying what is required rather than how it should be done.


Fred’s programming network, which had previously been based mainly on the use of QuickBasic, Pascal and Cobol, was de-stabilised by the emergence of Visual Basic. The problematisation proposed by Visual Basic soon resulted in the displacement of QuickBasic as Fred’s preferred programming language, with VB moving into this position itself. Visual Basic had shown and convinced Fred that visual, event-driven programming languages of this type were worth exploring further. It was then not long before VB began a process of interessement that would soon marginalise and lessen the place of the other languages. Fred readily admits that he was soon “completely hooked” (Fred 1998) on Visual Basic and the whole idea of the visual environment it represented. VB’s interessement had been successful. In Fred’s view VB had showed that it was capable of doing a better job of screen design than QuickBasic, Pascal or Cobol, and also that it could do this more easily and was more fun to use than the other languages. Fred was now enrolled by Visual Basic and his associations with the other languages considerably reduced.

“The idea of dragging stuff onto a screen and dropping it where you wanted, and then it creating the code for you was pretty mind-boggling.” (Fred 1998)

By offering a new and, what seemed to him, better solution to his technical problem with graphics screens VB had enrolled Fred to its view of programming and he now had to work out what this meant to his teaching. Choice of VB as a solution to the technical problem had now created an education dilemma for Fred: should he try to introduce Visual Basic into his course, and if so, how? Fred was particularly impressed with VB’s consistent visual environment and the speed with which VB applications could be developed. He was so impressed with the possibilities he saw in Visual Basic that he decided to introduce it to his students. He was, however, not sufficiently sure of how the students would take to it to propose the creation of a new subject to teach Visual Basic. He was also not sure whether he could develop enough materials for its use and so decided instead to try it out first in existing subjects (Fred 1998). For Fred, the introduction of Visual Basic into his teaching at Phillip Institute became a matter of exploration and experimentation. He said that, probably in common with many other teachers, he usually tried new ideas out in whatever seemed the easiest subject to do this at the time. Always looking out for new teaching ideas, before coming across VB in the consulting job Fred tried using some C and UNIX in one of the commercial programming subjects prior to accreditation of the 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ elective, and using Assembly Language in the 'DWD 6WUXFWXUHV DQG $OJRULWKPV subject.

“I tried out everything before I taught it; I added it as a small package in a core subject. We tried things out in one or two week bursts in something else before adopting them.” (Fred 1997b)

I will now make a small digression into the changes in these subjects in order to set the scene for the introduction of VB. In &RPPHUFLDO 3URJUDPPLQJ�& the programming language used had been Cobol, but Fred redefined the subject to include C and Unix. In years past, commercial programming was equated, by most computer professionals, with programming in Cobol (Juliff 1992), and most university subjects with a title like this would have involved Cobol. As C and Unix were also both commercially important, only a small change to the subject description was necessary to include them in addition to Cobol. C and Unix were also used extensively in industry and so seen as quite ‘real’, making the Courses Advisory Committee and the Institute happy to have them included in a subject like this (Donald 1998). Introducing assembly language into 'DWD 6WUXFWXUHV DQG $OJRULWKPV, in addition to Pascal, represented a somewhat larger change, but one that Fred found no difficulty in justifying to


himself and his colleagues (Fred 1997b). In the 1960s Pascal had been created primarily as a language for teaching and the communication of algorithms (Woodhouse 1992) and had come, by the 1980s, to be accepted as a good vehicle for introducing algorithmic and data structure concepts. Pascal, however, was not much used in commercial programming (Juliff 1992). Like any language, assembly language made use of data structures, and it used algorithms in much the same way as did Pascal. Fred asked ‘why should it not be used here?’ Fred described how he tried out Visual Basic in first semester 1993 as a screen prototyping tool in %XVLQHVV ,QIRUPDWLRQ 6\VWHPV�$. He did this not by just accepting Visual Basic as Microsoft had designed it, but by translating (Callon 1986b) it from a ‘programming language and visual programming environment’ into a ‘screen prototyping tool’. He assigned Visual Basic a new role in the demonstration of screen prototyping, and VB accepted this new role. Reassignment of Visual Basic’s role was a good deal easier than it sounds and just meant completing only the first step of program development in VB by using its visual interface to create the screen that would be seen by the user at runtime, but not proceeding to the stage of adding program code. This translation meant leaving out most of VB’s object and event-driven programming features and introducing just its visual interface. It was a translation that reduced the scope of Visual Basic to something that was appropriate to this subject, making it possible to use VB in this role. Without the translation to reduce VB’s scope to just screen design Fred judged that it would have been too difficult to use VB in this subject. The prototyping topic had always been hard to teach as, without suitable prototyping tools to use in the student labs it could not be handled practically. Paul, who also taught this subject, noted that it was not feasible to teach using tools like the VAX screen painter in this introductory subject and, in any case, these tools made up an important part of a later subject (John 1997). The reasons suggested by Paul that a CASE tool58, or some other prototyping product, had not been used were twofold. Firstly, such tools were quite expensive, and secondly, the time required to teach students to use them would have been beyond the scope of one topic in an introductory subject like this. Fred indicated he thought at the time that any easy way to convert this subject from pure theory into something more practical had to be an improvement. The slight change in the problem definition that allowed this was seen as highly desirable both by the lecturer and the students (Fred 1997b). The subject wasn’t working properly the way it was then being offered, and Fred judged this was because it was too theoretical. He said that where other alternatives did not seem satisfactory, Visual Basic did. VB offered a practical, concrete approach to prototyping screen design. The translation of VB to hide its programming features and leave just its visual design interface enabled it to be of use in this subject. So, where CASE tools and the VAX screen painter had been unable to offer a redefinition of %XVLQHVV ,QIRUPDWLRQ 6\VWHPV�$ that would allow their enrolment, Visual Basic was well on the way to doing so. One difficulty though was that Fred was then far from expert in using or teaching VB. In discussing curriculum change involved in the adoption of a Problem Based Learning (PBL)

58 CASE: Computer Assisted Software Engineering. The idea of CASE was to ‘use software to write

software’. The problem to be solved only had to be expressed in ‘simple English-like terms’, then the CASE tool would do the rest. CASE tools were very popular in the mid 1980s but are no longer ‘flavour of the month’ in computing. Phillipson (1998) notes that the growth of database managers like Access, tools like Visual Basic and technologies like client-server have made it easier for end-users to write their own applications that give them the ability to use corporate data. He suggests that the application backlog that CASE tools were designed to solve has subsequently largely gone away and, along with it, the need for CASE tools.


approach in US medical schools, Busch (1997) remarks on Latour’s (1987) contention that construction of new scientific knowledge is simultaneous with the construction of the network itself. She suggests that the staff in these schools learned about PBL at the same time they discussed it with each other in the process of setting up networks and enrolling new members. In this case, following the old adage that ‘the best way to learn something is to teach it’, Fred’s own learning about the capabilities and limitations of Visual Basic, and how it could be used in business programming, proceeded in parallel with his experiments in teaching with it. Although he no longer remembers all the details, Fred said that he does remember solving his own problems in dealing with the new design and programming paradigms required by Visual Basic by working through them with his students. The hybrid (Latour 1993) had now enlarged to become ‘Fred + VB for MS-DOS + students’. Because the student laboratory computers at Phillip Institute were MS-DOS-based at that time, Fred initially used the MS-DOS version of Visual Basic in his teaching (Paul 1997b). Enrolling the MS-DOS labs was much easier than trying to fight the battle of getting Windows installed just for use with Visual Basic. Fred judged that it was better to make allies of the labs in their present form than to try to force them to take a path they were not then ready to take (Fred 1997b). While VB for MS-DOS was constrained by having to work within MS-DOS and not being able to have access to all the features of Windows, it also had an effect on MS-DOS by offering it some of the features previously confined to users of Microsoft Windows. MS-DOS thus restricted the role that VB for MS-DOS was able to take, and VB for MS-DOS in turn offered a new Windows-like role to MS-DOS. At this stage, Fred did not make any use of Visual Basic’s programming features, just its visual interface, as he was convinced that VB’s visual interface made it easy to persuade his colleagues of the use of Visual Basic for prototyping. The point of developing a prototype information system is to build something quickly that looks like the final product and can be shown to an end-user for comment and approval. A prototype can be developed quickly because it does not, at this stage of its development, need to include all the functionality of the final product. VB’s visual design features, and its ease of use at this level for a beginner, made it very suitable for this purpose. Fred and Paul both indicated that they and their students much preferred the practical approach now offered by VB to the previous theoretical one and became convinced of VB’s value as a prototyping tool. They saw the role they had assigned to VB as being successful in this subject. The students had now become firm allies of ‘Visual Basic, the prototyping environment’ having been shown by VB how much easier it was to perform prototyping tasks practically rather than just to talk about them (Fred 1997b). Before being adopted in this subject, however, Visual Basic ‘the programming language’, had undergone a translation to become Visual Basic ‘the interface design and prototyping tool’; with the hybrid of Fred and the students attached. Without this translation Fred judged that Visual Basic could not have been adopted in this subject as many of its attributes were not at all relevant for use here and could, he thought, get in the way. It would not have been possible to teach all about VB here as the amount of available time was limited. What Fred and Paul saw as required was a simplified ‘cut-down’ version of Visual Basic that removed all of its programming and object-based features and left only its abilities in user-interface design. This translation allowed VB to enter the curriculum. Fred described himself in teaching as a ‘concept deliverer’, concerned to teach underlying ideas rather than just which ‘button to press’ to make something work (Fred 1998). He said that he regarded one of the important aspects of the teaching of systems development to be that students were able to visualise what a system will look like when it is finished. He


remarked that this was difficult for students when they were working in a command-line environment and had to consider, in detail, individual Cobol display verbs or Pascal WriteLn statements. Using Visual Basic in this subject enabled the students to be freed from having to cope with this level of detail and allowed them to concentrate on rapid prototyping which was, after all, what the subject was supposed to be about. In the following semester Phillip Institute installed the Windows environment in the student laboratories. John suggested that this had been necessary “in order to keep up with industry trends” (John 1997). This change allowed a move to the Windows version of Visual Basic in early 1994. It is not clear that Fred’s use of Visual Basic had a significant influence on PIT’s decision to adopt Windows in the student labs; the push to introduce Windows in the labs came from many directions (John 1997). In first semester 1994 Fred tried out the Windows version of Visual Basic in 2SHUDWLQJ 6\VWHPV3URJUDPPLQJ. Previously this subject had concentrated on programming within a Unix operating system environment, with students using Unix commands and writing Unix scripts to perform operating systems procedures. With the increasing importance of Microsoft Windows, Fred justified VB’s inclusion here to write operating system extensions to perform these for Windows instead of Unix.

“We created EXEs that could be run from icons - just as you run the File Manager from an icon, you’d write a VB program and create an icon for it to run. It was just to show how you could extend the operating system by writing programs.” (Fred 1998)

After using it for a while, the thing that excited Fred most about the students’ use of Visual Basic in this subject was VB’s low threshold for relative beginners; students with little or no experience of programming could soon learn to make enough use of VB to produce “a pretty impressive looking program” (Fred 1998). Fred had modified, by another small translation, the definition of 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ from a subject originally intended to examine the Unix operating system, to one that also looked at Microsoft Windows. In this, and the previous instance of prototyping with Visual Basic, we begin to see the emergence of two new ‘Fred + students + VB for MS-DOS’ hybrids (Latour 1993) that had been mobilised to speak for and advocate the use of appropriate aspects of Visual Basic to solve the problems of prototyping and operating systems programming. The operating systems programming translation allowed the entry of Visual Basic as an easy way to work with the Windows operating system. VB was adopted in this subject after it underwent another translation, this time to become Visual Basic, the ‘language for Windows operating systems programming’. As many of the students who took 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ also studied the $VVHPEOH /DQJXDJH elective, taken by Fred as well, these students had the experience of making extensions to an operating system in Assembler, C or Visual Basic, depending on the operating system involved. VB’s enrolment in %XVLQHVV ,QIRUPDWLRQ 6\VWHPV�$ and 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ had now made allies of these subjects as well as a substantial number of students and had further pushed the language towards a durable place in PIT’s curriculum. This, however, proved not to be enough and it became important for the VB hybrid to recruit more allies. Visual Basic and Other Alternate Visual Environments Fred claimed that the fact that the underlying language of VB was Basic was of little importance to him in making his adoption decisions. He noted that although VB was one of the first, there were other products that did the same sorts of things that VB did, but that did not have a version of Basic beneath them. Fred looked at several alternatives including


Oracle Forms, SQL Windows, Delphi, Visual Age and X-Windows, but judged that each of these products would be harder to teach than Visual Basic (Fred 1998).

“Things like the editor in VB were so much better and when we went on to Windows it was the whole ability of taking away the glunkiness of getting things going that was important in terms of teaching, and dropping the frustration level of students.” (Fred 1998)

VB’s enrolment of Fred, and his own subsequent assimilation of VB into his teaching had thus proved too hard to disassemble for any potential counter enrolment by these languages. None of them had succeeded in replacing, or even supplementing VB. Visual Basic now ‘spoke for programming’ in Fred’s (1997b) view, and he required all other contending products to measure up against it. Many were tested and all, in Fred’s view, were found wanting. Visual Basic had now succeeded in mobilising (Callon 1986b) Fred as its spokesman at PIT. Despite his continued search for alternatives to convince himself that he was doing the right thing in adopting Visual Basic, VB maintained its position and the hybrid based upon Fred and VB continued to grow. Fred indicated that being able to show students an application development environment which was largely hardware independent was important to him, and that some of VB’s properties made it useful for this purpose. Fred earlier stressed the difficulty of displaying even different fonts on the screen in an MS-DOS environment, and how VB had helped solve this problem. He said that he now also saw how useful Visual Basic could be with Microsoft Windows. He spoke of how the ease of using Visual Basic in screen design with students was important, as was its use in dialogue design.

“I think that dialogue design was an important feature too, that a person could click on something or move somewhere else and you could respond to what they were doing. If you think about how you might try to do that with Cobol; you have to have a Declaration Section, you have to have your PIC mask or whatever, and you can’t really respond all that well anyway. It was good to be able to do those things simply with the support of the language instead of going against it. That was a big feature.” (Fred 1997b)

With a good answer to all of this, Visual Basic contrived to establish itself more and more firmly into Fred’s programming network. VB’s continued efforts to show how much better it was than all the alternatives for screen and dialogue design further strengthened its place in Fred’s own programming language network, and in the curriculum at PIT, to the expense of the other programming languages that had been used before. VB had now convinced Fred of its advantages over the others for what he wanted to do. But it had done this by changing the things that Fred wanted to do; by re-defining programming to the things Visual Basic was good at doing. Fred saw the trend towards the use of Windows becoming strong in commerce, and watched as most educational institutions moved towards the adoption of a Windows platform. He noted, however, that as far as he knew at the time, few other Victorian universities were then using Visual Basic. He indicated that he was not influenced by what was being done at other educational institutions.

“It was a view, my personal view, of what the environment was capable of doing that I went on, and this would have been influenced by my early teaching experiments and also the consultancies that George and I were involved in.” (Fred 1998)

A lack of resources could have acted to slow VB’s growing insinuation into Fred’s network and PIT’s curriculum and so caused their destabilisation again when Fred found he needed extra information or assistance. Fred described most textbooks of the time, as “just re-


statements of the programming manual” (Fred 1997b) and so of little value. He noted that there was nothing particularly useful in magazines either, and that none of the few resources that were around had any significant influence on the direction he took. None of these resources would have made useful allies. The lack of useful resources could have discouraged Fred from proceeding with VB, but it did not do so partially because Fred’s confidence in being able to generate his own resources was great enough to maintain VB’s enrolment, but also because VB had made a big enough impression on him to resist any counter-enrolment like this. He had been convinced that VB was worth his perseverance, but perseverance was definitely what it took. Fred did, however, speak with his colleagues, particularly with Paul, with whom he shared an office, and with John. He said that when he was playing with the use of VB in the curriculum he had respect for John’s views and always spoke to him first. It was very important to Fred to convince Paul and John of the value of what he was doing with VB and to enlist them as allies. The sort of ‘negotiation space’ (Law and Callon 1988) that Fred had been granted in experimenting with Visual Basic in the curriculum at PIT is not unusual in higher education in Australia, but nevertheless it is very important to curriculum innovation of this kind. Paul suggested that had John insisted on constantly questioning what Fred was doing and why he was doing it, it is likely that the innovation would not have proceeded (Paul 1997b).

“Within a negotiation space it is possible to make mistakes in private; it is possible to experiment and, if all goes well, it is possible to create relatively durable socio-technical combinations.” (Law and Callon 1988 :296)

Fred also noted that he had to obtain John’s approval as HOD for expenditure on books and software anyway. Several staff and some sessionals had tutorials in the subjects where Fred had introduced VB and, initially, none had much knowledge of Visual Basic. It was necessary for Fred to teach them about using Visual Basic himself, and to enrol them as allies. This had the side effect of entrenching Fred as the prime spokesman for Visual Basic at PIT and of making his association with VB more durable. Paul was one of the tutors who worked on these subjects with Fred at PIT. Paul and Fred had previously taught at the same school and so were quite close, both as friends and in their educational philosophy (John 1997). They also shared an office at PIT and so Paul was quite open to accepting Fred as the spokesman for VB and was soon a firm and consistent ally (Paul 1997b). This was to be important later, during the merger with RMIT as Fred and Visual Basic needed all the allies they could find. Given that there were only seven Information Systems academic staff at PIT and, apart from Paul, none of Fred’s colleagues were directly involved in teaching with Visual Basic, Fred (1997b) did not see much point in trying to enrol any of them. Both Paul and John agreed that he did, however, go to some trouble to keep the other staff informed of what he was doing with Visual Basic to make sure that they did not feel threatened and so see a need to oppose its introduction. Fred had been keen to avoid the formation of any groups that might oppose what he was doing (John 1997; Paul 1997b). Consolidation of Visual Basic’s place in the Curriculum Fred said that after ‘playing around’ with Visual Basic as a prototyping tool in ,QIRUPDWLRQ6\VWHPV�$ in 1993, the next time around (in 1994) he formally implemented VB in this subject in the form of a student assignment. A question on the exam paper also referred to this aspect of the course. Rip (1986) uses the word ‘text’ in reference to permanent concrete expressions of concepts like this, and in this case the assignment and exam paper were the


first enduring evidence that Visual Basic had made its mark in the PIT curriculum. These texts also acted as ‘intermediaries’, which Callon defines as “anything that passes between actors which defines the relationship between them” (Callon 1991 :134), adding to the durability of the network and firming VB’s place in the curriculum. Fred (1997b) noted that if he had thought, at any stage, the experiment in using Visual Basic for prototyping to have been a failure, it would have been immediately pulled out of the subject. He indicated that he had previously tried using the dBase Application Generator and had taken this out very quickly when he saw how difficult it was for the students to use. He had also played with a number of other things, including the Gupta SQL Windows product, demonstrating this to students. None of these experiments, however, was sufficiently successful to result in the creation of competing networks, and none were implemented in terms of accessible tasks as Fred judged that they did not achieve the ends he was looking for (Fred 1998). None succeeded in replacing, or even seriously challenging Visual Basic; VB was too firmly ensconced and so easily resisted the challenge.

Visual Basic for Windows - third party products

A number of third party products were soon available for Visual Basic. In April 1992 a database Custom Control appeared, and in August a number of other Custom Controls. In May 1992 Microsoft released a Professional Toolkit for Visual Basic, a Visual Basic Custom Control Development Kit, and a Visual Basic Windows Help Compiler (Communique 1992).

In February 1992, Windows 3.1 became available.

Visual Basic 2.0

Version 2.0 of Visual Basic for Windows was released in December 1992, and had a number of small additions. It also corrected many of the problems associated with version 1.0. Like the MS-DOS version, it came in standard and professional editions.

Early in 1993 several third-party database Custom Controls and external database linking tools were released for Visual Basic 2.0 (Communique 1993).

In the early versions of Visual Basic access to foreign databases could only be achieved by purchasing third-party add-in data controls. When Visual Basic version 3.0 was released in mid-1993 the Professional version included a Data Control that made it possible to access data from any of the major database packages through use of this control’s object properties, without the need to write any program code at all. Fred indicated that when the Data Control became available this was the final thing needed to clinch its adoption as a prototyping tool in ,QIRUPDWLRQ 6\VWHPV�$. The addition of a Data Control was a significant evolution for Visual Basic that changed the possibilities of what you could do with VB. In addition to displaying attractive screens and creating better dialogues, it was now also quite easy to extract and manipulate data from almost any of the main database formats. This evolution enhanced VB’s ability to enrol new allies, prevent the desertion of existing allies, and make new converts. As well as these version changes and additions to VB, Fred’s translations of Visual Basic to suit his purposes in the curriculum were successful at Phillip Institute to the extent that Visual Basic was confirmed as a good prototyping tool in ,QIRUPDWLRQ 6\VWHPV�$, and a useful operating systems language in 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ. They also got Fred thinking of other places Visual Basic could be fitted into the curriculum.


Visual Basic 3.0

In July 1993, Standard and Professional editions of VB3 became available. Probably VB3’s most important new feature was the addition of a Data Control (used to manipulate existing databases), and the conversion of many standard controls to become data-aware. Other new features included OLE Automation, a Common Dialog Custom Control, Pop-up Menus, and a Setup Wizard. The Professional Edition also included external database support, Crystal Reports for Visual Basic, and additional data-aware Custom Controls. (Microsoft 1993), (Feldman, Jennings et al. 1993)

There were now, in effect, two VBs (- or two translations of Visual Basic) in the PIT curriculum, and VB’s place there continued to increase in size, importance and durability as many new actors were enrolled. By the end of 1994, Fred, Paul and many of the students had accepted VB, and Visual Basic had been formally adopted in aspects of both ,QIRUPDWLRQ6\VWHPV�$ and 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ. It had quite firmly established an enduring place for itself in the Information Systems curriculum at PIT. Unfortunately, PIT itself and its Information Systems curriculum did not endure much longer as Phillip Institute was about to be merged into RMIT.

A Pause in Curriculum Development Due to an Impending Merger The merger of Phillip Institute of Technology with RMIT was announced during 1992, with complete integration to be implemented over several years. This meant an end to any further formal curriculum development at Phillip Institute but did not prevent Fred from continuing with his experimentation with Visual Basic. Early in 1993, discussion commenced within the new Faculty of Business, and in particular within the new merged Department of Business Computing, on the curriculum development necessary to produce new common degree, graduate diploma and masters courses. Fred’s energies now went into development of these new courses, but he did not lose his interest in Visual Basic. The actor-network that Fred and Visual Basic had become a part of at PIT was sufficiently robust not to disintegrate, but began to undergo a transformation in order to establish a place for itself in the new enlarged RMIT. In the first key moment of this first part of the study of the adoption of Visual Basic in the Information Systems curriculum at RMIT I have traced how Fred discovered Visual Basic during a commercial programming consultancy in a manner unconnected with his day-to-day teaching activities. I related how VB had initially interested Fred with its ability to bring display screens of various types into line and make the job of the programmer in displaying graphics on different screens much more straightforward than it otherwise would have been. I showed then how Fred’s interest in VB changed from display screens to its different style of program development, and how VB enrolled him to its style of programming as graphical and event-driven rather than character-based and procedural. In the second key moment I traced how Fred experimented with how he might use Visual Basic in his teaching at Phillip Institute. I showed how, through several translations from ‘Visual Basic the graphical, event-driven programming language’ to ‘Visual Basic the screen prototyping tool’ and ‘Visual Basic the language for operating systems programming’, Fred was able to incorporate two different translations of VB into two Information Systems subjects at Phillip Institute. The next chapter puts the translation of Visual Basic temporarily to one side in order to examine programming languages and events related to business programming at RMIT before the merger.


Chapter 7

Prior Claimants: Pick and Alice Business programming at RMIT (City) before the merger

It was in 1995, some time after Fred’s first tentative teaching experiments with Visual Basic at Phillip Institute, that VB made its appearance in the RMIT Information Systems curriculum in the elective *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ. How it did this is the subject of the next chapter. This chapter is concerned with events at RMIT (City) before the merger while Fred was exploring the possibilities of using Visual Basic at Phillip Institute. When the ‘Fred + Visual Basic’ hybrid arrived on the scene at RMIT with aspirations of gaining a place in the curriculum it was confronted with two well established programming languages: Pick/BASIC and Alice, which were both jealously intent on guarding their territory. VB also encountered a situation at RMIT where curriculum in higher education had to be seen to be relevant to the needs of industry and commerce and where only ‘real’ programming languages were allowed entry. At RMIT a programming language was considered to be ‘real’ if it had a substantial user-base in business and was used by a large number of professional programmers (John 1997). The concept of ‘real programming languages’ is a recurring theme in the next few chapters that is taken up by many actors who use it to mobilise the computer industry in support of these languages in preference to others. It is the detailed subject of Chapter 10. The new Information Systems degree developed at RMIT after the merger owes something to the Information Systems degree from Phillip Institute of Technology, the original RMIT (City) Business Information Systems degree, and the teaching staff, practices and traditions of both institutions. It was into this new degree that Visual Basic eventually established a place for itself in two programming subjects. Some approaches to educational research would suggest that RMIT was simply the context in which Fred worked to find a place for Visual Basic, and from which Visual Basic emerged to take its place in the curriculum. Latour looks at the concept of context rather differently:

“A technological project is not in a context; it gives itself a context, or sometimes does not give itself one.” (Latour 1996 :133)

Visual Basic created its own context, first at PIT then later at RMIT, but it did not do so unchallenged as there were several prior claimants involved in attempting to determine what was meant by business programming at RMIT. Pick/BASIC and Alice and, to a lesser extent Cobol, between them determined how the teaching of business programming was to be defined. It was against the background of well established and highly stable programming networks for Pick/BASIC and for assembly language programming using Alice59 and its predecessors at RMIT that Visual Basic had to contend in order to eventually nudge its way into the curriculum. The network I will refer to as Pick/BASIC consists of more than just the Pick/BASIC programming language. It is a kind of hybrid (Latour 1993) of RMIT and some aspects of Pick and Pick/BASIC that fit with RMIT’s definition of what a business programming 59 The Alice assembly language computer simulator went through a number of variants, sequentially named

Snark, Jubjub, Boojum, and Alice.


language should be. Likewise, the Alice programming network consists of a hybrid of the Alice computer simulator, assembly language programming and elements of RMIT. Because Visual Basic later mounted a challenge to these well established networks, in this chapter I will examine their formation and how they were maintained. I will examine two key moments. Firstly the discovery, translation and adoption of Pick/BASIC as a significant programming language in the curriculum, and secondly the design, building and use of the Alice computer simulator to introduce students to concepts of assembly language programming and computer architecture. Tracing these two moments is important to my study because the two networks were already in place, and being maintained, at RMIT when Visual Basic arrived in 1995. This part of the story is set mainly in the late 1980s and early 1990s, a little before the events at PIT described in the previous chapter. It begins with four actors: RMIT, Pick/BASIC, Alice, and Cobol. The first of these actors; RMIT, is a heterogeneous network built up by the recruitment of many allies during over 100 years of operation. An examination of RMIT reveals its mission of providing an applied tertiary education designed to equip its students to take their place in the business, industrial and commercial professions of Melbourne, along with the implications that this had for curriculum innovations such as the adoption of Visual Basic.

RMIT University The institution now known as RMIT University opened its doors to students in June 1887 as the Working Men’s College (WMC). Unlike its London namesake which was devoted to “literary subjects, Christian principles and the humanities” (RMIT 1997b), the Working Men’s College in Melbourne was more concerned with general and technical education, and in 1899 it began to offer full-time diploma courses in Engineering and Applied Science (Murray-Smith and Dare 1987). During the 1950s, the college developed new courses in Food Technology, Transport Studies, Accountancy, Real Estate and Advertising. In 1960 it adopted the name Royal Melbourne Institute of Technology (RMIT). In 1965 RMIT became a member of the Victorian Institute of Colleges, and the non-tertiary parts of RMIT were reconstituted as RMIT Technical College60 (RMIT 1997b). After the merger with Phillip Institute in 1992, RMIT was granted formal university status and adopted its current name: RMIT University61. RMIT has always prided itself as being a “technological educator” (RMIT 1997a), and has worked closely with industry over the years to justify this title.

“We emphasise education for employment, and our research solves real-world problems. Our courses and research projects are technologically oriented, client focused, creative, innovative and - above all - practical.” (RMIT 1998)

It maintains close ties with industry and commerce and makes every effort to keep its courses relevant to the needs of industry. This vocational orientation has been maintained, and the university’s teaching and learning strategy (RMIT 1995) emphasises that students’ educational experiences will be a preparation for working life. The university’s Web pages proclaim:

“We pride ourselves on providing our students with ‘education for employment’. We provide vocationally relevant courses which ensure our graduates are highly employable

60 RMIT Technical College later became RMIT TAFE, and is currently known as RMIT VET (Vocational

Education and Training). 61 More information on the background and development of RMIT will be found in Appendix A.


in their chosen field. And for mature-age students we offer courses that concentrate on upgrading their existing skills. We’ve been doing it for 110 years!” (RMIT 1997a)

In line with this vocational focus, many of RMIT’s courses include opportunities for periods of professional practice, and all undergraduate business degree programs incorporate a cooperative education year. The university claims to work actively with industry to reinforce the applied emphasis of its education and training programs.

“This is achieved through the participation of skilled industry representatives in the design and evaluation of RMIT programs, the appointment of teaching staff with industry experience, and the extensive employment of guest and visiting lecturers.” (RMIT 1997a)

Like Phillip Institute, RMIT’s Course Advisory Committees were used as one means of channelling curriculum input from business and industry into the academic departments. The Course Advisory Committee of the Department of Business Computing at RMIT will be seen as an important actor when it enters the story shortly. RMIT’s long tradition, and the regard with which it is held in filling an important place in higher education in Melbourne, have been powerful inducements in convincing its staff, students, Course Advisory Committees, and courses to accept and adopt the particular definition of higher education it has proposed. Higher education at RMIT meant an applied professional education that took serious regard of the current needs of industry and commerce. This was, of course, differentiated from industry training that was undertaken in RMIT TAFE and VET (Vocational Education and Training) programs. As far as possible, RMIT curricula aimed to use materials and examples that reflected the situation in industry. In Information Systems this meant, where possible, teaching with ‘industry standard’ hardware and software, and ‘real’ programming languages used in the computer industry by professional programmers. Information Systems at RMIT At RMIT, many actors have been involved in the formation of the Information Systems curriculum. In tracing the networks associated with the adoption of Visual Basic, the academic departments that introduced Information Systems were identified by many of the actors in my study as a good starting point. Beginning in 1984, a Graduate Diploma in Commercial Data Processing was offered by the Department of Administrative Studies. This department however, was quite diverse with many interests more significant to it than computing and there was no specific department or group looking primarily after Information Systems. In 1987, the Department of Business Information Systems was formed out of Information Systems and Applied Office Systems lecturers from the Department of Administrative Studies, and of academic staff from the Faculty of Business’ Computing Services Group (RMIT Faculty of Business 1993a). The Department’s first head was Geoff (John 1997). In 1989, the new department offered RMIT’s first Bachelor of Business in Business Information Systems as before that time there had only been a minor Information Systems specialisation within the Bachelor of Business in Office Systems degree. Although there had been a number of Information Systems subjects offered at undergraduate level within the Faculty of Business in the 1980s these single subjects had not been part of a complete Information Systems degree and had been delivered by individual lecturers with no strong departmental or disciplinary allegiances (John 1997). In line with RMIT’s policy and tradition of seeking the views of commerce and industry on the content of its courses, each academic department was required to set up a Course Advisory Committee. These committees normally meet twice each year. In 1996/97, the


Course Advisory Committee of the Department of Business Computing62 at RMIT had seventeen members; six with connections in the computer industry, four from other universities, and seven academic staff members from the Department itself. Given RMIT’s location in Melbourne’s central business district and its long association with local industry and commerce, it had not been difficult for successive Head’s of Department to persuade prominent IT professionals to sit on this committee. While not having the power to impose curriculum changes on the Department, the views of the committee on matters of curriculum were often sought and, when offered, were always taken into account (John 1997; Donald 1998). The Course Advisory Committee was to become a significant contributor to the department’s Information Systems curriculum by offering a “sobering industry view” (Jean 1998) of any proposed changes and their likely effect on student employment. Interactions between this committee and curriculum developers within the department explain much of the direction taken by the Information Systems curriculum at RMIT. The Bachelor of Business in Business Information Systems offered at RMIT in 1990, before the merger with Phillip Institute, was a general information systems degree, much less oriented towards programming than its counterpart at PIT. This ‘soft’ orientation probably reflected the origins of the department, many of whose members had previously been concerned with teaching secretarial and administrative studies (Stephen 1997). The goal of those designing the degree had been more to cater for the needs of general business students and allow for the backgrounds of the academic staff, than to “push the frontiers” of Information Systems (Geoff 1992). Several academics in the department, however, did have a strong background in systems analysis, programming and computer architecture. It is these people who acted to set the agenda for business programming at RMIT. It is they who spoke for the department in business programming and later pushed the line that such programming should be in ‘real’ industry-based languages (Stephen 1997). The bachelor’s degree was of four years duration including one (compulsory) year of cooperative education involving ‘supervised professional practice’. This ‘cooperative education’ year was intended to give students the opportunity to relate their theoretical learning to industry practice. Although not unique to RMIT, such a co-op year fitted well with RMIT’s intent to be seen to serve the needs of industry and commerce. In addition to twelve common core business subjects, the Business Information Systems specialisation consisted of four compulsory IS subjects (RMIT Faculty of Business 1990).

&RPSXWHU $SSOLFDWLRQV LQ %XVLQHVV6\VWHPV $QDO\VLV'DWDEDVH 6\VWHPV,QIRUPDWLRQ 6\VWHPV 3URMHFW

and eight electives, which need not necessarily be taken from the Information Systems field. A large number of IS-related electives were listed in the handbook, but not all were offered to students on a regular basis (Fred 1997b).

62 When first set up in 1987 at RMIT, the department delivering Information Systems curriculum was known

as the Department of Business Information Systems. After the merger with Phillip Institute its name was changed to the Department of Business Computing.


,QIRUPDWLRQ 6\VWHPV�, (- assembly language programming in Boojum63),QIRUPDWLRQ 6\VWHPV�,,&RPPHUFLDO 3URJUDPPLQJ��$ (- using the Pick environment)64 &RPPHUFLDO 3URJUDPPLQJ��$ (- programming in Pick/BASIC)&RPPHUFLDO 3URJUDPPLQJ��$ (- programming in Cobol)'HFLVLRQ 6XSSRUW 6\VWHPV6\VWHPV 'HVLJQ0DQDJHPHQW RI &RPSXWLQJ 5HVRXUFHV$GYDQFHG 'DWDEDVH 6\VWHPV([SHUW 6\VWHPV LQ %XVLQHVV (VP-Expert) &RPSXWHU 6\VWHPV� 6HFXULW\ DQG &RQWURO2IILFH 6\VWHPV��2IILFH 6\VWHPV��2IILFH 6\VWHPV��2IILFH 6\VWHPV��$GYDQFHG &RPSXWHU $SSOLFDWLRQV LQ %XVLQHVV$SSOLFDWLRQV RI ([SHUW 6\VWHPV (VP-Expert)

Programming subjects had always existed among the Information Systems offerings at RMIT and, during the 1980s a number of different languages including Cobol, LISP, Pascal and Assembly Language had been used at different periods (Adams 1991). Based on RMIT’s history of working with industry, most academic staff had always accepted that there should be a preference for the use of ‘real’ programming languages - those used in business. Languages like Pascal and LISP were only ever used by one or two lecturers and were never able to obtain sufficient allies to build substantial networks. Like at PIT, these languages were used under sufferance on the basis of a claim that they were thought to be ‘good teaching languages’ useful for introducing students to programming concepts (Stephen 1997). No particular programming language however, was able to show its superiority over the others; none was able to obtain sufficient allies to enter the curriculum and maintain its place for any length of time, until the late 1980s when two new languages came onto the scene and changed everything. By 1990, some programming was still taught in Cobol, but Pick/BASIC had become the major programming environment used for teaching purposes and had assembled by far the largest network to become unquestionably the most important programming language in the department. The assembly language computer simulator Boojum65 had also become accepted as an indispensable part of the curriculum for use in teaching computer architecture. From about this time, these two languages came to represent what was generally considered to be the most appropriate vehicles for teaching business programming at RMIT (John 1997); they came to represent business programming at RMIT. How Pick/BASIC and Boojum came to establish such a strong presence and manage to attach so many academic staff, subjects, classes and students as to be accepted as what business programming at RMIT was all about, is what this chapter describes. The way in which Pick and Boojum managed to become synonymous with business programming at RMIT in the late 1980s will become apparent after the analysis that follows.

63 First of the Alice line of computer simulators that we shall meet shortly. 64 As before, programming language names shown in bold are specifically mentioned in the handbook. 65 As previously mentioned Boojum was an earlier member of the Alice family of computer simulators.


The Pick Operating System and Pick/BASIC Today, outside RMIT and some particular segments of the computer industry, few people have heard of Pick. In the mid 1980s however, Pick was in its ascendancy (Stephen 1997) and in the process of assembling a network that would assist its entry into the Information Systems curriculum at RMIT. Pick is a special database-oriented operating system which makes use of a programming language called Pick/BASIC. Pick is described by Pick Systems, its supplier, as follows.

“As a method for maintaining and accessing databases for quick transaction processing and analysis, Dick Pick’s original ‘multi-value’ structure has stood the test of time. Today, over 30 years later, this deceptively simple approach still stands as one of the most robust IS environments ever devised.” (Pick Systems 1998b)

The Pick operating system had its beginnings as part of a research and development project, called ‘Generalized Information Retrieval Language and System’ (GIRLS), for the U.S. Army in 1965. At the end of the project Dick Pick, one of the project’s computer systems engineers, decided to build on the idea of incorporating a form of database access directly into the computer’s operating system. He set up a company that began development work on this idea, resulting in commercial release of the Pick operating system in 1973 (Pick Systems 1998b). Whereas relational database management systems require information to be stored in two-dimensional tables, the D3 data model devised for Pick was multi-valued. This meant that in Pick, a record could have multiple fields with each field having multiple values. Both records and fields could also be made up of multiple sub-values (Pick Systems 1998b). The D3 data model was designed to allow users to store large amounts of data in ‘any way they wanted to’, and to rapidly retrieve it in ‘any form required’. Although not accepted by all IS professionals, advocates of Pick claim that this way of representing information is superior for the creation of business applications. This claim, by those who supported Pick, was the basis of Pick’s initial attempts to enter the Information Systems curriculum at RMIT. Its argument was quite persuasive. Originally the Pick system could be programmed only in assembler, but by the mid 1970s a procedural programming language called Pick/BASIC had been developed. Pick/BASIC was a quite unconventional version of Basic in that, unlike other Basic implementations at that time, it did not use numeric statement labels. It also lacked the usual data typing, recognising variables only as numeric or string, and arrays as either dimensioned or dynamic.

“The complex and confusing world of defined real numbers, integers, single- and double-precision numbers, Booleans and alphanumeric variables is cast aside for a simpler and more manageable view.” (Pick Systems 1998a)

Pick and Pick/BASIC soon gathered an enthusiastic following of programmers and users who saw a place for this database-oriented operating system as a suitable alternative to Unix to run the business applications they needed. Pick had successfully enrolled them. Particularly in the mid to late 1980s, Pick became very popular in certain market segments having assembled a large network of users. In Victorian hospitals, for which some powerful Pick applications had been recently developed, Pick was especially popular (Fred 1997b). Pick had identified a business application area where its database features could win over new converts to the Pick approach, and had succeeded in enrolling many of them to this approach. Its problematisation of Information Systems as requiring a database-oriented


operating system was convincing to many businesses. Pick/BASIC had now become a ‘real’ programming language that was used in business, even if only by some segments of business. Pick’s following of users began to gain strength at the expense of Unix, but Unix was not prepared to loose any its supporters, and fought back. Unix enlisted the help of its allies in the computer industry, university Computer Science departments, and the computing press to praise its advantages as a ‘universal operating system’. Unix and its allies argued that only it could achieve this objective and problematised operating systems as needing to offer similar features and facilities to all computers. There was no place in this view for database features within the operating system. The argument put forward by Unix was convincing and its popularity continued to grow. In the 1980s, one of the drawbacks in using the Pick operating system was that an organisation had to choose to use either Pick or Unix, and Unix was rapidly gaining in market popularity (Stephen 1997). For any organisation, choosing Pick instead of Unix would have been seen as a “courageous decision” (Lynn and Jay 1984). To counter this advantage, in the late 1980s a version of Pick known as Universe was developed to run under Unix. This new development meant that an organisation using Unix could now run Universe66 and so also make use of Pick (Stephen 1997). This translation of Pick into a product that did not have to challenge Unix in an all-out, win or lose battle succeeded in strengthening Pick’s hold on its market segment (Fred 1997a) and succeeded in strengthening Pick’s network of allies and supporters. Now that an organisation which was using Pick did not have to choose either to stay with Pick, and so miss out on what the computer press increasingly praised as the advantages of Unix, or to desert Pick and move to Unix, most adopted Universe to retain the advantages of both. Pick’s network had avoided the desertion of its user allies and so had survived the Unix challenge; for the moment. It had survived, however, by neutralising Unix’ attack, and without weakening or challenging Unix’ supremacy; the result was a draw. About this time, Pick Systems also developed a version of Pick that would run on a microcomputer instead of a mini. This change further enhanced Pick’s attractiveness to a wider audience and so strengthened its sphere of influence and its power to attract new converts. Recent development in the mid 1990s have seen versions of Pick for Windows 95, and Visual Basic extensions that allow use of Pick’s D3 data model with other Windows applications (Pick Systems 1998b). As in the earlier bout with Unix, the Pick network chose to work towards reaching a compromise with the opposition rather than challenging it to a win or loose fight that it judged it may well lose (Stephen 1997). The result was that Pick has survived; it had survived through compromise. This series of translations meant that Pick had now transformed itself into four different, but related products: ‘Pick operating system’, ‘Pick under Unix’, ‘Pick on a PC’, and ‘Pick D3 extensions to Visual Basic’. To survive against strong competition Pick had allied itself with what it saw as influential partners and created a long and stable network that chose to allow Pick to undergo several translations to become what was essentially several new products. This meant that a potential user no longer had to either accept Pick and reject all else, or to reject Pick and adopt one of the alternatives. Had Pick not followed this course, but instead chosen to directly confront its competition in an all or nothing battle, the result would probably have been different and Pick may have lost many of its allies as a result of the Unix network’s successful definition of what was appropriate for an operating system to contain. In the free enterprise world of information technology, the loss of any allies who

66 It has been suggested that choice of the name ‘Universe’ was probably an attempt to counter the claim made

by Unix to be heading towards becoming the universal operating system (Fred 1997b).


might have wanted to use it threatens the financial viability of any product. As a commercial product, the only way Pick could survive was through sales. This threat was certainly serious and if enough of its allies had deserted (Callon 1986a), Pick’s survival would have come into doubt as its network started to disassemble. The changes that Pick underwent allowed it to retain many of its allies and so prevented its demise. Borrowing from Latour’s hotel key analogy described in Chapter 4 (Latour 1991), Pick adopted a series of ‘programs’ that saw it undergo significant changes in response to its customers’ ‘anti-programs’ that followed from their wish to obtain the benefits of using Unix. In a later chapter I will show how Visual Basic adopted a somewhat similar approach to fighting off the challenge of a growing market interest in object-oriented languages as these languages began to assemble longer networks that could challenged those of VB. Pick and Pick/BASIC at RMIT Pick could not have entered the RMIT Information Systems curriculum unaided. It needed to expand its network by the addition of a local ally who was in a position to assist, and who could be convinced to do so. In 1986, Stephen, an RMIT Business Information Systems lecturer who was, at that time, also an RMIT Computer Science student, encountered Pick in a consulting job he had been doing for a trade union (Stephen 1997). The union needed an upgrade to the hardware and software of their Hewlett Packard (HP) minicomputer but the next model in the HP range was judged to be too expensive. They knew they would have to look elsewhere and so went out to tender. One of the companies to tender was offering a Pick system that used:

“... terminals that were extremely ergonomically designed, ultra-thin keyboards with high-resolution screens.” (Stephen 1997)

Stephen indicated that neither he nor the trade union had heard of Pick before, but that the union loved the terminals and so this environment was the one selected. Stephen thus first found out about the existence of Pick for reasons that had nothing to do with Pick itself and had no direct connection with his teaching. Pick had won an ally on the basis of a fortuitous alliance with ergonomic keyboards and screens. The dealer/consultancy that had won the tender had negotiated the association of hardware and software that resulted in this alliance, but this was something I did not pursue further as it was not mentioned by other actors as being significant to the adoption of Pick at RMIT. Stephen said that he knew nothing at all about Pick when it was chosen and had to begin finding out about it. Pick had few ready made intermediaries available for it to use to help enrol new users. There were very few available resources and very little documentation, with the exception of a few books like the ‘Green Manual’ written by Dick Pick himself67 (Stephen 1997). Stephen indicated that it took him a year or so to come to an understanding of Pick and to build a Pick system for the trade union, which was still “thrilled to bits” by the terminals, but by then Pick had become quite popular in parts of the industry as its network continued to grow. Coming to a good understanding of Pick was quite a feat given the scarcity of documentation, but Stephen did get some help. He reinforced his own developing Pick network by visiting other Pick sites and speaking with Pick programmers, users, managers, and installations and enlisting them as allies. Although very different to the sort of programming environment he was used to using, Stephen remarked that:

“I then discovered that if you could get over the humps of getting a mindset about how it worked, you could do anything.” (Stephen 1997)

67 This contrasts strongly with the present situation where the release of any new mainstream PC product is

heralded by a bombardment of third-party publications in all the bookshops.


Stephen also found assistance from some of the other Computer Science students, but not from his Information Systems colleagues who were, at that time, really only interested in their own work which involved little or no programming (John 1997). As we have already seen, few of Stephen’s departmental colleagues had any interest in programming and so he did not look to them as potential allies. He did acknowledge though, that he needed to woo his colleagues to the extent that they would not oppose Pick. He later found an ideal way of doing this through to Pick’s problematisation of business programming that offered a niche market, able to supply new jobs for RMIT graduates (Stephen 1997). Stephen described how he then decided to experiment in using Pick with his students. He said that although he now clearly saw potential for teaching Pick he still had first to convince himself that it would work with his students (Stephen 1997). In 1988 he decided, as Fred was later to do with Visual Basic at PIT, to include Pick in one of his teaching subjects.

“So I snuck it into the course as it existed at that time, as part of a programming subject.” (Stephen 1997).

Stephen further described how the students quickly adapted to Pick and were able to gain an understanding of the business problem very rapidly, something he had not seen with Pascal or any other programming language he had come across. Stephen indicated that he now gained further support by convincing his students, who found Pick interesting, of the possibility that it might enhance their future job prospects (Stephen 1997). He quickly convinced his students that business problems could be better visualised and tackled using Pick than Pascal or Cobol, and said that he had no difficulty in doing so. Stephen said that he now found arguing for Pick’s inclusion in the curriculum quite straightforward (Stephen 1997), and the incorporation of Pick into &RPPHUFLDO 3URJUDPPLQJ��$ and &RPPHUFLDO 3URJUDPPLQJ��$ was formalised by specific mention in the 1990 Faculty handbook. Like the Visual Basic exam question at PIT mentioned in the previous chapter, this ‘text’ (Rip 1986) was the first formal evidence of Pick finding its way into the RMIT curriculum. Specific mention of the use of Pick in two subjects in the handbook meant that Pick must be taught in these subjects until such time as the handbook was formally changed. This, in turn meant that Pick’s future in the curriculum was relatively secure until the course underwent a major review. In 1989, RMIT moved to Universe and so began running Pick under the Unix operating system. This made it easier to manage the use of Pick in RMIT’s student laboratories as before this time it had been necessary for the Faculty’s Computer Services Department to run one minicomputer using Pick and another on Unix. This they did only under sufferance (Stephen 1997). The reluctance of Computer Services to support dual operating systems had acted, to some extent, as a brake on the use of Pick at RMIT; a minor ‘reverse salient’ (Hughes 1988). Adoption of Universe meant an end to this difficulty as now both operating systems could be run on the same minicomputer. This was a cause of great rejoicing in Computer Services and resulted in their alliance with the supporters of Pick (Stephen 1997). Winning over Computer Services, and hence the student labs, as allies to the Pick cause further strengthened the Pick network and make it more durable. Pick now had few opponents and lots of influential allies at RMIT. Two other important events that finally confirmed Pick as an indispensable part of RMIT’s Information Systems courses were Stephen’s participation and leadership in PickLab and the acceptance, by the Course Advisory Committee, of the proposition that RMIT’s Information Systems graduates could be assisted in getting jobs if the course filled a niche market for Pick programmers (John 1997).


From the mid-1980s, the Australian Pick Users Association has held an annual conference, called PickLab, to share the common experiences of its members in working with the Pick environment and in programming with Pick/BASIC. From small beginnings PickLab had grown, by 1988, to a large conference attracting several hundred delegates (Stephen 1997). Stephen attended PickLab several times in the late 1980s, and in 1989 he was appointed Conference Chair. In view of his leadership position in PickLab, Stephen managed to convince the Department of Business Information Systems to sponsor the conference (Geoff 1992). This was an important coup as, apart from furthering Stephen’s authority within the department it also strengthened the position of Pick at RMIT without the expenditure of a lot of money or effort. Stephen had successfully mobilised the Department, and hence RMIT, in support of Pick. RMIT was also the site of the conference in 1990, 1992, 1993 and 1994 with Stephen as Chairman. These conferences confirmed RMIT’s part as a significant actor in the Pick community and, what is more, RMIT was the only university in Victoria that was teaching Pick. Enlisting PickLab, the Pick Users Association and a number of organisations using Pick as allies also helped confirm Pick’s place within RMIT. Stephen further mobilised Pick and cemented his place in the Pick network by being elected President of the Pick Users Association from 1990-1993, and an Executive member in 1994 and 1995 (John 1997). The socio-technical network that was PickLab proved a very useful ally to Pick in firming its place in RMIT’s curriculum. Stephen’s credibility, and that of his Pick network at RMIT, was further enhanced by his involvement in a number of Pick consultancies with quite large companies. The size of Pick’s network at RMIT continued to grow and become longer and more heterogeneous as more and more new actors joined it. One important reason that the Department of Business Information Systems could easily be convinced to sponsor PickLab relates to its Course Advisory Committee. Members of the committee had known little of Pick until the appointment of several new members in the late 1980s. Coincidentally, two of these new members had an interest in Pick, one as the principal of a software house and the other as a Pick user (Donald 1998). Their knowledge of Pick changed things on the committee as their advocacy of Pick with the other members soon convinced them of its value. It is not clear whether the idea that RMIT could control an important niche market for Pick programmers came from this committee, or from Stephen himself (John 1997). Whatever the source, this idea was quickly taken up by Geoff, Stephen and the Course Advisory Committee in support of teaching Pick at RMIT. This proved a very plausible argument as it was demonstrably true that a number of students did get placements in ‘Pick shops’ in their co-op year, with every prospect of these becoming permanent jobs upon their graduation. It also tied in well with what everyone saw as RMIT’s goal of ‘education for employment’ (RMIT 1997a) and how it tailored its courses to the ‘perceived needs of industry’ by the use of ‘real’ applications. The Department of Business Information Systems could now be seen by all to be representing business interests, with the support of its Course Advisory Committee, and so satisfying RMIT’s commitment to producing ‘employable’ graduates (John 1997). The Pick programming network at RMIT now represented a particularly effective barrier to the entry of other challengers to become the main teaching language used at that time. Pick spoke for programming at RMIT. Pick was programming at RMIT, and Stephen spoke for Pick. He had become the spokesman for Pick, acknowledged by everyone who had anything to do with Information Systems at RMIT. In 1996, after discussions with John (Stephen 1997) had convinced him that he needed a new challenge, Stephen shifted much of his teaching load to his other area of interest: networks and data communications, bringing in two new lecturers to assist with the


teaching of Pick. John had argued that Pick was now working well in the curriculum and no longer needed Stephen’s close attention, but that networks and data communications did. In 1997, although now not teaching any programming subjects at all, Stephen still makes use of Pick/BASIC to have his students write CGI scripts68, amongst other things, in his networking subjects. Although he had moved aside and thrust the mantle of sponsoring and teaching it to others, he has not abandoned Pick and still believed that:

“... as a programming environment and as a business computing tool, Pick is a pretty close second to none academically.” (Stephen 1997)

Pick’s enrolment of the Information Systems academic staff has recently however, begun to falter and Pick has suffered some criticism from those who teach business programming at RMIT for its lack of data typing and use of non-standard control structures. Pick had problematised business programming in a way that said that providing a suitable solution to the business problem was what mattered, not the use of standard data and control structures. The new academic staff teaching programming in the mid 1990s however, problematised business programming rather differently. At the height of its popularity in the early 1990s, what these people now began to see as Pick’s blemishes were ignored in the euphoria of its perceived market niche advantages (John 1997). By 1995 other networks seeking to speak on behalf of business programming were becoming more successful in making themselves heard and Pick was being more closely scrutinised as we will see in the next chapter. When questioned about this criticism Stephen, still very much committed to Pick, responded:

“My counter to that is that we’re not here to teach programming, we’re here to teach business computing and solving business problems. Pick does that well.” (Stephen 1997)

Stephen suggested that Pick has now matured as a back-end database environment that goes well with client-server front-ends, and that its future lay in this direction. He made it quite clear that he believed Pick does have a future. Asked how Pick has survived for so long at RMIT he replied that:

“… it is probably due to my intractability that it has managed to stay in place.” (Stephen 1997)

This, perhaps, is a little modest from the acknowledged champion of Pick at RMIT. Pick gained the place it did in the curriculum as Stephen, and his allies, were able to redefine the key attributes of what was required in a language best suited for teaching business programming at RMIT (Latour 1988b :35). In this definition such a language must be prominent in business, and its use should give RMIT Information Systems students an edge in the employment market. This problematisation of Pick as a ‘real’ programming language that provided student jobs was important as it set up Pick as an ‘obligatory passage point’ (Callon 1986b) through which all Information Systems students were required to pass to master business programming at RMIT. Pascal, probably the main potential challenger as a teaching language at that time, and the language most often suggested as an alternative by opponents of Pick, was not used to any great extent by industry and so could not be considered to be a ‘real’ programming language. Pick was ‘obviously’ preferable, its supporters said (Stephen 1997), appealing to RMIT’s mission in applied education. Guaranteed jobs for RMIT Information Systems graduates into a niche market for Pick programmers added weight and support for Pick and made this an easy idea to sell.

68 The Common Gateway Interface (CGI) is a specification that defines a set of standards by which data enters

and leaves an Internet server consistently and predictably. Programs that perform Internet-based data processing and decision making operations are called CGI scripts (Eidahl, Mackenzie et al. 1999: 828).


This is a good illustration of how use of the term ‘real’ in relation to a programming language by someone wanting to give some status to that language represents a mobilisation of the computer industry in support of the view that only programming languages that are widely used by computer professionals are worthy of use in an institution like RMIT. Use of the term invokes a long list of translations that have occurred in taking the language from relative obscurity to the point it now occupies. By appealing to the benefits of a market niche in Pick programming for RMIT students, Stephen and his allies also performed a process of interessement (Callon 1986b) that locked the Course Advisory Committee and the Department of Business Information Systems into continued support for Pick by raising effective barriers against any challengers, or other competing networks such as Pascal. A case was also made against the alternative of teaching Cobol, suggested by some members of the Course Advisory Committee. Cobol is by far still the most prominent programming language used in industry. Based on industry use, it is indisputably the most ‘real’ of all the computer languages, but the advocates of Pick were able to describe Cobol as ‘old hat’ and boring (Rebecca 1997b), and were supported in this view by much of the computer press and by student opinion. Through Stephen and his allies, interessement by Pick had very effectively marginalised Pascal and Cobol in the Information Systems curriculum. The role of Cobol will be considered later in this chapter. The Pick network now effectively owned the business programming curriculum at RMIT. Pick spoke loud and clear for programming at RMIT (Callon 1986b) and Stephen spoke for Pick. This effectively mobilised the Pick network which comprised, among other things, the Pick environment, Pick/BASIC, RMIT Computer Services, the student labs, Stephen, and several other lecturers who taught the programming subjects, the Course Advisory Committee, the Head of Department, RMIT itself, PickLab, and several prominent Pick programmers, sites and users. Pick had become an extremely long, extremely heterogeneous network and was very strong because, as Grint and Woolgar suggest, “the power of a network is equivalent to the cost of dismantling it” (Grint and Woolgar 1997 :57). The potential cost of replacing Pick/BASIC with another programming language would have been considerable, as was later discovered during the merger with PIT. Pick was certainly the strongest voice in programming in the curriculum at RMIT, but it was not the only voice. A machine level simulator used for teaching assembly language, while in no way a challenger to Pick/BASIC, also played an important role in the curriculum and hence as an actor when VB later began its negotiations to enter the curriculum.

Assembly Language Programming – the Alice Simulator In 1985 James began development of a new one-semester introductory subject in computer architecture and operating systems for the Information Systems degree. This was at a time before formation of the Department of Business Information Systems when Information Systems was delivered by the Department of Administrative Studies (Geoff 1992). At this stage the subject was intended to be for all business students, not just those taking Information Systems. James began this course development not because of a suggestion from the Course Advisory Committee, but because he himself saw a need for his students to understand more about how a computer works internally. While developing this subject James decided to build a software simulator to make the teaching of assembly language more concrete (Thomas 1991). The idea was that when using this ‘virtual machine’ the students would be better able to understand what goes on inside a computer. James maintained that they would do so more easily, and in a shorter time than if performing real


assembly language programming which he judged to be more the province of Computer Science. James’s first simulator was called Snark and it, and its successor Jubjub, were used for several years before being replaced by the more powerful Boojum. These simulators were all designed predominantly as teaching machines in the belief that it was important for students to understand how a computer worked (Thomas 1991). A consideration was that while teaching assembly language and machine operation by allowing a student to tamper with the actual operating system on a laboratory computer carried considerable potential for undesirable side effects, using a simulator did not. Alice, the final machine in the line, was designed in the early 1990s with the assistance of a development grant from the Victorian Educational Foundation (Thomas and Tatnall 1995). Alice was a quite sophisticated simulator involving powerful computational features and an interface showing the status of the internal operations of the machine (Thomas 1994).

James always claimed that Alice’s purpose was to teach architecture, rather than assembly language programming, but that the programming was a necessary part of this.

Figure 7.1 Alice Computer Simulator Snark, Jubjub, Boojum and Alice were all creatures of James’s making, although he did have some professional programming assistance. James felt quite self-sufficient in his work and made little effort to convince others or to seek allies (John 1997). The simulators were all based on James’s assessment of what Information Systems students needed to understand about the internal operation of a computer and the best way to teach this. He had been given control of a piece of the curriculum: computer architecture, and used this control and ownership to redefine the teaching of computer architecture to include the use of his computer simulators. James defined the educational problem Alice69 was designed to solve in terms of all Information Systems students having to come to grips with computer architecture so that they could fully understand the capabilities, and limitations, of the machine (Rebecca 1997b). As its creator, James spoke for Alice and the solution he proposed involved the use of Alice as an ‘obligatory passage point’ to this understanding.

69 For simplicity in discussion, from this point on the name Alice will be used to refer to this, and all previous

versions of the machine simulator.


This definition, or problematisation, was the key to Alice’s existence. If Information Systems students needed to have a deep understanding of the internal operations of a computer; of registers, accumulators, assembly language, program counters and I/O buses, then Rebecca (1997b) and John (1997) both agreed that Alice offered an excellent way of teaching this. If, on the other hand, Information Systems students did not really need such detailed knowledge then it was hard to support the use of Alice. Alice contained a fairly homogeneous network based on a claim of what was worth knowing by Information Systems students about the internal operations of a computer. This was a factor in its eventual demise as I shall show in the next chapter. The ‘Carroll Computer Laboratory’ was established within the Department of Business Information Systems in 1992 “to develop visual software emulations of all parts of a computer’s hardware” (RMIT 1997a). The laboratory added credibility to the use of Alice, and so acted as a significant intermediary (Callon 1991) in the Alice network between James and the Information Systems curriculum at RMIT. Although not Head of Department when Alice was born, John supported the concept it represented and indicated his belief that some knowledge of the internal workings of a computer was very worthwhile for Information Systems students. He saw it as something that all his students should have and believed that there was a place for Alice.

“I think the students do need to know something about the internal construction and operation of computers, otherwise all is a mystery, and I don’t like the students not knowing. I don’t think that if you are going to be a professional in a field you should have these kinds of black-boxes where you have no idea what’s going on. There are enough black-boxes now where we only have a sketchy idea. But I don’t think that in our course, when you are trying to teach people the foundations, there should be mysteries about how the most fundamental thing of all actually works.” (John 1997)

John noted that, on the other hand, it was growing increasingly hard to justify that all Information Systems students needed this level of understanding. Rebecca (1997b) said that she had used Alice in class several times for demonstrating how a computer works internally, and had been most impressed.

“It really does give you a full understanding of how a machine works. It all starts to make sense. What is a co-processor? What is a bus? What is the difference between a 16-bit and a 32-bit bus, a 32-bit language versus a 16-bit, and all that sort of stuff. The terms all start to make sense then.” (Rebecca 1997b)

One ally that Alice did make use of was the MS-DOS based student laboratories. As a simulation, Alice ran quite easily on the lab computers requiring no special modification of these machines and not causing problems for other users. Because it allows a programmer to access the innermost parts of the computer and its operating system, use of assembly language could have posed a real threat to the student laboratories. Alice offered no threat in this regard. The alternative of conducting real experiments in low-level programming on the lab computers would have had unpredictable results that could have left the machines in a condition where they were unfit for use by the next class for its accounting, economics or word processing applications. Alice created no conflicts in the student labs and so easily enrolled them, and Computer Services that ran the labs, as allies. Alice was generally accepted as being a good product that filled an important curriculum role by provided a suitable means of showing students the internal workings of a computer (John 1997). The RMIT culture, prevalent at that time, of each individual lecturer being largely responsibility for what they taught made it easy for James to introduce Alice in the late 1980s without much need to specifically justify the details of how he would do so. His


rational, he reasoned, was sound so why should he have to convince anyone else not directly involved? Business Information Systems at RMIT offered a particularly large ‘negotiation space’ (Law and Callon 1988 :296) to its lecturers for the design of curriculum, giving them plenty of latitude and room to move (Geoff 1992). This space meant that James did not have to go out of his way to convince lots of people and win lots of allies to his cause before introducing Alice. He did, of course, discuss what he was doing with the Head of Department, and he also ran several information seminars on Alice (Geoff 1992), but these were more to provide general information on the value of simulators than to gain allies from the staff in his use of Alice. Lack of a need for James to work closely with many others led to Alice becoming a more compact network that Pick, consisting of just Carroll Laboratories, Alice, James, a couple of other academic staff, some student allies, Computer Services, and the MS-DOS computing labs of the time for which Alice was ideal. Had Alice managed to make its network ‘longer’ (Latour 1997) by involving more and varied actors, perhaps its subsequent history might have been different. James had successfully problematised a need for students to understand computer architecture, and had suggested the adoption of Alice as an ‘obligatory passage point’ (Callon 1986b) in its solution. As just a teaching simulation and not a language used for commercial programming, Alice could never be considered to be a ‘real’ programming language in the way that Cobol could. James’s problematisation of the education of Information Systems students meant that this did not matter as what Alice was teaching was important. It is interesting to see that he managed to get his colleagues to accept Alice on this level, whereas those trying to promote Pascal by use of a somewhat similar argument failed to convince them. But then again Alice’s only competitor was ‘real’ assembly language, and this the student labs would not allow. Alice’s whole network, its whole existence, was based on the premise that it was important for all Business Information Systems students to have some understanding of computer architecture, and this is where it later collapsed. While earlier versions of the simulator were not challenged, after the merger Alice did not remain popular with either Information Systems students or academic staff and its network began to collapse. While Alice retained its own strong network and remained an important part of the RMIT programming scene into the early 1990s, changes after that time in the perceived value of requiring all Information Systems students to be exposed, at quite a deep level, to computer architecture concepts meant that a number of these allies later deserted. Rebecca (1997a), originally a firm ally, noted that although Alice was “a great teaching tool” it was hard to justify spending the amount of time needed to learn to use it in an Information Systems course. Paul (1997b) agreed that Alice worked very well and did a good job of showing the internal workings of a computer. He also, however, said that he does not think that this level of understanding is now appropriate in an Information Systems degree. James’s problematisation of the teaching of Information Systems through computer architecture using Alice was beginning to be questioned. If Alice had been used as an elective, these criticisms may not have been as strong. Had Alice not tried to show all Information Systems students how a computer worked, it would probably not have come under the same pressure. The process of weakening Alice’s network began just before new course discussions commenced in 1993 (Chapter 8). Alice lost its place in the curriculum a couple of years later.

Cobol Cobol had been taught, on and off, for some years at RMIT and it had some strong supporters on the Course Advisory Committee. Certainly there could be no doubt that it


was a ‘real’ programming language, and it probably had the best claim of any language to this title as it had been used to a very large extent in business over a very long period (Juliff 1992). Nevertheless, Cobol’s ability during the 1980s and early 1990s to demand a significant place in the Information Systems programming curriculum was quite weak. Its problematisation of business programming in the curriculum was also weak and apart from some members of the Course Advisory Committee, Cobol had few allies at RMIT. Even Rebecca, the lecturer teaching Cobol in the late 1980s and early 1990s, was happy to teach any programming language and had no special love for Cobol above the others (Rebecca 1997b). Cobol had been unable to convince her that it had sufficient benefits to gain her support at the expense of other programming languages. Its interessement of actors allied to other competing programming networks had not been successful. Rebecca could certainly not be seen as a champion for Cobol in the way that Stephen had been for Pick/BASIC, and James for Alice. With no one standing up to support it the view put by some Pick supporters and, from time to time in the computing press that Cobol was ‘past history’, went unchallenged (John 1997). Cobol thus presented no significant deterrent to the growth of Pick/BASIC’s network, and no threat to Pick or Alice.

A Comparison of Pick, Alice and Cobol at RMIT The three programming languages discussed in this chapter have some similarities, but also some important differences in the way they established, or failed to establish (Latour 1996), a place for themselves in the Information Systems curriculum at RMIT. The table below (Figure 7.2) shows the different associations and alliances of these languages in the early 1990s before the merger with PIT. In this chapter I have described another two key moments in my study. In the first of these I showed how Pick/BASIC entered the RMIT curriculum almost by accident through its fortuitous alliance with ergonomic keyboards and screens in a tender to a trade union. In the second key moment I described the introduction of the Alice computer simulator, designed to make concepts of assembly language programming and computer architecture easier for students to grasp. This was the scene at RMIT before the entry of Visual Basic. By the time of the impending merger in 1992/93 Pick was business programming at RMIT. It had established itself as an obligatory passage point in the teaching of business programming that had become almost unchallengeable. It spoke with a loud clear voice for business programming at RMIT. Alice was never a threat to Pick and never tried to become the main language for introducing and teaching ‘regular’ programming. Alice staunchly guarded its place70 as an important part of the curriculum although it only ever aspired to show students one single aspect of programming: low-level machine operations with assembly language programming, and in this it had set itself up as an obligatory passage point. None of Alice’s supporters would have claimed that Alice represented ‘mainstream’ programming; that was left to Pick. Any potential entrant to the curriculum would, however, have had to acknowledge the place occupied by both Pick and Alice in business programming. Although the weak position of Cobol would probably have been quite easy to challenge, the highly stable network represented by Pick/BASIC and the strong Alice network prior to the merger would have made the introduction of any new programming languages in Information Systems at RMIT very difficult (John 1997). It took the destabilising affects of the merger of two departments, with similar but somewhat different philosophies, and the

70 This ANT shorthand means that human members of the network punctualised by Alice took these actions.


entry of a whole new set of actors (Grint and Woolgar 1997), to disrupt and destabilise these networks and open the way for the introduction of Visual Basic.

Pick/BASIC Alice Cobol Human to speak on its behalf

Stephen James No one

Primary role assigned by this human

Database-oriented operating system and programming language

Computer simulator and low-level programming language

(Commercial programming language)

Main use in industry - suggested by the Course Advisory Committee

The creation of business systems used in some industry niches

Not used in industry Commercial programming

Allies and networks at RMIT

RMIT Computer Services, student labs, RMIT, Stephen, other Pick lecturers, Course Advisory Committee, Head of Department, PickLab, Pick programmers, sites and users from industry

Carroll Laboratories, James, two other academic staff, a few students, Computer Services, MS-DOS computing labs

Course Advisory Committee

Place in the RMIT Information Systems curriculum

Introduction to programming concepts for all Information Systems students

Introduction to concepts of computer architecture for all Information Systems students

Programming elective

Justification for its use in the RMIT Information Systems curriculum

Provision of a niche market for RMIT students as Pick programmers. A ‘real’ programming language

Educational simulation designed to show important computing concepts

‘Real’ programming language suitable for business programming

Weaknesses identified by its opponents

None identified in early 1990s. Later, its unorthodox style was criticised by some

Not a ‘real’ language. Single purpose application. This purpose later became unpopular

Seen as ‘old hat’ and boring

Potential competition to introduction of Visual Basic as seen by Fred (More on this in the next chapter)

Strong potential competitor. Would have savagely fought off any attempt to displace it as the introductory language

Potentially a strong competitor in the early 1990s.

None

Figure 7.2 Comparison of Pick/BASIC, Alice and Cobol at RMIT


Chapter 8

The Merger The entry of Visual Basic, continuation of Pick and exit of Alice

Before 1992, RMIT and Phillip Institute of Technology were independent institutions of higher education; RMIT located on several sites in central Melbourne, and Phillip Institute of Technology with campuses in Coburg and Bundoora. In 1990/91, in this period of ‘Dawkins amalgamations’71, RMIT, Footscray Institute of Technology and Western Institute were working towards forming Victoria University of Technology, and Phillip Institute was discussing a merger with nearby La Trobe University. Both of these mergers, in their original form, fell through with Footscray Institute of Technology and Western Institute, but not RMIT, combining to form Victoria University of Technology and La Trobe University amalgamating with Bendigo College of Advanced Education (Maynard 1990; Juliff 1992). These mergers left RMIT and PIT without partners but the government had left RMIT in no doubt that if it wanted to gain university status it would have to merge with some other institution (Donald 1998). The result was that discussions were quickly completed between these two CAEs, leading to Phillip Institute becoming part of an enlarged RMIT University. In this chapter I will trace the participation of new actors including the Australian Computer Society, two Visual Basic textbooks, US Information Systems model curricula, the RMIT Information Systems Undergraduate Course Review Panel, RMIT’s process of Educational Quality Assurance (EQA), Java, Oracle and Otto72. There were some changes in the length of several existing actor-networks, Fred increasing his, and the influence of Alice being considerably reduced. The chapter also maps the negotiations between two existing sets of networks associated with Information Systems: those originally at Phillip Institute and those that existed at RMIT before the merger. Prior to 1992, RMIT and PIT had very little to do with each other and so the networks associated with Information Systems curriculum that had developed at each institution were largely unconnected. Only a single Information Systems curriculum could continue after the merger was complete, and this period was characterised by the various existing networks from the merging institutions vying for a place in the new order of things. How this happened is the subject of this chapter. The chapter traces another four key moments I have identified in the adoption of Visual Basic: VB’s introduction in a new elective designed especially for it, its acceptance in a core programming subject, Pick’s successful efforts at warding off attempts to displace it from the curriculum, and Alice’s unsuccessful struggle for survival. In addition to these key moments, as a backdrop the chapter also details how the merger took place and the networks and actors that were influential in determining the new Information Systems curriculum.

71 See Appendix A. 72 Java is an object-oriented programming language, Oracle is a database management system, and Otto is the

RMIT minicomputer used to run Oracle. These actors will all be properly introduced later.


Mechanics of the Merger The amalgamation of two sizeable organisations cannot happen overnight and the merger of PIT with RMIT took place in several stages over three years. Fred (1997b) described how prior to the merger with RMIT, Phillip Institute staff had discussions with academics from La Trobe University which, in the end, had all come to nothing. In 1992, when the announcement at PIT was made of a merger with RMIT to be effective from July that year Fred remarked that it came without a lot of public discussion and with little previous contact between the two sets of academic staffs. Initially the announcement resulted in little change as it was decided that each merging institution would continue to run its old courses for a period of two years or so (John 1997). The announcement however, did result in an immediate pause in all new formal curriculum development at each merging institution. Before the merger, the Department of Accounting and Business Computing73 at Phillip Institute had seven academic staff74 in Information Systems. The Department of Business Information Systems at RMIT had eighteen academic staff and an additional academic associated with the Australian Computer Abuse Research Bureau (ACARB). In relation to Information Systems, the intent of those planning the merger was clear:

“The merger was to produce one Department with one set of awards to be obtained on one or more campuses. Staff on both campuses were to be fully involved in the work of the department.” (RMIT Department of Business Computing Course Advisory Committee 1995).

As the position of Head of the Department of Business Information Systems at RMIT was then vacant John, Head of the Department of Accounting and Business Computing at PIT, was appointed Head of the new merged department which was subsequently to be known as the Department of Business Computing. John immediately based himself at the City campus and came out to Coburg only one day each week to teach a third-year programming subject. John thus got to know all the City campus staff soon after the departmental merger. Fred (1997b) said that he also took it upon himself to get to know the Information Systems staff in the City campus but that apart from this there was little staff interchange between the campuses at this stage. In order for the new enlarged RMIT to have the appearance of a single university it was necessary to quickly merge the curricula for each degree at each campus so that only one common course was offered (RMIT Faculty of Business 1993b). The complete process, however, took several years beginning with a union of the subjects in each old course and resulting in the design of a new degree. The progress of this part of the merger can be viewed by looking at the RMIT and Phillip Institute handbooks of the time. In 1992 the department offering Information Systems courses at Phillip Institute of Technology was the Department of Accounting and Business Computing, located at Phillip’s Coburg campus. In RMIT, Information Systems courses were offered by the Department of Business Information Systems in RMIT’s Swanston Street West campus. As one would expect, each institution’s 1992 handbook (Phillip Institute of Technology 1992; RMIT Faculty of Business 1992) shows details of only that institution’s courses with no mention of the forthcoming merger. In 1993 and 1994 a single RMIT Faculty of Business handbook was issued showing a single Department of Business Computing based at both City and Coburg campuses. There were then sections detailing the separate courses at each campus (RMIT

73 Formerly the Department of Accounting and EDP. 74 There were twenty-five academic staff in this department but eighteen of these were involved with the

discipline area of accounting.


Faculty of Business 1993a; RMIT Faculty of Business 1994). By 1995 the single handbook (RMIT Faculty of Business 1995) also showed a single course75 for the Bachelor of Business in Business Information Systems, but indicated that this was offered at both City and Coburg campuses. The financial and human cost of running a Faculty of Business across two campuses fifteen kilometres apart was something that RMIT soon decided it was not prepared to continue doing, and a decision was taken to close the Coburg campus, move the Education Faculty to the Bundoora campus and centralise all Business teaching operations in the city (John 1997). The 1996 handbook (RMIT Faculty of Business 1996) showed this department and its new degree course being offered only at the City campus. In 1996 the former RMIT Faculty of Business (Higher Education) and the former TAFE76 School of Business Studies combined into one division called RMIT Business (RMIT Faculty of Business 1997). During this stage of the merger Fred continued to teach Visual Basic as the main programming language in the subject 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ as he had previously done. This subject was now offered, for a short period, at both the Coburg and City campuses as part of the interim degree course. Before the merger RMIT Business had been spread around several buildings in the Melbourne central business district but at the end of 1995, in readiness for first semester 1996, all RMIT business staff (from both the City and Coburg), along with all Business courses, moved into a new campus in a renovated building in Bourke Street Melbourne. Revamping its teaching programs was seen as a priority task (John 1997), and starting early in 1993 the new Department of Business Computing began a complete review of all its course offerings with the goal of creating a new undergraduate degree from the best aspects of each of the existing courses (John 1997). It was during this period that the scene was set and the way was prepared for Visual Basic to formally enter the RMIT curriculum. This stage of the merger process involved a long period of discussions between academic staff from the old RMIT and from PIT, with additional input from various sources ‘outside’ each department (Fred 1997a).

Getting External Input for Curriculum Changes At RMIT a Course Advisory Committee provides its department with a major source of curriculum advice from a commerce and industry perspective, and staff-student consultations help to obtain input from students. These however, were not the only outside sources of curriculum input. The compulsory year of work experience77 for RMIT Information Systems students meant that many academic staff from the department had to go out to visit the places where students who had finished two years of this degree were working. This contact provided useful input from the business community and Fred described how the department recently identified that a lot of the students from their course were going into programming maintenance jobs.

“We scanned our course, to find out where the topics were that had to do with maintenance, and changed and beefed up those topics to make sure that the students were aware that this was an aspect of the industry they needed to deal with.” (Fred 1997a)

One of John’s first tasks in late 1992 as Head of the new merged department was to set up a new Course Advisory Committee. He recruited the members of the new committee from former members of the old PIT and RMIT Course Advisory Committees but also added

75 This course was an interim one and not the final accredited version of the new degree. 76 Technical and Further Education. 77 Co-operative Education.


some new members and left out some of the previous members who he judged had not contributed much (Donald 1998). Donald, chair of the Course Advisory Committee during this period, believed that the Committee made a significant input into curriculum at RMIT, and that its advice was seriously regarded.

“I think that John is a person who listens to advice. The committee that John has put together is not half bad, and John does float things in front of them, and he does listen to what they say. I would say it is listened to and, if you are on it, you do get the impression that it is worthwhile having your sixpenny’th worth because the Head of Department is actually valuing what you tell him.” (Donald 1998)

Donald remarked that John and he had similar backgrounds, both coming from commercial origins and teaching first in the CAE sector. John was also a member of the corresponding committee in Donald’s department at Deakin University. Donald went on to note that John used the Course Advisory Committee to outline what the department was doing and to ask for ‘approval’ of their ideas. This can be confirmed from the minutes of the October 1996 Courses Advisory Committee meeting (RMIT Department of Business Computing Course Advisory Committee 1996) in which Paul, Course Coordinator for the degree, is seen to seek the committee’s views on the use of Pick/BASIC as the first programming language, and Visual Basic in $SSOLFDWLRQV 'HYHORSPHQW�,,. He also told the committee how some cooperative education employees had expressing concern over the difficulty in obtaining students with Cobol skills. Curriculum development is essentially a departmental academic activity, and in a university it is difficult for any entity to impose curriculum change from above or from outside. The ‘global network’ (Law and Callon 1988 :289) involved in curriculum development at RMIT consisted of ‘external’ (Lambright 1994) actors including the Course Advisory Committee, past and present students, employers, the Australian Computer Society (ACS)78, and RMIT itself. The academic staff of the Department of Business Computing then acted as a ‘local network’, which actually contained the global network (Law and Callon 1988 :289) and spoke for it on curriculum matters. The global network, of necessity, negotiated with John to grant a considerable degree of autonomy to academic staff within the Department of Business Computing to handle the detailed development of curriculum and to perform its delivery without constant outside monitoring and interference. This “relatively autonomous negotiation space” (Law and Callon 1988 :296) was conditional upon John, as Head of Department, acting as an ‘obligatory point of passage’ (Callon 1986b) for all matters that needed to pass between the two networks. This arrangement was readily accepted by all actors and the negotiation space has been happily maintained since the merger.

Conference Papers, Textbooks and Demonstrations In 1994, while Fred was experimenting with VB at Phillip Institute, I introduced Visual Basic in a third-year Information Systems subject at Victoria University. During this period Fred and I often worked together to find the best way to present event-driven programming concepts to our students. As it is beyond the scope of this study I will tell no more here of the introduction of VB at Victoria University except to say that it did have some parallels with this investigation and will make an interesting study at a later date. At this time Fred and I also wrote a number of academic papers outlining our experiences in teaching with Visual Basic in our courses (Davey and Tatnall 1995; Tatnall and Davey 1995; Davey and Tatnall 1996).

78 - through its course accreditation activities. This is fully described in a later section.


The publication of these papers could have been seen as an attempt by us to create what Latour (1987) calls ‘immutable mobiles’ for the purpose of translating (Latour 1986) our teaching innovations to a wider audience of actors in other universities. ‘Texts’ (Rip 1986) like these can be an effective means of convincing others to adopt an innovation and because they must act at a distance and so have to be able to stand by themselves, “all the forces of interessement have to be presented explicitly” in a text (Rip 1986 :87). Whether or not this was a result of our conference papers we do not know, but it was not our deliberate intention to achieve this. What we were attempting to do, probably unconsciously at the time, was to obtain some reinforcement for our actions by seeking the support of academics at other universities; we were looking for allies. We used the papers to test the water to see if our ideas also made sense to others, and as a result we succeeded in enrolling a number of our peers from other universities as allies in our VB networks; allies we wondered if we might later need for support. As Visual Basic was new and few of the other academic staff in our departments knew anything about it, Fred and I jointly ran a demonstration and laboratory practice session for Information Systems academic staff at Victoria University in early June 1994, and a similar session at RMIT (City campus) a week later. This was the first time that we had to publicly defend our advocacy of Visual Basic with our colleagues. We had them work through some of the VB exercises we did with our students and explained why we saw it as important to progress the programming curriculum in this direction. In each case the demonstration session went well with encouragement, support, and positive comments from our colleagues far outweighing doubts about Visual Basic’s suitability as a teaching language. Even though we fully expected that many of them would not themselves use VB in the near future, at this stage we were well on the way to enrolling our colleagues as allies, at least peripherally, in our VB networks. This work may have helped reduce the likelihood of later attack from potentially competing networks involving similar products like Borland Delphi and IBM Visual Age. Such attacks did come after some time from one or two staff, but by then Visual Basic had become entrenched in the curriculum and so easily prevailed. Another consequence we did not consciously intend was that these sessions also promoted each of us into positions of unambiguously speaking on behalf of Visual Basic at both institutions; we had successfully mobilised VB in our respective institutions. As there were no available textbooks that we judged to be suitable for use in teaching Visual Basic, Fred and I decided that we would write our own, and A Guide to Visual Basic (Tatnall, Davey et al. 1995) was published in July 1995 and Visual Basic for Business Applications (Tatnall, Davey et al. 1997) a little later. Not surprisingly, the books were adopted at RMIT and Victoria University and we each used them with our respective students. Like the academic papers, the books acted as texts which represented “a carefully structured actor-world” (Rip 1986 :84), and while we hoped that they would have the affect of acting to further the adoption of Visual Basic in other universities where they were used, this was not our primary purpose; we really just wanted to create resources for our own students. The textbooks did, however, act to entrench our positions as spokesmen for Visual Basic, to define how VB was taught in our respective degree subjects, and also to influence how the language was later used in other subjects in our courses. More so than the academic papers, these books played an important part in making VB’s place in the RMIT Information Systems curriculum more durable79. They did this by becoming what Callon (1991 :134) calls intermediaries in the process of defining the

79 They also had this effect at Victoria University, but that is another story and another research project.


relationship between Fred’s ideas of what should be included in the curriculum with those of Paul, Rebecca, the other teachers of Visual Basic and the students. The books ascribed (Akrich 1992) certain attributes to Visual Basic by facilitating some possible uses of VB and, by their omission, disallowing others (Lundberg 1997) and so were able to influence how the other actors saw Visual Basic. As Callon says:

“... actors define one another by means of the intermediaries which they put into circulation.” (Callon 1991 :140)

Development of the New Degree In early 1993 several documents from the new (combined) RMIT Faculty of Business described the process to be followed and a framework for redevelopment of Bachelor of Business degrees which needed to take account of the offerings from each campus (RMIT Faculty of Business 1993b). These documents gave an overall specification for the degree and set the balance between core business subjects and each of the discipline specialisations. In the case of Information Systems the new course was to be of four years duration, including one (compulsory) year of cooperative education, and consist of six core business subjects, a Business Information Systems major of twelve subjects, and six electives (RMIT Faculty of Business 1997). In 1993, after examining the Faculty documents John issued a memo suggesting a process for creating a single degree in Business Information Systems (BIS) by the integration of the existing degree programs at RMIT (City) and PIT.

“The guiding strategy should be to seize the opportunity presented by the merger to the combined department, to build an integrated course that not only incorporates the strengths of the existing programs but also identifies the emerging trends in information technology and addresses the needs of the future.” (John 1993a :1)

The suggested process involved setting up a panel with a brief to prepare an issues paper to be referred to academic staff and the Course Advisory Committee for input and comment. This issues paper aimed to convince the academic staff of the need for change (Schein 1961; Davis, Rhodes et al. 1998) and to suggest a direction for this change. It was to identify:

• Course objectives. • Course structure constraints. • Emerging Information Technology trends and an evaluation of their likely

impact on the curriculum. • How graduates and employers see the existing courses as satisfying career

aspirations and work requirements. • Improvements and changes that need to be incorporated into the

integrated degree. This will show revised course, and year by year objectives, broad course structure guidelines and proportions of subject area to be covered.

(John 1993a :1) A model degree structure was then to be proposed by the panel, where possible using existing subjects. This course proposal would be referred to staff and to the Course Advisory Committee for further suggestions and then for final approval. The proposal made it clear that the Panel’s role was only to set up the course structure and provide an outline of the content of each subject; it was not to do the work of fully developing each of the subjects. The Panel was thus not in a position to determine which languages would be used


in the programming subjects. The process suggested for the panel was a highly collaborative one, designed to facilitate the involvement of all staff in building a single Information Systems curriculum. It was designed to weaken, and hopefully dissolve, the existing separate networks of each of the old institutions.

The Information Systems Undergraduate Course Review Panel In April 1993 John (1997) set up the Undergraduate Course Review Panel to perform this task, indicating that he had been conscious of the need to create an interest and readiness for change in his staff (Stark and Lattuca 1997 :333; Davis, Rhodes et al. 1998 :326-329). The purpose of the panel was to facilitate curriculum change, and its members were deliberately chosen to include the curriculum opinion leaders and the “movers and shakers” (Fred 1997b) from each of the old departments. It was to be an obligatory passage point through which all curriculum matters must pass. The panel’s membership was John (HOD), Stephen (City), Brian (Coburg), Fred (Coburg), Alan (City), James (City), and Gary (Course Advisory Committee). There had been very little formal contact between the teaching staffs on the two campuses and Fred suggested that:

“The model that the Head Of Department had in mind was for an ‘expert group’ to meet and discuss with the Course Advisory Committee, and come up with a good idea for a new course.” (Fred 1997b)

Fred said that the small size of the committee was mainly because John did not want a lot of people having to take the time to drive between campuses for meetings. On the other hand, ‘political’ considerations were also seen as important to the future workings of the new department and it was thought to be important that a balance be seen to have been met between the curriculum of each of the former departments so that neither group would think they had been ignored or their interests disregarded (Fred 1997b). It was hoped that the committee would not come up with anything too radical, but rather with a good compromise that would be acceptable to all (Fred 1997b). It was also hoped that the committee’s suggestions would be transmitted into action without a great deal of further discussion. It was, nevertheless, physical movement considerations and not an attempt to reduce curriculum input to a select group, that was the motivation in setting up this group in the way that it was (John 1997). In a memo (John 1993b) to all members of the Department of Business Computing in July 1993, John tabled the panel’s first Undergraduate Review Working Paper and called for discussion and contributions. A question was later asked at one of the Course Advisory Committee meetings about the research by the panel that had gone into informing the curriculum review. The answer from John (RMIT Department of Business Computing Course Advisory Committee 1995) was that a number of sources had been tapped, including: • Feedback on all subjects and courses from current students, obtained informally and

also in the process of complying with RMIT’s Educational Quality Assurance policy80. • Suggestions from departmental academic staff solicited during ‘discipline

conferences’81. • Industry surveys including the ‘Discipline Review of Computing Studies and

Information Sciences Education’ (Department of Education Employment and Training, Department of Industry Technology and Commerce et al. 1992).

80 See next section. 81 Two overnight discipline conferences were held at venues outside Melbourne in 1994.


• Model curriculum documents produced by the DPMA and ACM (Nunamaker, Daniel et al. 1982; Longenecker and Feinstein 1990; Turner and Tucker 1991)82.

• Reviews of similar degree courses in other Australian universities. • Discussions with various industry representatives. • Research into the types of jobs that Business Information Systems graduates went into. One of the sources of ideas for the new curriculum came from the model curricula proposed by the ACM and DPMA, but as IS’9583 was not released till very late in the curriculum development process no use could be made of it. John indicated that the panel used the available model curriculum documents, but questioned their value for detailed course design.

“I found a lot of the stuff was so generic – they are talking about motherhood stuff, but they are useful benchmarks and we did certainly put things in that were useful and we should continue it as a bench-marking exercise.” (John 1997)

Fred (1997b) pointed out that the main use the panel made of these model curricula was in looking to see if they contained any aspects of Information Systems that the panel had not thought of, and to see other ways the material could be grouped into subjects. Donald (1998) could not remember much mention of model curriculum documents at Course Advisory Committee meetings, and noted that many of the people sitting around the table would not have been familiar with these anyway.

“The view of the business people on the committee would be something like this: ‘Look you guys in the university are basically doing a pretty good job, so we presume that you are looking at those sorts of things and keeping yourselves up to date with them and therefore it’s not our job to be going and asking you to write us a three page summary as to where your curriculum coincides with the current best practice or whatever.’ They tend to take the view that academics are professionals and that looking at these things is their job.” (Donald 1998)

These curriculum documents also constituted ‘texts’ (Rip 1986) intended, by their designers and the computer societies that they represented, to act as ‘immutable mobiles’ (Latour 1987) that could be used to cause the translation of their version of Information Systems curriculum to universities around the world. More use was made of these model curriculum documents during the university and ACS course accreditation process, but this will be discussed later. Course Teams and Educational Quality Assurance at RMIT In the early 1990s the Commonwealth Government made it a requirement for all universities to be audited by the Committee for Quality Assurance in Higher Education (CQAHE) and in response RMIT set up its own system of Educational Quality Assurance (EQA). The EQA system was not fully in place during the time the Information Systems Undergraduate Course Review Panel was doing its work and so it had little effect on development of the new degree at that time. In on-going curriculum development some aspects of EQA, and especially its requirement for the creation of ‘Course Teams’, did have a significance effect as EQA sought to negotiate a role for itself and to redefine the process of planned curriculum change. John Bowden (1997b), who was Director of RMIT’s Education Program Improvement (EPI) Group during the period of the study, claims that the concept of making 82 - discussed in Chapter 2. 83 See Chapter 2


improvements to educational quality was not new to RMIT which first set up an Educational Development Unit in the late 1960s. He writes that RMIT’s EQA system was set up both to demonstrate educational accountability and in a genuine attempt to make teaching and learning in the university better and insists that the system is well based in educational theory.

“The approach that RMIT has taken to educational quality assurance has been to attempt to achieve an appropriate balance between the improvement and accountability aspects of quality assurance…” (Bowden 1997b :2)

A key element of the system was a focus on degree ‘Course Teams’ working together to continually improve the quality of teaching and learning by taking responsibility for course quality and its evaluation. These Course Teams were expected to ensure that continual improvements were made in learning experiences and outcomes through attention to issues including teaching, curriculum, assessment and course management (Bowden and Knowles 1994). A Course Team is typically composed of the subject coordinators of each subject offered in the course, and is normally chaired by the Course Coordinator. Course Team meetings are held regularly to discuss teaching and learning issues related to the particular course (Benjamin and Bricknell 1997). RMIT’s EQA system is evidence-based, which means that Course Teams need to establish Quality Improvement Cycles (QIC) of design, reflection, change and evaluation. They need to accumulate and document evidence of the strengths and weaknesses of current programs, and to develop appropriate course change processes.

“The model is that changes to a course should only happen because something documented has happened – students have made complaints, the community which the course services has made some sort of comment, or the Course Team has noticed something. So every quality cycle starts with a documented reason for some improvement being needed. Then the Course Team meets and decides what they are going to do about it, then they document that, and then they implement it and document the implementation. Then they review it and make sure it did have some effect on the thing that was identified as being wrong. In general, everything that is minuted is supposed to be followed up.” (Fred 1997a)

The EQA system was intended to monitor and influence the on-going small changes made to a course during its life, rather than to engage in large-scale curriculum revision. EQA thus did not play a large part in the design of the new Information Systems degree except in one respect: the effect of the new Course Teams which had not previously existed. In the Department of Business Computing there were four Course Teams: one for the undergraduate degree, one each for the two graduate diplomas, and one for the masters course. These groups of academics with a common interest and commitment to a particular course were highly focused on any changes needing to be made to that course. It is really through the actions of the undergraduate degree Course Team that the effect of the EQA system was manifested in the process of designing this new degree. Introduction of Visual Basic in a Graphic User Interface Elective Discussions and negotiations about the new course continued over almost a two-year period, with formal accreditation of the final version being completed late in 1995. During this period however, a significant event occurred when Visual Basic made its appearance in a new elective subject. Although developing a new course or redeveloping an existing one at RMIT is quite formal and involves a rigorous accreditation process, getting an elective onto the books is a good deal easier.


In what I regard as the first key moment of ‘the merger’, Visual Basic was first formally introduced in its own right at RMIT in 1995, in an elective subject called *UDSKLF 8VHU ,QWHUIDFHDQG (YHQW�'ULYHQ 3URJUDPPLQJ (Rebecca 1997b). The new elective was designed by Fred and first delivered by him in second semester 1995 at the Coburg campus just before its closure. The way that electives are instigated at RMIT is interesting; they are usually developed and sponsored by a person with an interest in this topic. Any academic who acquires an expertise in a particular area and thinks that there might be a demand for this as a subject among the student population can propose an elective (Paul 1997b). There is, of course, a process whereby electives have to be certified by the Academic Board, and Paul (1997b) noted that each proposed elective is supposed to be brought up in the Course Team where there should be some discussion on whether it is an appropriate subject to offer to students at this level. He pointed out however, that this is mainly just rubber-stamping as long as the proposed elective is generally considered to be of value. The Graphic User Interface (GUI) elective was proposed by Fred, and in relation to this elective Paul commented:

“So it depends on the person, and the reason Visual Basic is used in this elective is purely because of Fred.” (Paul 1997b)

Microsoft Visual Basic

Programming languages like Cobol and Fortran have been a feature of the computer industry now for over forty years, and Pascal and C for around thirty years. Microsoft Visual Basic is a relative newcomer, being released in 1991. A Visual Basic program involves construction of one or more interface screens, each based on a form. Controls (such as buttons and text boxes) are added to a form to give it functionality. The way that the programmer works in designing the interface is to select controls (objects) from a tool-bar and then drag and drop them at appropriate places on the form. Next, properties are assigned to each of these objects. Each object has an associated set of event-procedures that can be made to execute when a given event (such as a mouse-click) occurs. The program statements manipulate objects and can cause changes to object properties, or cause actions (known as methods) to occur in event-procedures. As writing code is almost the last step (Figure 8.2), it is possible to get quite a long way before coming to this and in some cases to produce a complete system with no code at all. It is possible, for instance, to create a program to view the contents of a database (see Figure 8.1), using very little program code (Tatnall 1997).

Fred (1997b) indicated that *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ was designed as a programming subject from the beginning. He spoke of how he thought that it was important to show students an entirely different type of programming language than the normal third generation procedural languages they were used to. He said he wanted something different also to the brief exposure students had to the dBase IV Application Generator which had been shown as an example of a fourth generation language, of a sort.

“Well, VB had always been a small partner in the other subjects, and it seemed to me that there was a rationale for having Visual Basic as a separate study which you could do lots of, and so I invented a subject to do that sort of thing.” (Fred 1998)


Figure 8.1 Personnel Viewer; VB runtime screen84 (Tatnall, Davey et al. 1998b).

As I have demonstrated, Visual Basic had previously enrolled (Callon 1986b) Fred and he had become its spokesman and chief ally at Phillip Institute. After teaching with VB in several subjects at PIT during 1993 and 1994, and co-writing several academic papers and textbooks on VB, Fred now had a good understanding of the language, and how it could best be taught. He was, furthermore, seen as an innovator by his colleagues at Coburg (Paul 1997a) and, after working for some time on the Course Review Panel, increasingly also in the City campus. Fred’s forceful personality (Rebecca 1997b) was such that he was always able to make his voice heard in curriculum negotiations at RMIT. If Fred suggested that it would be a good thing, and worthwhile to the students, to introduce an elective to teach Visual Basic, there was unlikely to be much opposition. After all, everyone acknowledged that “Fred knew all about Visual Basic” (Paul 1997b). The key to getting VB accepted this easily was that introduction of the new subject was not seen by other academic staff as challenging or threatening any existing subject or language (John 1997); it was initially just added on as an elective that taught ‘just another programming language’. It is, perhaps, a little surprising that this was not seen as a threat by supporters of the other electives given the fact that students could still take only a finite

84 This screen is taken from the text by Tatnall, Davey et al. (1998b) and contains data on a fictitious

employee. The picture is used with the subject’s permission.


number, and that if they chose the GUI elective then they must omit another. Nevertheless, no one spoke against including this new elective (John 1997) as Fred had been able to argue that RMIT students needed a better understanding of programming in a Windows environment and of styles of programming different from that of Pick/BASIC. He was able to couch his problematisation of the need for introducing a different programming environment in terms where the obvious solution pointed to Visual Basic. Visual Basic now had its foot quite firmly in the door.

Figure 8.2 Visual Basic design screen with code

for the ‘Personnel System’ (Tatnall, Davey et al. 1998b) The name of the new subject, Fred (1997b) said, was descriptive of the subject content as each of its two aspects: graphical user-interface programming, and event-driven programming represented a different programming paradigm than the conventional procedural one used in Cobol, Pascal and Pick/BASIC. Visual Basic characterised a convenient way of showing this new paradigm. Fred said that incorporation of Visual Basic’s ‘Data Control’85 was important, as it was always in his mind to use VB to move between computing platforms and so to access Oracle DBMS86 on the minicomputer. He commented that he saw Visual Basic as a convenient way of doing this because, in his experience, attempting to do the same things using an X-Windows programming environment would not work due to lack of support at the university network level. Whereas the faculty’s Computer Services Department was quite easily able to support the use of Microsoft Windows on student laboratory PCs it did 85 This was included from version 3.0 of VB 86 Oracle is a powerful Database Management System that runs of a minicomputer. It is used in many medium

and large organisations and is the world’s best selling DBMS.


not have the personnel or the expertise, Fred (1997b) judged, to support extended use of X-Windows. Despite being designed to easily move data across platforms from the PC to Unix, X-Windows thus could not muster sufficient support to represent any competition to the use of VB. In the 1980s, Fred had been a member of the Victorian year-12 &RPSXWHU 6FLHQFH subject committee, and at the time of the study he was prominently involved in determining details of the curriculum for one strand of the VCE87 ,QIRUPDWLRQ 7HFKQRORJ\ field of study. He remarked that some of his thinking about the use of Visual Basic came out of discussions he had in trying to make the year-12 subject more representative of what goes on in the computer industry. He said that these discussions, in the late 1980s and early 1990s, before VB was available, made him think about what programming really involved (Fred 1998). He noted that he then saw quite clearly that programming was not always going to be represented by languages like Pascal, QuickBasic or Cobol, and that there were other things programmers could do (Baron 1986). When he encountered Visual Basic, he saw VB as one means of showing a good example of another different “thing programmers could do” (Fred 1998). Fred said that this is what showed him that VB had a ‘real place in the curriculum’88. It is what made Visual Basic ‘real’ for him. It would thus appear that the year-12 subject committees, which Fred still maintained as networks, contributed to Fred’s ideas on VB by providing another external source of ideas; that for a time they constituted another ‘external network’ (Law and Callon 1988).

Event-driven programming languages

As an event-driven language, Visual Basic differs considerably from procedural languages such as Pascal, Cobol and other versions of Basic. In a procedural language, a program executes by moving sequentially through one line of code after another. The program retains control and directs logic flow from the beginning to the end in an orderly top-down manner. Programs in an event-driven language, however, consist of a number of independent procedures, each associated with an object defined in the program’s user interface, which execute only when a particular event calls that section of code (Tatnall, Davey et al. 1998b).

*UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ was Fred’s first attempt at building these ideas into a complete subject, and represented a milestone for Visual Basic in making a durable place for itself in RMIT’s Information Systems curriculum. The Visual Basic that gained entry into this subject was, however, not the same Visual Basic that had been used at Phillip Institute, but a translation of VB to become ‘Visual Basic the GUI programming language’. Fred had mobilised Windows programming, programming of a different style to Pick/BASIC, and jobs for RMIT graduates in launching this new subject. VB’s network had worked hard to establish Visual Basic in commercial programming, and the large number of job advertisements for VB programmers in the press indicated that it had been very successful. In this new subject Visual Basic was able to stand in its own right as a ‘real programming language’. It now had the opportunity, with Fred’s assistance, to enlist more allies to ensure its place in the curriculum at RMIT. It now had a good opportunity to go on to bigger and better things and to forge a durable place for itself in the curriculum.

87 Victorian Certificate of Education (- year 12) 88 See Chapter 10.


University and ACS Course Accreditation To keep faith with the needs of industry and commerce, and also to ensure that its courses are kept up to date, all RMIT degree programs are put through a formal re-accreditation process every five years (Bowden 1997a). New or changed degree courses, such as the Information Systems course produced as a result of the merger, also had to be accredited. RMIT’s rules said that the accreditation should be carried out by a panel with membership from the department proposing the course, its Course Advisory Committee, academics from similar departments in other universities, representatives from industry, and representatives from the relevant professional society - in this case the Australian Computer Society (ACS). Many professional societies act as gatekeepers to their professions, but this has not really been the case with computing in Australia. This has been due, in part, to the acute shortage of people trained in this area and the necessity for employers to take the best they could get; qualified and certified or not (Maynard 1990). In recent years, however, the situation has changed and certification has become more significant. An important reason for an academic department to apply for ACS accreditation is in an attempt to enhance the job prospects of its graduates (Juliff 1990) by mobilising the ACS and the computer industry to this end. Even though it was not required to follow the curriculum recommendations of a professional society like the ACS, the Department of Business Computing also applied for ACS accreditation for its revamped degree course. Both Maynard (1990) and Juliff (1990), who have done much of the ACS course accreditation work in recent years, commented that the ACS had little effect on the content of tertiary computing courses until the mid 1970s when it began formally accrediting these courses. In the late 1970s and 1980s however, not every tertiary institution had been happy with the ACS’s accreditation criteria. Geoff (1992), who was HOD of the Department of Business Information Systems at the time, conveyed that he believed that the ACS had a fairly strict view that its membership should be restricted to &RPSXWHU 6FLHQFH graduates, and that its criteria for course accreditation reflected this view. Geoff’s interpretation may however, have been coloured by the fact that in the late 1980s as HOD at RMIT he had been unable to secure ACS accreditation for his department’s *UDGXDWH 'LSORPD LQ &RPSXWHU 6WXGLHV. He blamed ACS ‘Computer Science bias’ for this, but Maynard and Juliff both disagreed, saying that there really were some structural problems with this course which seemed somewhat “Mickey Mouse” (Maynard 1990). When the degree course was due for re-accreditation a couple of year later, Geoff worked through the university procedures but did not seek accreditation from the ACS. The role of the ACS in the curriculum revision is more complex however, than it might initially appear. One obvious aspect of its role is in its course accreditation activities. Not so obvious was the more subtle influence coming from its members who included Donald, John, Paul, Fred and many of the other RMIT Information Systems academics and the Course Advisory Committee. As ACS members all these people were committed, to a greater or lesser extent, to supporting the ACS view of what it meant to be an Information Systems professional in Australia. Fortunately, what the ACS considered to be important matched quite closely with the views of RMIT and hence the Course Advisory Committee and Department of Business Computing. The new HOD, more attuned than his predecessor to the philosophy of the ACS and to the wishes of RMIT to work closely with the computer industry, was determined to get things right this time (John 1997). In mid 1995 he applied for both university and ACS accreditation of the new degree program.


“I’ve always taken the view that ACS accreditation is important. This is the third course that I’ve been involved with the design of that has ACS accreditation. I think it is important from the point of view of marketability, apart from anything else. The more recognition you can get the better.” (John 1997)

The ACS worked with the Course Advisory Committee to set up a joint accreditation panel which met later that year. The task of this panel was to examine the submission from the department regarding the aims, objectives, teaching methods and composition of the curriculum. It also examined the qualifications and experience of the academic staff delivering the course, and the resources, such as computing laboratories and library facilities, available to assist them. In an ACS course accreditation, an attempt is made to see if the new course covers all the things that the ACS judges that such a course should. To do this it is compared with various standard curriculum models such as IS’9789 or, more recently, the ACS’s own curriculum model90. In this case the Department of Business Computing was thus required to set out where its course was similar, and where it differed from these curriculum models. The course accreditation involved a set of negotiations between the Department of Information Systems, the ACS, and the model curricula. The goal of the professional societies that had designed the model curricula (Davis, Gorgone et al. 1997) had been to convince course developers in the USA and elsewhere to an acceptance of certain views they proposed on what an Information Systems curriculum should contain. The goal of the ACS was to ensure that the curriculum being assessed met the needs of its members in the computer industry for ‘suitably prepared’ graduates (Maynard 1990), and it did this by comparing this course with the curriculum models. These curriculum models could thus be regarded as texts (Rip 1986), mobilised by the ACS and its American counterparts to further their view of IS curriculum by causing a translating in RMIT’s curriculum in line with their own views of what it should contain. The result of the process was that the new degree was accredited, with no substantial changes, by both the university and the ACS and was ready for delivery to students in 1996.

The New Degree Course The newly accredited RMIT Bachelor of Business in Business Information Systems consisted of six core business subjects, two subjects from the RMIT context curriculum91, a Business Information Systems major of twelve subjects (including four core programming subjects), and four electives (RMIT Faculty of Business 1997). In addition to the business and context curriculum subjects, Information Systems students had to undertake the following subjects of the Business Information Systems major:

6\VWHPV )RXQGDWLRQV&RPSXWHU )RXQGDWLRQV (Programming subject - Pick/BASIC) ,QIRUPDWLRQ 7HFKQRORJ\�,,QIRUPDWLRQ 7HFKQRORJ\�,,6\VWHPV $QDO\VLV DQG 'HVLJQ�,6\VWHPV $QDO\VLV DQG 'HVLJQ�,,$SSOLFDWLRQV 'HYHORSPHQW�, (Programming subject - Pick/BASIC)$SSOLFDWLRQV 'HYHORSPHQW�,, (Programming subject - Visual Basic)6\VWHPV ,PSOHPHQWDWLRQ�,6\VWHPV ,PSOHPHQWDWLRQ�,, (Programming subject - OO language)

89 Neither IS’95 nor IS’97 were available at the time of the course review and the older DPMA and ACM

models were used instead. 90 The ACS only started using its own curriculum model after the RMIT accreditation. 91 This consists of a number of general subjects aimed at broadening the students’ horizons.


and two other subjects from the following list:

&RERO (- programming in Cobol) *8, DQG (YHQW�'ULYHQ 3URJUDPPLQJ (- programming in Visual Basic)2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ (- programming in C) 2EMHFW�2ULHQWHG %XVLQHVV $SSOLFDWLRQV$GYDQFHG 'DWDEDVH&RPSXWHU 6XSSRUWHG &R�RSHUDWLYH :RUN.QRZOHGJH %DVHG DQG ([SHUW 6\VWHPV&RPSXWHU 0RGHOOLQJ IRU %XVLQHVV 'HFLVLRQV7HFKQLFDO :ULWLQJ3URMHFW 0DQDJHPHQW IRU 6\VWHPV 'HYHORSPHQW7HFKQRORJ\ DQG WKH /DZ3&V DQG /RFDO $UHD 1HWZRUNV$GYDQFHG 6RIWZDUH (QJLQHHULQJ&RPSXWHU 6HFXULW\ DQG &RPSXWHU 6\VWHPV $XGLW'HFLVLRQ 6XSSRUW 6\VWHPV

The four additional electives could also be chosen from this list but, alternatively, could come from the offerings of any other business discipline within the university.

Programming Languages and Course Proposals In 1997, two of these core subjects were taught using Pick/BASIC (&RPSXWHU )RXQGDWLRQV and$SSOLFDWLRQV 'HYHORSPHQW�,), one using Visual Basic ($SSOLFDWLRQV 'HYHORSPHQW�,,) and the last (6\VWHPV,PSOHPHQWDWLRQ�,,) using Oracle92. The elective subject - *UDSKLFDO 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ also used Visual Basic. Since 1997 most of the Visual Basic programming has been taught by Fred, Rebecca and Paul. As previously discussed, the task of the Course Review Panel had been to propose a course structure and outline for each subject, and not to specify details such as which programming language would be used. Decisions on the choice of which programming language to use in each programming subject were thus quite deliberately not made at the time the course was being designed and accredited.

“The whole idea was to make platform independent subjects that talked about concepts out of the discipline rather than teaching specific languages.” (Fred 1997b)

Choice of language became an implementation decision that was taken fairly late, not long before the subject was offered for the first time to students. Donald also remembered discussion along these lines in the Course Advisory Committee.

“John has always made a point, and it strikes a cord in me as well, that you try to write your syllabus as product-free and language-free as you can, so that you can put in whatever you like at the time.” (Donald 1998)

At the course design stage the panel proposed four core subjects dealing with programming – many more than in the old RMIT City campus course and closer to the situation that had existed at PIT. Fred (1997b) suggested that before the merger some of the City people felt that programming was not necessarily an important part of an Information Systems degree. This situation, the Panel believed, had needed correction (John 1997). Donald suggested that the impetus for an increase in the stress on programming did not come from the

92 In 1998 this changed to Java. This change is discussed in the next chapter.


commercial members of the Course Advisory Committee, although they would probably have agreed with it.

“I don’t remember it even being an item of discussion. It certainly was not a matter of the Course Committee saying ‘hey you guys have got to get your arse into gear and put some more programming into it’.” (Donald 1998)

Where the move to increase the amount of programming came from is unclear but, according to Fred (1997b), it probably grew out of the differences between the original RMIT degree and that at PIT, combined with the greater stress on programming in the model curricula. Another possibility lies in the observation that John, Stephen, James and Fred, all of whom were on the review panel, were all also interested in teaching programming (Wood and Davis 1978) and so gave more importance to this topic than some others (Fred 1997b). While not wanting to specify the actual languages to be used, the panel did discuss programming paradigms and made an effort to lay down some general principles for the content of these subjects.

“The first two subjects were to focus on some structured programming – traditional structured programming. The first one was to focus at a micro-level where students learned to develop small programs, develop algorithms, use design techniques and tools, and to code their designs in proper structured code, test them, and so on. The second subject was to introduce the idea of complexity so that students had to learn how to develop designs using modularity, and all that entails, and the tools to support them. That sort of thing. Also size with respect to the complexity of the stored data that’s used, so multiple file handling and so on became part of the picture.” (John 1997)

Although not explicitly stated, and even though it was expressly forbidden by their guidelines, there appears to have always been a tacit understanding among members of the review panel that the first two subjects would be taught using Pick/BASIC (John 1997). The network that Stephen had engineered around Pick was by now so long and powerful that any attempt to remove it was almost unthinkable (John 1997). Dismantling this network would have proved very costly (Grint and Woolgar 1997 :53-58) as it would have required the weakening of a lot of associations, and convincing a large number of Pick’s allies to change their allegiances. There were, however, no prior assumptions about the programming languages that might be appropriate for use in the two later subjects.

“The idea of the third programming unit – that is $SSOLFDWLRQV 'HYHORSPHQW�,,, was that we would start the shift into some of the newer issues that were relevant, such as graphical user interface, client-server concepts and possibly multiple platforms. So, for instance, you might have a database, say in Oracle, being interfaced with some other development environment - ODBC; those sorts of concepts. So the purpose of $SSV 'HY�,,�� was a move away from just strictly text-based structured concepts to start to incorporate some of the, if you like, newer emerging developing issues of concern.” (John 1997)

Unable to attend the Course Advisory Committee meeting in October 1996, Donald responded to the agenda by writing to John giving his views on programming languages. He mentioned the trend towards object-oriented programming and pointed out that, although very expensive, Deakin University used Oracle as their ‘industrial strength’ DBMS. His views on teaching Cobol and Visual Basic are especially interesting.

“We have been using VB for two years with great success. The non-computing students can cope with it and you can use it to teach almost anything you need to communicate about writing software. It has the advantage that the students are able to get some

93 $SSOLFDWLRQV 'HYHORSPHQW�,,


immediate feedback from their programming effort. A compromise would be to use Delphi, which has Pascal syntax.

To Cobol or not to Cobol? We believe that it is still a necessary vocational skill for students to have. We have been building systems in assignments, which use VB as a front-end to capture data on a binary file and then process the file using Cobol and its variety of easy-to-use file organisations. Best of both worlds.” (Donald 1996)

The issue of using ‘real programming languages’ is also something on which Donald commented. He noted that from time to time people on the Course Committee had mentioned the advisability of having something that was commercially standard being taught, and had pointed out that RMIT was more concerned than some of the more traditional universities with turning out ‘readily employable’ graduates who are more attractive to industry.

“A couple of people around the table, including myself, have said that moving to teach to industry standards is all very well. But if we want to teach people on AS-400s using a standard IBM operating system or whatever, be aware that this is going to cost us zillions of dollars and we just don’t have the authority to do that. So, by definition, what educational institutions try to do is to teach things that are representative of what students will meet when they go to work for you. So, be aware, that we cannot guarantee that they will have done your language, on your equipment, using your operating system, supporting your database package. The consensus around the table has been, ‘yes, we understand that’. ‘All we ask, and hope I guess, is that the students have done something that is representative of that.’ ” (Donald 1998)

Jean (1998) also commented on the Committee’s concern that only a ‘real programming language’ should be used. She suggested that they would have been concerned with the use of something like Microsoft Access as a programming language94, or anything “that sat inside a package”. She also indicated that one or two of the industry representatives on the Committee were also very suspicious of anything coming out of Microsoft and so would have had some concerns about the use of Visual Basic (Jean 1998). The minutes of the Course Advisory Committee meeting show that there was discussion on what constituted an ‘appropriate’ programming language to teach to Information Systems students (RMIT Department of Business Computing Course Advisory Committee 1996). The consensus was that students needed to learn fundamental skills and be exposed to a range of programming paradigms. Transferability of skills was also an issue and there was concern that a language not be offered just because it was “flavour of the month” (Jean 1998). It was also thought desirable, where possible, to expose students to contemporary developments in programming languages. The committee was most interested to investigate what languages were being used in similar courses at other universities (Jean 1998). Despite the fact that it was the review panel’s intention to keep details of programming languages out of the course descriptions, one language did creep in. Referring to a memo from John (1994) in July 1994 to all Information Systems staff on proposed course structure, Luis (1994) commented that the proposed subject &RPSXWHU )RXQGDWLRQV mentioned use of Pick in its content outline.

“I believe that all reference to programming concepts should be generic. Why is ‘Pick/BASIC’ plastered all over the syllabus? Why not leave out references to particular languages and keep our options open?” (Luis 1994)

94 At this time this was a language called Access Basic. In later versions of Access this was replaced by Visual

Basic for Applications (VBA).


He also remarked that since, from its course description, this subject was obviously intended as an introduction to programming, perhaps its name was less than appropriate. &RPSXWHU )RXQGDWLRQV also suffered criticism from other sources, with Rebecca (1994) also commenting on the inappropriateness of the subject title, and suggesting that the content looked less like a general introduction to programming than an introduction to Pick/BASIC. Luis further questioned the impartiality of the Course Advisory Committee towards Pick, suggesting that the continued use of Pick seemed like a foregone conclusion:

“Several of the industry representatives are well known Pick professionals; is someone trying to stack the committee in favour of the Pick environment or is it a coincidence?” (Luis 1994)

Donald disputed that there was any pro-Pick bias on the Course Advisory Committee. He agreed that several members of the Committee had considerable expertise in Pick and also with Cobol, and that one committee member was the principal of a software house, but stated that he cannot remember any occasion where a committee member attempted to bring pressure to bear for the adoption of any particular programming language (Donald 1998). Luis was aiming at the wrong target, he suggested. But this begs the question of what the right target was. Despite the Course Review Panel’s stated goal of keeping its subject descriptions language-free, Pick had managed to sneak in. It had managed to do so largely because the length and durability of its network had made the inclusion of any other language in its place unthinkable to most people. Visual Basic and Applications Development-II In 1996 the third core programming subject $SSOLFDWLRQV 'HYHORSPHQW�,, ran for the first time. Given the intention of the review panel that this subject should move students away from procedural, character-based languages and to look at interfacing with database management systems (DBMS), it was little surprise that the programming language chosen for use in this subject was Visual Basic. The incorporation of VB in this subject constituted the second key moment in this section of the study of the adoption of VB and was, in my view, especially important as it represented VB’s acceptance in a core programming subject that was undertaken by all students. Of course the Visual Basic adopted in this subject was not the same as that earlier adopted in the elective, but another translation of VB to become ‘Visual Basic the language for rapid application development with databases’. After the experience of Fred’s GUI subject had shown students and many of the academic staff some of the ways in which it could be used, VB was easily able to enrol many of them as allies in its attempt to become the language of choice for this subject (Paul 1997b). The main aim of the subject was to show students how a programming language, Visual Basic in this case, could use SQL95 commands to interact with a DBMS96 (Paul 1997b). Accessing databases of various types is extremely important in business programming and Visual Basic’s acceptance of a role to perform this task gave it a considerable advantage over other many languages (Rebecca 1997b). John reflected on the decision to use Visual Basic in this subject:

“VB at the time looked like the best vehicle to do that. It had a good graphical user interface capability, it could interface with other database management systems and it was also popular in the market - that was an important reason for choosing it. They also had

95 Structured Query Language (SQL) is the most commonly used tool for extracting data from a database. It is

a generic, rather than a proprietary language, and is available in database systems including Oracle, IBM DB2 and Access, and programming languages such as Visual Basic. SQL commands can be embedded in other programming languages like Cobol but doing so is not as straightforward as the approach offered in VB.

96 Database Management System.


some experience of using it in electives and so on. I think for all those sorts of reasons it was chosen. It was also seen to be relatively widely used around the system by other people. It was to be something that could be learned without too much clutter, compared to some of the full heavyweights of commercial software, like Oracle Forms. I think they are the reasons.” (John 1997)

Fred, Paul and Rebecca were attracted by Visual Basic’s graphic user interface capability and its ability to interface easily with various Database Management Systems (Fred 1997b; Paul 1997b; Rebecca 1997b). They also saw its popularity in the computing industry as an asset that they could use in support of using VB in this subject. Fred, Paul, Rebecca and Visual Basic had teamed together to deliver programming in $SSOLFDWLRQV 'HYHORSPHQW�,, or, if you like Fred, Paul and Rebecca had been assigned to teaching the subject and had chosen VB as the vehicle. They chose Visual Basic because it seemed to them like the “obvious answer” to their problem (Paul 1997b) and I will now explore why this answer seemed so obvious to them. Paul and Fred were close colleagues who had worked together first at Whittlesea Technical High School, then at Phillip Institute. They had even shared an office at PIT. Like Fred, Paul had started off programming in Applesoft Basic then moved to Microsoft QuickBasic. He had tutored in subjects where Fred had experimented using Visual Basic at PIT. Although perhaps not quite to Fred’s level, by this time Paul had been strongly enrolled in the VB programming network (Fred 1997b). Before taking up a position at RMIT, Rebecca had been a commercial programmer and had always been interested in looking at new programming languages. In 1995 she had adopted Visual Basic in her subject in the Graduate Diploma and had watched Fred’s experiments with VB in the GUI elective with much interest. Although declaring that she owed no allegiance to any particular programming language Rebecca (1997b) was now coming to accept VB. Visual Basic’s interessement had weakened her involvement with other languages in favour of its own adoption. When it came to choosing a programming language for $SSOLFDWLRQV 'HYHORSPHQW�,, it is hardly surprising that easy access to remote databases, and its different style of programming made Visual Basic seem like the ‘obvious’ choice for this subject to Fred, Paul and Rebecca. Paul (1997b) indicated that he is not even sure who made the final decision to go with Visual Basic. He noted that the original intention was to use Oracle and have the subject revolving around the use of a programming language front-end on an Oracle database. As they knew what VB could do, and had experience of using this language and not much experience of the alternatives, VB seemed like the answer and they attempted using it as the front-end:

“... but we had a lot of trouble getting ODBC97 to work with Oracle. When it did work it worked particularly slowly and it certainly wasn’t capable of handling a tute group of twenty students making an ODBC link at the one time. The only times we managed to do it were a couple of times in class, and it was taking half an hour. It worked all right in our offices so eventually it turned out to be just a theory class saying that this was possible – and we said: ‘Late one night if you are the only person in the labs you can give it a try’. But this semester we can’t get it to work at all. I think they have fiddled with Otto98.” (Paul 1997b)

97 Open DataBase Connectivity - a Microsoft technique of accessing data from ‘foreign’ databases. 98 Otto is the minicomputer used to run Oracle. It is run by the Faculty of Business Computer Services group.


Although Visual Basic had enrolled Fred, Paul and Rebecca and they had enrolled it in $SSOLFDWLRQV 'HYHORSPHQW�,,, they had not succeeded in making firm enough allies of either Oracle, Otto, or the Faculty Computer Services group to work with VB. Having the minicomputer Otto work in a predictable way was crucial to getting VB to link up with Oracle, but Computer Services did not cooperate sufficiently to make this connection work. The alliance was not sufficiently robust and so Oracle played a smaller role in this subject than originally planned. Paul recalled that another reason for adopting Visual Basic was that the Course Advisory Committee had seen a need for graduates to know about procedural third generation structured programming, but also for programming in an object-like, GUI-type environment. They particularly mentioned the need to be able to program in Windows. Another factor was that the Committee indicated that they would prefer the language to be different to others the students would have used elsewhere in the course. Paul remarked:

“Pick programmers can’t go and start programming in Windows very easily! So we decided to introduce Visual Basic. Also VB was readily available, it was quick off the mark and probably one of the first of its type to be marketed at software shops. Students could easily get hold of it and use it on their home PCs. Fred was the resident expert, so we did have someone who knew a bit about it, and it was a Microsoft product.” (Paul 1997b)

Being a Microsoft product was definitely to Visual Basic’s advantage (Paul 1997b). It mattered who VB’s parents were, and which network it was associated with, for two main reasons. Firstly, as the industry leader in microcomputer software, being a Microsoft product almost guaranteed VB a significant share of the visual programming market. The Microsoft network had made all the associations and obtained all the necessary alliances from programmers and products, to retailers and advertising, to ensure this. Products like Delphi and Visual Age, with much shorter networks, would have had to be seen as a lot better than Visual Basic to challenge Microsoft’s network and overcome its marketing advantage. RMIT’s policy of using ‘real’ programming languages, while not ruling out Delphi and Visual Age which were also seen as ‘real’, would certainly have favoured a product with the share of the market and number of allies that Visual Basic commanded. Secondly, and more pragmatically, RMIT had an agreement with Microsoft that, because of the magnitude of its software purchases, allowed it to purchase Microsoft software cheaply in large quantities for student laboratories. Microsoft then made use of this device to enrol RMIT in its software network. Being a Microsoft product was certainly significant and much to VB’s advantage! Donald remembered the programming languages discussion on the Course Advisory Committee and added that Visual Basic could now meet the criteria to be classified as a ‘real’ programming language.

“I’m sure that the Course Committee would have looked favourably at Visual Basic. Whilst some may not use VB in their own environment, they would say well, that doesn’t matter much because at least you are teaching them event-driven software with GUIs etc. That’s OK. Lots of people do use VB, and what you are teaching would be pretty much transportable into the environment we are using anyway.” (Donald 1998)

Paul added that the choice of Visual Basic was consistent with the initial programming language that was also (Pick) Basic and that this contributed to its selection. Another point in its favour was that Fred, Paul and Rebecca saw that VB was becoming more popular and employers were looking for people with VB skills. This suggested another link to provide more jobs for RMIT graduates. But Fred, Paul stressed, had been the key.


“I think Fred’s involvement and use of VB contributed. I think he was on the original team that designed the course, and I think he would have known he would have some involvement with this subject.” (Paul 1997b)

Rebecca (1997b) said that it was generally felt that a language other than Pick/BASIC was necessary for the third programming subject, and the fact that Visual Basic was event-driven and could easily “hook into a database” (Rebecca 1997b) meant that it was a good choice. For Rebecca, VB’s translation into a language for accessing databases was very significant in her enrolment. In the process of choosing Visual Basic, no serious attempt was made to look at alternative languages such as Borland Delphi or IBM Visual Age (John 1997; Paul 1997b; Rebecca 1997b). The fact that Fred, Paul and Rebecca now had some experience with teaching Visual Basic in other subjects was enough to ensure that, given that a language of this type was needed, Visual Basic was the one chosen. VB’s enrolment of Information Systems curriculum at RMIT through these other subjects had marginalise its competitors to the extent that they were dismissed, almost out of hand.

“In choosing VB I think it was a case that people knew of it, used it, had had experience, knew others were using it, knew enough of it to know that it would do the job.” (John 1997)

John indicated that Fred’s influence was significant, and that although Rebecca has some little experience of using Visual Basic, it appeared to him that she and Paul had been greatly influenced by Fred.

“There were people like Fred who had experience with VB who thought it was a good thing to use. Yes I think that Fred was somewhat of a champion of it at that time. Fred was using VB back at Coburg. It’s got a bit of a history going back a number of years, and that is probably not an uncommon phenomenon with the adoption of languages; that they get tried out by someone in electives or modules or segments until they prove to be useful. They seem to be popular in industry and in educational circles, and we build up knowledge. People champion them, feel that there is an investment of energy, time and know-how here and they should be adopted further. This is often the way these things happen.” (John 1997)

Fred, however, denied any attempt to ‘sell’ the idea of using Visual Basic after the merger, saying that to do so would not have been successful because of the “culture” (Fred 1997b) existing in the RMIT City campus at that time.

“I think it is because I didn’t sell it that VB has become so important. There was a big resistance to people who were seen as someone who would live or die because of the particular software package they wanted to use. I think people who were prepared to rationally discuss things and look at alternatives and whatever, and train other staff and involve other staff, had a big edge over the people who were fighting rearguard actions.” (Fred 1997b)

Fred suggested that the “culture” (Fred 1997b) in the City campus had been one of subject ownership, and that some lecturers went to great lengths to preserve what they saw as their reason for existence in the institute. This assertion is borne out by the events described in the previous chapter. Fred said that when he was investigating subjects during the design of the new degree he found considerable overlap between them, but that this was hidden as the exclusive ownership of subjects even went to the stage that some lecturers would not allow subject documentation to exist, let alone be passed on to someone else (Fred 1997b). He said that he believed that this was because the academics involved saw any change as potentially having a devaluing effect on the time they had invested in gaining experience in


their area of expertise (Fred 1997b). These lecturers were attempting to preserve the networks they had put so much effort into creating but they were preserving them as homogeneous and exclusive by forbidding or restricting the production of any texts (Rip 1986) that might allow others to question what they were doing. This, of course, also meant that they could not enrol other academic staff to assist them in the maintenance of these networks. Jean (1998) believes that the original group at RMIT were “not team players” and were “fairly distrustful of each other” and “fairly wedded to their own particular ways”. To succeed against these isolated networks Fred judged that the introduction of Visual Basic had to be seen as a cooperative effort and not something he alone wanted to push (Fred 1997b). He then proceeded deliberately to engineer Visual Basic into the curriculum in his own way by seeking small, unobtrusive ways to let other staff see aspects of the success of the GUI elective, with which he was now clearly identified. He did this through various means including encouraging students to speak of the subject to other academic staff (Paul 1997b). The Survival of Pick Despite severe criticism from a number of lecturers during the course review, Pick/BASIC survived the merger and, being taught in two core programming subjects in 1999, remains the major programming language in the degree. This third key moment tells of how the Pick network survived, despite making the mistake of taking Pick’s place in the curriculum for granted. Fred suggested that there were three main factors contributing to Pick’s survival: the fact that it gave RMIT’s students almost exclusive access to a niche market, the perseverance of Stephen to fight against any change that would have diminished its importance, and the changes that Pick underwent to make itself more acceptable (Fred 1997b). It had a long network of allies, and had undergone the translations required for survival. Due to staffing and resource implications the number of different programming languages that any course can sustain is limited (John 1997), and what was happening with both Pick/BASIC and Alice had a potentially significant effect on the future of Visual Basic. This was particularly the case with Pick/BASIC as had Pick not survived as the main programming language in the course, the way would have been opened for Visual Basic to become a challenger in this role. This however, was not to happen. John described how the introductory programming language at Phillip Institute in the 1980s had been Basic, and that this had been followed by subjects with programming in Cobol and finally in a 4GL. The introductory language had been switched to Pascal in 1990. Although it was not a language much used in industry, Pascal was adopted as it was thought by a number of the academic staff (John 1997) to be better than Basic for introducing programming concepts to students. RMIT City campus had, as we have seen, moved along a quite different path. When discussing the issue of programming languages in the course review, John described the impending clash.

“So we arrived with Pascal, Cobol and Basic into the City, but the City had staked its flag to the mast on teaching Pick. There was a very strong champion of Pick in the place at the time, a very strong champion who was teaching it. And he was teaching with success, I’ve no doubt. This particular champion knew the language very well, and with all due respect I think, had a reputation around the country as being something of a guru, and he was deferred to and recognised as being a guru.” (John 1997)

As we have already seen, Pick’s hold on programming at RMIT was extremely strong, and the length of Pick’s network gave it some particular advantages. Rebecca (1997b)


mentioned the niche market that Pick had offered in exchange for RMIT’s support over the years, and how this represented jobs for RMIT Business Information Systems graduates. Paul (1997b) added that because RMIT was one of the few universities using Pick it had captured this niche market, and so any company running a “decent-sized” Pick system (Paul 1997a) and looking for graduates would have had to come to RMIT. John agreed:

“I felt that we had a very strong niche market; very strong at the time. Rightly or wrongly I felt that we were in front, we had our foot in the door with a captured market of a lot of potential co-op places, and indeed graduate places in that market if we continued, so there was a strong reason to do that.” (John 1997)

He added that for “very largely political reasons” (John 1997) at the time of the merger they had tried hard to pick up elements of both courses in the new design and that “Pick got carried over largely from the weight of support that was apparent in the City at the time” (John 1997). But Pick/BASIC also had some severe disadvantages as Paul described:

“It is a nasty programming language. It doesn’t capture the imagination of students anything like VB would, it’s hard to get into, it’s text-based, it doesn’t run under Windows. I’ve no hesitation in saying that it probably causes a certain percentage of student drop-out when they are confronted by this thing that is so difficult to use. It doesn’t run on a PC99, the students can’t go home and develop expertise in it, and textbooks are very hard to find. Go to any book store and say ‘I want a book on Pick programming’ and you are flat out to find one.” (Paul 1997b)

Rebecca commented that with Pick/BASIC there were some important concepts, such as parameter passing and data types, that you could not easily teach (Rebecca 1997b). She added however, that even though Pascal would probably have been easier to teach, “Pascal is not out there, but Pick is” (Rebecca 1997b); Pascal was not ‘real’ like Pick. As far back as 1992 there had been some questioning from the Course Advisory Committee of the choice of Pick/BASIC as a programming language. (RMIT Department of Business Computing Course Advisory Committee 1992). There was also far from unanimous support for the idea that teaching Pick guaranteed jobs for RMIT graduates into a niche market, with one RMIT staff member describing this as “a diminishing possibility” (Luis 1994) in the late 1990s. In 1994, in a memo to the Course Team doing a subject review of the Graduate Diploma in Applied Information Systems, Ian (1994) commented on the subject %XVLQHVV 6\VWHPV�$. This subject acted as an introduction to programming and also to databases. Ian taught the subject in 1993 and said that he believed the amount of time that had to be spent on database systems was excessive because of the use of PICK to teach this. The programming part of the subject was also taught using Pick/BASIC and Ian added that he did not believe that the students received an adequate grounding in structured programming techniques by using Pick/BASIC. He suggested that the next time the subject was offered, Pick be removed and an alternative database package, such as dBase IV, and a programming language like Pascal, be used in its place. His suggestion was, however, not considered until the following year. Pick was also anything but popular with the Graduate Diploma students. Both formally and informally they had indicated that they wanted to move away from Pick/BASIC. Rebecca, who next taught this subject the following semester, isn’t sure whether it was Pick itself

99 Although this was true in 1997 when Paul was interviewed, in 1998 RMIT obtained a version of Pick/

BASIC able to run under Windows on student PCs.


that was the problem, or whether it was that many of the students just did not like programming.

“Some of them really are against doing programming and don’t feel they should have to. They also complained about Pick from the point of view that they have never heard of it before, whereas if you give them Visual Basic they have all heard of it. I think that was certainly an issue to post-graduates because they want to be dealing with the latest and the greatest all the time.” (Rebecca 1997b)

This comment points to VB’s success in making itself known in the business world, and in managing not to look much like a typical programming language. In the mid 1990s, although Pick still had a significant place in some specific industries it did not have the influence it had had a few years before and it was virtually unknown outside these niches. Whereas Pick had failed to work its way into the general consciousness and go on to recruit more and more allies, VB was succeeding in this task remarkably well. As I showed earlier, this was due in part to the length of the Microsoft network. Pick’s enrolment of Stephen and Information Systems at RMIT was still strong, but it had begun to take its position for granted when it really needed to make an effort to keep enrolling new allies, like the Graduate Diploma students. In 1995, the next time this subject was taught, after her experience with Pick the previous year Rebecca adopted Visual Basic in its place. In taking this step she had observed VB’s success in Fred’s GUI subject and had listened to staff and student comments about this subject. She said she thought it looked as if VB may have the answer and spoke of why she introduced Visual Basic in this subject.

“We were trying to introduce information systems to the students with a bit of practical hands-on work with a database and a programming language. So we initially started with Pick because you could use Pick Access and Pick programming which gave both sides of it. But then I changed that subject as the Pick system was far too confusing for them. I changed it to Microsoft Access and then as the Pick/BASIC programming language had its problems too, we moved to Visual Basic.” (Rebecca 1997b)

Rebecca did not remember how she first learned about Visual Basic but thought she might have heard of it from Fred when he was working at Coburg. After this she had followed what she saw as VB’s success first in what Fred was doing at Coburg, then in the GUI subject, and thought it was time to try it out for herself. Although not as yet fully mobilised, Rebecca was moving towards accepting enrolment in the VB curriculum network. When asked what clinched her decision to go with Visual Basic in this Graduate Diploma subject, Rebecca replied:

“Firstly because it hooked into Microsoft Access. Plus it’s fun to program in and you get into it quicker and you see a quicker result on the screen; you see whether something works or it doesn’t. But the major reason was having the easy database link.” (Rebecca 1997b)

Here again Visual Basic’s translation to a database programming language associated its Data Control and its other database features as one of its most important attributes, and one of its most effective means of enrolling new allies.


Visual Basic 4.0

This version of VB, released in November 1995, saw a move towards better object-orientation with the addition of the ability to insert objects as controls, a new collections object, and an object browser. It also added Data Access Objects and several new data-bound controls. The Professional Edition offered a programmer the ability to create DLLs100, along with a number of additional data-aware custom controls. The Enterprise Edition had extra features for data access, and the ability to create more robust client-server applications (Microsoft 1995).

Most of the academics from Coburg did not favour any decision to remain with Pick, but the language did have some strong supporters in the City. With a potential fight on his hands over Pick, John (1997) decided to make a political compromise, asking “what is better than Pick?” “What would be used in its place?” (John 1997) As Visual Basic was then not quite ready for such a challenge, and as Fred had judged that it was better not to engage in a fight that VB may well loose, it was not a contender (Fred 1997b). The main possibility at the time, and the language that had recently been used at Coburg, was Pascal. But while Pascal could claim to be a good teaching language it was not much used in the computer industry; it did not qualify as a ‘real programming language’ (John 1997). Given the strong industry connections RMIT had developed and the niche market for RMIT students that Pick had created, John reasoned that Pascal was just not a better alternative to Pick.

“I’m not having a big front-of-the-barricade brawl to put in something that is blooming well no better, and I said that if you want me to fight at the barricades to put Pascal in, then I’m not going to. I suppose, in the end, I took a decision for pragmatic reasons. The Department was brand new and we were tackling a big job trying to weld it together.” (John 1997)

Although it had some allies to speak in its favour, Pascal could not gain sufficient support to become even a half-hearted challenger to Pick. It could certainly not get to the stage of being ready to mount a serious challenge. So the decision was taken to use Pick in the first two programming subjects, but that did not end the discussion as many of the Coburg staff remained to be convinced, and the antagonism continued. In a memo to John, Fred (1993) describes a meeting with Stephen (the main supported of Pick). He describes how he attempted to convince him that while the Coburg staff would argue in favour of Pascal this represented no real threat to Pick. Fred’s own links to Pick, through the work expertise of his brother Mike, meant that Fred had enough understanding of Pick to speak quite knowledgably of it. This raised his credibility with Stephen who was satisfied that although Fred was far from being an ally, at least he was not an enemy. This apparently calmed the waters for a while, but the issue was still alive in 1997 as Stephen indicates.

“Apart from the last two years, every year there has been an attempt to lever Pick out of the place and bring in something mainstream, on the grounds, and only on the grounds that everybody else does it. Totally ignoring our niche markets, totally ignoring the edge it gives our students over others, and the fact that we are a Business Faculty not a Science Faculty. These are the battles that are constantly fought.” (Stephen 1997)

Pick, with Stephen’s support, had proceeded into a position of sufficient strength at RMIT to withstand almost any challenge at this stage. Pick could take the line: ‘Slander my attributes and capabilities if you like, but I’ve got powerful friends, and I can provide a

100 Dynamic Link Library - code that can be used and reused in a number of programs.


niche market for your graduates that you can’t afford to loose. You need me in your curriculum!’ It was a winning line. Alice’s Exit from the Information Systems Curriculum Despite the fact that most lecturers thought it to be a good product (Rebecca 1997b), Alice is no longer taught in the degree. The disassembly of the Alice network and the subsequent demise of Alice is the fourth important moment in this chapter that I have identified in tracing VB’s entry into the curriculum. Rebecca (1997b) thought that Alice was “fantastic” for getting students to properly understand how a computer worked, but that it just kept getting bigger and more complex as new features were added. Alice then took more and more time to teach. Even back as far as 1992 there had been some disquiet about Alice, with a meeting of the Course Advisory Committee being told of student concern at the Snark101 component of ,QIRUPDWLRQ 6\VWHPV�� (RMIT Department of Business Computing Course Advisory Committee 1992). In like vein, in 1994 Ian (1994) refused to teach Alice as he considered it inappropriate to be teaching at this level of machine and assembly language detail in this subject, even for a week or two. The process of weakening the Alice network began in earnest at about this time, and its relative homogeneity due to its single use made this easier (Grint and Woolgar 1997). If Alice had had more allies, or a greater range of possible uses, it may have survived. The trouble was that the problem Alice had been designed to solve - teaching important concepts about the internal workings of a computer - had now become largely irrelevant to Information Systems students (Ian 1994), and Alice was not able to adapt. It could not possibly adapt and still continue to exist in anything like its present form. It could not accept a translation to another role and so deny the very reason for its existence. It could not accept that having a deep understanding of a computer’s internal workings was unimportant, when this was exactly what it was built to teach. Alice could not adapt and still be true to itself102. It was not until a couple of years later however, that Alice actually lost its place in the curriculum. Rebecca noted that she had liked using Alice as a demonstration tool, but that it became more than just this. Using Alice came to necessitate learning assembly language and Rebecca thought that this was asking too much of the students. She summed up Alice’s demise in this way:

“I think Alice died because it took on a life of its own. I think really what happened was it started to eat into too much time within the subject and instead of it taking up just a few weeks it took from four to six weeks of the semester and I felt that students were writing too much assembler. It’s OK to get them to write a couple of programs, and maybe bring it in and show them a couple of things, but only as a demonstration rather than concentrating on the assembler. The assembler started taking over.” (Rebecca 1997b)

John (1997) agreed that Alice was a good simulator and that it did the job of showing students what goes on inside a computer very well, but suggested that there had been a change in perspective in the course since Alice and its predecessors were designed in the late 1980s.

“I suspect that what James was doing here; talking about the inner workings of computers, whilst it’s good stuff and it’s interesting and it’s well done and the product is fine, increasingly the students don’t see it as being relevant and important today.” (John 1997)

John spoke of an upward movement in the level of abstraction of concepts in the computer industry and those at which an application developer worked, making knowledge of the 101 An earlier version of Alice. 102 This use of ANT language represents another instance of giving agency to non-human actors (Chapter 5).


internal workings of a computer much less relevant than before in an Information Systems degree. He suggested (John 1997) that while it was probably relevant to developers who needed to interact with the services of operating systems and have a detailed understanding of things like file management, directory management, and multi-programming, it was not now relevant in a core subject.

“James had the students writing assembler programs and all sorts of things and they got a very thorough knowledge of it, and of course they bucked. Increasingly the students were complaining. The nature of the complaints were that ‘this is all very well but, I don’t want to do this sort of detail and I don’t think this sort of thing will help me get a job’.” (John 1997)

He also suggested that James, Alice’s designer, must bear some of the guilt in his demand that, whereas in the old course Alice occupied about one third of a single subject, he could now not adequately teach programming concepts with Alice in the new degree in less than a full subject, and would prefer two subjects. John said that the review panel would not accept the idea that a complete subject should be devoted to Alice, and James indicated that he would accept no less. Neither side would compromise and the result was that Alice was not included in the new course.

“The question gets down to this: have we got time to spend a full one of our core subjects on the basic internal operation of memories and registers and that sort of thing in the machine? Or should we spend it on the object paradigm, Java or something at the top end. That’s the conundrum. In the end I’d had enough of this and I said, well I’ve got two choices: it either runs as a full subject and I continue with all these problems - complaints from students and lecturers, or it goes altogether because the compromise hasn’t worked. When you sit in the management chair you can’t persist with problems like this.” (John 1997)

Paul reiterated the arguments against Alice and the reasons for it not continuing to be offered in the degree:

“Alice did what it did very well, but it wasn’t relevant to a BIS103 degree. It could be offered as an elective, but I’ve no hesitation in saying that it wouldn’t run, it wouldn’t get the students. BIS students are not looking for that type of subject, there might be a handful, but there wouldn’t be enough to make a class. If you put up a list of things that should be taught you can’t cover everything so you scrub something, and Alice would have to be one of the things to go.” (Paul 1997b)

Intransigence, some of it unavoidable, in the face of changing circumstances is what caused Alice to be removed from the curriculum. It was Alice’s unwillingness, or inability to undergo a translation to make it more relevant that led to its network quite quickly disassembling and falling apart. Alice’s demise was significant to the future of Visual Basic as in more than one sense they were opposites, one representing a detailed internal view of the computer and the other a visual view at a conceptually much higher level. Had Alice survived as a subject in its own right, John suggested that it may have been harder for Visual Basic to gain a toehold in the course (John 1997). A course with an emphasis in the direction of detailed knowledge of the internal workings of a computer would be very different to one concentrating on issues of systems integration and visual interface design. The course could not go in both directions (John 1997) and Alice lost out to Visual Basic.

103 Business Information Systems.


The Failure of Cobol to Undergo a Revival Although offered at Phillip Institute in the early 1990s and at RMIT Coburg campus in 1995, the Cobol programming elective has not run in RMIT’s City campus for several years. It has not run at all since the merger and John explained Cobol’s failure to stir students’ imagination to the extent that they would choose it as an elective, in this way:

“I can only assume that Cobol has had such a bad press over so many years, in the popular press, and that includes the popular journals and so on. If ever it is referred to it’s as the butt of a joke. Now I would suspect that most students who read this stuff would not have a clue what Cobol is, and that it is the basis of probably 70-80 percent of the world’s software, they wouldn’t know that. All they think is that it’s passé, ancient, a piece of history that they don’t need to know about and therefore they bring that prejudice to their subject selection.” (John 1997)

In an article in Computerworld, Goff (1997) describes how Information Systems curricula at the University of Texas and the University of Minnesota (Minneapolis) have moved away from mainframe-based languages like Cobol to languages like C++. He reports that students at these universities have reacted favourably to the change, but notes that this trend is bemoaned by industry representatives. Rebecca (1997b) agreed that the students don’t see any need to learn Cobol and suggested that this may be related to Cobol’s main reason for existence: the creation of reports.

“Really it was a very good language for solving business problems, I mean that’s what it was designed to do - report writing was its major thing. But now you have all the GUI stuff where you can just grab a few things and say OK that’s it, that’s my report. You don’t need to do all that report programming any more, and so students don’t think they need Cobol.” (Rebecca 1997b)

Cobol’s main supporter at PIT, Brian, resigned just before the merger, and RMIT (City) did not really ever have a Cobol champion to speak on its behalf. Cobol’s network of support in the curriculum was thus quite weak. What is particularly strange though, is that students do not choose the Cobol elective despite the fact that it is made clear to them in course briefings that there are plenty of jobs for Cobol programmers (Paul 1997b), particularly in light of the Y2K104 problem. John (1997) doubted that with all the publicity it would be possible for any computing student to have been unaware of the Y2K problem and its implications for the need for Cobol programmers. Neither John, Paul nor Rebecca claimed to fully understand Cobol’s unpopularity in their course. Although interesting, this is another line of investigation that was dropped at this point as none of the actors suggested that it had further relevance to the adoption of Visual Basic. Object-Oriented Languages and Systems Implementation-II Visual Basic had now entered the Information Systems curriculum at RMIT through two different translations. In the first two key moments traced in this chapter I showed how ‘Visual Basic the GUI programming language’ gained a place in an elective, and ‘Visual Basic the language for rapid application development with databases’ in a core programming subject. VB had gained its place in the curriculum but its allies had more work to do to ensure that it remained in that place, as I shall describe in the next chapter. In the other key moments discussed, Pick had survived the merger and had remained in two core programming subjects, but Alice had lost its place in the curriculum. The imminent entry of a new actor: object-oriented technology was, however, about to destabilise each of the programming language networks as I will show in the next chapter.

104 Year-2000. The problem concerned with two-digit dates in the new century.


During the course review there had been a good deal of discussion on the benefits of students learning an object-oriented language and Java and C++ were most often mentioned as the likely languages to choose between. John (1997) said that the panel’s view was that the final programming subject 6\VWHPV ,PSOHPHQWDWLRQ�,, would be the appropriate place to teach an object-oriented programming language. He said that the panel considered arguments that one of the dangers of switching to objects so late in the course was that it may be difficult for students who had learned conventional programming to switch to this new paradigm of working with objects. It had been suggested that perhaps the course should begin with an object-oriented language but, given the need to remain with Pick in the early subjects, this argument was quickly dismissed. As this final subject was not due to be offered to students in its new form until second semester 1998, the choice of programming language was left open, as was the question of how this might affect use of Visual Basic in $SSOLFDWLRQV 'HYHORSPHQW�,,.


Chapter 9

Surviving an Object-Oriented Challenge How Visual Basic continued to maintain its place in the curriculum

By the end of 1996, a year after completion of all stages of the merger, Visual Basic had been introduced in two Information Systems subjects at RMIT. At this time it had been used for two semesters in the *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ elective, and once in the core subject $SSOLFDWLRQV 'HYHORSPHQW�,,. Debate on programming languages, however, did not stop after the course was accredited. The difference was that now this debate had to occur within the framework of RMIT’s system of Educational Quality Assurance105. Paul (1997b) reported that programming languages were often a matter for consideration and heated debate at the degree Course Team meetings. He described one recent meeting where the possibility had been raised of a new elective using ABAP/4, SAP’s programming language106, in the light of possible industry accreditation for students taking this subject. Increasingly, however, the debate was turning towards the value of introducing object-oriented (OO) programming somewhere into the degree. The entry of a new actor, or a translation in the role taken by an actor already present, often destabilises and poses a threat to existing networks (Grint and Woolgar 1997 :54). At this point, we see a new actor: Object-Oriented Technology and its associated network, poised for an attempt to enter the curriculum. The OO actor-network had been growing steadily for several years and its increasing influence and importance was well known to many academics in the Department of Business Computing. If it had been unprepared to face this threat Visual Basic would have been substantially weakened and perhaps even displaced from at least one Information Systems subject. Fortunately for Visual Basic however, the OO threat had been building up for several years and when it eventually came, VB was prepared. Visual Basic had always made use of objects in designing screens, and its whole programming approach was object-based. Early versions however, could make no claim to being object-oriented, a classification that requires conformance to a set of specific rules107. Microsoft had also seen the impending OO threat, and successive versions of VB had been moving nearer and nearer to having full object-oriented status. Visual Basic had responded to the gathering OO menace by itself becoming object-oriented, and in this part of the study I will trace how VB’s place in both Information Systems subjects underwent several translations in response to the OO challenge. These translations neutralised the threat and ensured Visual Basic’s survival in the RMIT curriculum during the period of this research. Object Technology did soon enter the curriculum, but not at VB’s expense. In this chapter I will trace three key moments in VB’s efforts to maintain its place in the curriculum. They begin with Java’s entry to the curriculum in answer to a call for inclusion of object-oriented programming. A decision to use Java108 in the final core programming subject put the focus back onto the use of Visual Basic in the previous subject and tracing the second key moment tells of the response of the VB network to this challenge. The third

105 See Chapter 8 and Appendix A. 106 SAP is a German company that markets Enterprise Resource Planning (ERP) products; ‘standard software

for integrated business solutions’. SAP has its own programming language called ABAP/4. 107 See the Object Technology box on page 168. 108 Java is a newly developed object-oriented programming language. It is described later in the chapter.


moment involved a family dispute between the two subjects using Visual Basic that were having trouble finding a suitable line of demarcation in which subject did what.

Object-Oriented Forces for Change In August 1997 increased debate on the nature of the programming subjects was catalysed by two events. The first event was a Departmental seminar on object-oriented programming by Bob, a Visiting Professor from the United States who had been working in the Department for several weeks. The second was the realisation by a number of the academic staff that the final programming subject, 6\VWHPV ,PSOHPHQWDWLRQ�,,, was due to be taught for the first time the following year (Henry 1997). In the first important moment of the OO challenge traced in this chapter I will describe how Visual Basic’s allies were unable to assign VB a role as an object-oriented programming language, and where Java’s supporters were successful. After Bob’s seminar John raised the issue of teaching different programming paradigms109 with several of the teachers of programming in the department. In line with earlier Course Review Panel discussions John’s idea was to stick with a structured procedural language for the first two programming subjects in the core, but to make the final subject an object-programming one teaching the “object-oriented paradigm” (John 1997). It would then be appropriate for the third programming subject, currently the subject using Visual Basic, to provide an introduction to object concepts. This proposal seemed to have the support of most of the department (Henry 1997).

“There are four subjects in the programming core for all our students to do. The first two should stay as the structured paradigm – procedural language, structured methodology, all that. I think that is fairly stable and it’s actually working quite well now. Regarding the next two, one of them has been introduced110, co-op has intervened, and the final one has never run yet as a compulsory unit.” (John 1997)

Of course the idea of introducing object-oriented programming did not start with the seminar. It would have been almost impossible for anyone to have had any interest or involvement in IT and not to have read about or heard of the rise of OO Technology. To most of the department however, OO Technology was a black-box that they occasionally caught a glimpse inside. What the seminar did was to open the black-box and expose a large number of new entities: OO programming, encapsulation, polymorphism, inheritance, SmallTalk, Eiffel, C++, Java, advantages of using the OO paradigm, an interesting topic to teach, and more potential jobs for RMIT graduates (Henry 1997). It was becoming clear that OO Technology was changing the nature of programming and that it would change the way that programming problems were tackled (John 1997). After re-positioning and redefining the sort of problems that business programming was intended to solve and the way it should solve them, OO Technology began a process of interessement to wean the programming lecturers away from procedural programming towards OO programming.

109 Object oriented programming, procedural programming and event-driven programming. 110 $SSOLFDWLRQV 'HYHORSPHQW�,,


Object Technology

Objects are the basic building blocks of an OO system. In the OO paradigm the real world is viewed as consisting of objects; hence, many real-world applications can be considered OO systems. The notion of an object includes the following: • An object models an entity or thing in the application domain. • An object has a set of attribute values that define its state. • An object has a set of operations it is capable of performing to change its

attribute values. These may cause changes to attribute values of other objects.

• An object has an identity that can be used to uniquely specify it, or to distinguish it from similar objects.

OO programming is based on three concepts: encapsulation, inheritance and polymorphism. Encapsulation means modelling and storing with an object the attributes and the operations the object is capable of performing. Inheritance means that properties (ie attributes and operations) defined for an object class are automatically defined for all of its subclasses. The most promising benefit of inheritance is software reuse, which has been utilised widely by software engineers. Polymorphism means the ability to take more than one form: an attribute may have more than one set of values, and an operation may be implemented by more than one method. Dynamic binding means the method that implements an operation is unknown until runtime. It is an effective mechanism to implement polymorphism.

(Kung, Gao et al. 1995) As described earlier (Chapter 8), the Information Systems degree at RMIT is of four years duration, with a compulsory co-operative education year coming after the first two years of study (RMIT Faculty of Business 1997). 6\VWHPV ,PSOHPHQWDWLRQ�,, was scheduled for the final year of the course but as teaching of the current course had only begun in 1995, by August 1997 this subject had not yet run in its new form. From his discussions within the Department, the Course Advisory Committee, and with anyone else who was interested, John believed that there was now fairly widespread acceptance that object concepts should be included in the core (John 1997). He recognised that one way of doing this, and perhaps the most straightforward way, was to make the final subject in the sequence an object-programming subject. There were other alternative places to consider putting it, but one way or another object concepts had to be brought in, he considered. He decided to make sure that the department was genuinely informed and would come along with his views, and so arranged further seminars and discussions on OO Technology. In his arguments for inclusion of OO Technology John mobilised Information Systems students and the computer industry:

“We owe it to our students to acquaint them with the prevailing and current viewpoints in the industry with something as significant as this. I think that some people might take the view that you adopt ‘house methodology’ and that is what they get. To a point I go along with that, but I think that if something is particularly significant you owe it to your students – they have got to know about it. It’s not a matter of whether we think it is a good idea or a bad idea, it is a fact and they have got to be acquainted with it. So I don’t think there is much question that the students should know about this stuff in the core of the course any more; it’s got to that point.” (John 1997)

For several years now many scholars (including Massey and Douglas (1993), Dukovic and Joyce (1995), Statts (1998) and Hardgrave and Douglas (1998)) have advocated inclusion


of object-oriented concepts in the Information Systems curriculum, and especially the concept of code reuse. Typically they suggested that as OO Technology is gaining such widespread acceptance in the software industry then it is time to give it a place in these courses. Donald thought that the computer industry, the computing press, the Course Advisory Committee and most IS students would agree (Donald 1998). OO Technology was thus supported by academic papers, magazine articles and books advocating its use, and these were used to secure the allegiance of external networks including students and the Course Advisory Committee.

Objects and Re-use

“The recent commercialization of object-oriented software process technologies have been driven by pragmatic desires to increase productivity, shorten cycle times, enhance maintainability and extensibility, and more fully satisfy user requirements. Although an organisation’s transition to OO typically centers on the use of an OO language such as C++ or Smalltalk, other changes are also necessary if expected benefits are to be realized. These changes include new approaches to analysis and design, greater use of iterative/incremental development, and - perhaps most crucial - an increased emphasis on component reuse.” (Fichman and Kemerer 1997).

“Unfortunately, software reuse has proven difficult to achieve. ... In the past ten years, a conjecture has taken hold that says that object technology supports reuse. The studies we examined now show that object technology can successfully support reuse ...” (Rine 1997)

“Object-oriented analysis and design, followed by the use of an object-oriented programming language at the implementation stage, do not, by themselves, guarantee a high level of reuse.” (Jacobson, Griss et al. 1997)

John suggested that only on two issues would there have been any contest on this matter within the department: � Should OO programming be taught in place of, or in addition to, procedural structured

programming? and � If both paradigms are to be taught, in what order should they be presented? John and most members of his department had now accepted that OO Technology needed to be introduced into the curriculum (Henry 1997) but as there was still an ‘unused’ programming subject, this inclusion did not have to be at the expense of procedural programming. Looking at the effect of this debate and the rise of Object Technology in isolation and without consideration of other languages, could lead to too much importance being given to the part played by OO Technology alone. It might appear that the interessement OO Technology alone had set up had been successful to the extent of moving the Department away from sole reliance on the procedural paradigm represented by languages like Pick/BASIC and Cobol and towards its own way of doing things. This would however, be a simplistic view as this change was not due entirely to the efforts of OO Technology. For some years now Visual Basic, with its event-driven approach, had been successfully challenging traditional procedural programming languages in the curriculum111 (John 1997). As a result of VB’s success in this, it had become clear that an Information Systems course could not teach only procedural programming and claim to be meeting the needs of industry and hence its students’ need for jobs (John 1997). Such a course would have had great difficulty in mobilising (McMaster, Vidgen et al. 1997) the

111 See Chapters 6 and 8.


Course Advisory Committee, industry, students and others necessary to getting the course approved and popular. VB had started the re-definition of programming as it related to the Information Systems curriculum at RMIT. It had started re-defining it towards an event-driven rather than procedural approach, and OO Technology was continuing this trend. A further translation of VB to becoming an object-oriented language might later allow it to fill this programming role better still. It should also be noted that neither Visual Basic nor OO programming had succeeded, or even seriously tried, to dislodge procedural programming, and hence Pick/BASIC, from its position in the curriculum. The Pick network was far too resilient to be easily dislodged, as I showed in the last chapter. John pointed out that a decision on where to put object-oriented programming was far from a straightforward one, and that an alternative to the final programming subject would be to introduce it right from the beginning in place of Pick/BASIC. He remarked that some people argued that this would be “cleaner and nicer” (John 1997), and students could then move to the procedural paradigm later in the course. He commented that one argument raised against switching to objects so late in the course was that after studying procedural programming it would be difficult for students to change to objects, but added that if they had to learn both, as he believed they did, then moving from one programming paradigm to the other would be difficult no matter which way you go. Another argument raised against introducing a new language for the final subject was that many lecturers thought that by the time students got to the end of their course they should be “boring really deep” (John 1997) into something that they had already learned, and building on top of that. These people were, in effect, arguing for a translation of either Pick or Visual Basic to fill this role instead of something like Java. So there were now different suggestions coming from two competing networks. Firstly that OO programming should be put at the start of the course in place of the first Pick subject, and that the final subject should teach an extension of either Pick or Visual Basic. Secondly, that OO programming should go at the end of the course and the other languages (especially Pick) stay were they were. A major difficulty in considering the radical approach to the introduction of OO concepts at the beginning of the course was the effect it would have on Pick/BASIC. If Pick was to be introduced later in the course, instead of retaining its current place at the beginning, then it would be very hard to justify giving it the two subjects it now ‘owned’. Anything less than this would mean that Pick’s importance would inevitably be diminished. Such was the strength of Pick’s mobilisation of a large and influential part of the department and the Course Advisory Committee that this option was not even seriously contemplated (John 1997). But to make quite sure, Pick supporters knew that a decision needed to be made quickly to put the teaching of OO concepts at the end of the course and so remove any threat to Pick’s place at the beginning (Paul 1997b). As the general view was that both OO and procedural programming should find a place in the curriculum, putting OO at the end would further entrench procedural programming, and hence Pick/BASIC, in its place in the first two subjects at the start of the course. It was generally accepted (Henry 1997) that the time to introduce OO programming was now, and John’s view was that:

“There was a bit of a window of opportunity to think what we do with respect to the final unit at least, while we have got a chance before it comes on stream compulsorily. Once it does, it will be a big investment in time, and people will be reluctant to be making changes so soon – best to do it now.” (John 1997)

An earlier version of this final programming subject, originally offered in the Coburg degree, had been running as an elective mainly to cater for students still finishing off the


old degree course. This programming subject has been taught by John who described how he had been handling it in this interim period:

“For the last few years we’ve run the final subject as an elective, and I experimented this year by starting out in that subject giving the students a burst on data manipulation language. They get a couple of weeks on this, then I give them a burst on Cobol, putting embedded SQL112 into it. Learning how to embed the SQL becomes an interesting bit of work to do.” (John 1997)

At the Course Advisory Committee in October 1997, Paul and John spoke of the discussions that had been going on within the department, and asked the Committee’s views on the appropriateness of introducing object-oriented programming into the degree. In particular, they asked about the advisability of using Java in the final programming subject (RMIT Department of Business Computing Course Advisory Committee 1997b). The consensus of the Committee was that OO programming, through the use of a language like Java, was quite appropriate as it would ‘make students more marketable’. The supporters of OO Technology had successfully mobilised the Course Advisory Committee in support of including an object-oriented programming subject in the core. The Committee also added their weight to the view that this should be in addition to, and not in place of, procedural programming. Contending Object-Oriented Languages If the final programming subject was to be based on the use of an object-oriented language, two questions now emerged: which language to use for this final subject, and whether Visual Basic was still appropriate in the preceding subject that would then need to introduce object concepts. One possibility was to use Visual Basic for both subjects. Although early versions of VB had been ‘object-based’ and had made considerable use of object concepts, they had not previously been ‘object-oriented’ in the technical sense, but this had begun to change in 1995 with the release of VB4 and continued with the release of VB5 earlier in 1997.

Visual Basic 5.0

Released in March 1997, Visual Basic 5.0 saw the addition of Internet features and a continuation of the move towards complete object-orientation with the ability to create ActiveX controls. Although it can still be argued that, technically, Visual Basic is not a fully Object-Oriented Programming Language (- it is missing some aspects of inheritance (Dukovic and Joyce 1995)) to all practical extents and purposes VB5 can now be considered as object-oriented.

The new version also uses a new Integrated Development Environment (IDE) consistent with those used in Microsoft’s other languages.

(McKelvy, Martinsen et al. 1997; Microsoft 1997)

Despite the fact that the release of VB5 had taken Visual Basic much closer to becoming a fully object-oriented language it was not regarded as a serious contender for 6\VWHPV,PSOHPHQWDWLRQ�,, because it was still largely seen by the industry as event-driven rather than object-oriented (John 1997). There is no reason why a language cannot be both event-driven and object-oriented, as is Delphi, but representations of Visual Basic in the industry press did not show it this way (Fred 1997b). Furthermore, at RMIT proponents of Java

112 SQL (Structured Query Language) commands can be embedded into a programming language so that a

program in Cobol, for example, can interrogate a database.


sought to represent VB as event-driven rather than object-oriented. Another reason for not seriously considering VB was that if it was used in both the later subjects John feared that with Pick/BASIC and Visual Basic as the only core languages, the course “might be seen as being a bit narrow” (John 1997). It is not completely clear what views John is representing here, but probably those of industry and students (Fred 1997b). VB had not done its “sales job” (Paul 1997b) well enough to be able to muster sufficient support to be seriously considered for both subjects. Its allies had been unable to negotiate it a role as an OO language suitable for use in this subject. Visual Basic was not seen by the academic staff as being an object-oriented language (Paul 1997b) and so did not fit the requirements for the final programming subject. The network developing around VB’s object-oriented features had not yet gained enough allies and had not created enough ‘immutable mobiles’ (Latour 1987) to give it a good chance of adoption. Whereas Delphi had always been object-oriented and had also been able to convince programmers to see it as object-oriented, it was not until version 4.0 that Visual Basic had started to move substantially in this direction. By version 5.0, the version that was current in 1997, it could claim a substantial measure of object-orientation. In its earlier forms VB could not even have been considered, but now it could. The VB network had seen the need for Visual Basic to become object-oriented and had made the translation, just in time. In many universities this translation would have been enough. According to a recent survey of university Information Systems courses in the United States (Hardgrave and Douglas 1998), Visual Basic is the most popular programming language for teaching object-oriented concepts in such courses in that country. But at RMIT in 1997 it was not enough. RMIT was very concerned with industry perceptions and John (1997) suggested that as the Australian computer industry did not yet see Visual Basic as an object-oriented language it could not fill that role in the RMIT curriculum. Judging by general industry responses and the large number of job advertisements for VB programmers, the Australian computer industry is quite satisfied with Visual Basic and uses it extensively (Fred 1997b). They have just not yet discovered its new OO features. Visual Basic’s network had more work to do to convince the industry of the value of VB’s translation to becoming both an event-driven and object-oriented language. Following this line further would have constituted an interesting research direction but as none of the actors suggested that the reason for industry regarding VB in this way had been important to RMIT’s decision, it was not pursued. VB had mounted several ‘programs’ (Latour 1991) in an attempt to counter the ‘anti-programs’ devised by its opponents in the department, but these had not been effective enough to win over sufficient allies to get it adopted in the final programming subject. What was needed in the RMIT Information Systems curriculum, John (1997) suggested, was a language that was able to recruit the necessary allies so that everyone acknowledged it as object-oriented. Debate now boiled down to the serious, ‘pure’ OO languages like SmallTalk and Eiffel, or OO languages with good commercial penetration such as C++ and Java. John noted that SmallTalk and Eiffel both appeared to be:

“… very clean but learnable, good teaching languages, a bit synonymously like Pascal but, on the other hand these languages don’t seem to have a very great commercial penetration, and probably never will. You are back to the old problem in choosing languages; do you pick something because it is very pure but has got zilch market penetration and never will have, or do you choose something that has got a foot in both camps.” (John 1997)

The views of the Department, and of RMIT, on meeting the needs of industry and making use of only ‘real’ programming languages effectively ruled SmallTalk and Eiffel out of consideration. Of the ‘popular OO languages’ the choice thus appeared to be between C++


and Java. Reputed difficulties in teaching C++ (Davey and Tatnall 1995; Bob 1997) meant that Java emerged as the favourite and John mobilised Bob and the US industry to speak in its favour.

“My input, mainly from Bob is that in the US, C++ seems to have become the boom. Everyone wants C++. Bob says he doesn’t like it; it’s not easy to teach, and that’s the impression I get too. It’s also a bit of a hybrid, it’s not pure object at all with add-ons to make it object-like. It is a very complex thing to learn. So there is a feeling that, from an educational point of view, it would be a difficult pill to swallow. Java, on the other hand, has apparently taken some of the nasties out of C++. It appears, from what everyone says, to be the likely flag bearer in object technology in the future. That seems to be the way the trend is going.” (John 1997)

Commercial considerations are important, but so are educational issues (John 1997). Unless the teaching staff considered that a programming language was readily learnable, it would not be adopted into the course (Fred 1997b). It is interesting, however, that this is not just assumed and that it does not go without saying in an educational institution. If it needs even to be mentioned by the Head of Department then clearly there must still be some doubt, at least in the minds of some teaching staff. Some of the teaching staff had mobilised the industry view but not the educational one. Negotiations involved in finding a balance between commercial pressures and educational issues are especially significant in a department of Information Systems in an institution like RMIT (Fred 1997b). John remarked that commercial programming languages tend to emerge as a result of an evolutionary process: people adopt them, they become popular, new features are added, and the result is “a bit of a monster” (John 1997). He again made the point of commercial credibility both with students, who look through the job advertisements, and the university’s industrial sponsors. The languages that these networks constructed are certainly ‘monsters’ in actor-network terms (Law 1991) with their technical associations, commercial associations and educational associations.

“But my concern, sitting with my manager hat on, is that if we adopt SmallTalk there will be students saying ‘Why have you adopted SmallTalk? There are no jobs in SmallTalk. Why didn’t you go with Java or C++?’ I reckon we’d hear that a million times until we’re sick of it. I think that these days, regrettably in some ways, we have got to keep one eye firmly fixed on the marketplace for survival. I suppose we always have in our discipline, we have always tended to lean more towards adopting something that has got commercial credibility. So I think we have got a case there for what is seen to be commercially more acceptable, even if teaching-wise it is a little less acceptable. We hedge a bit more towards the former.” (John 1997)

Java

Java is an object-oriented programming language with a syntax similar to C and C++, only simpler. Because Java is an interpreted language, the typical C or C++ compile-link-load-test-debug cycle is reduced. Java development environments actually let the entire software development cycle take place within a Web browser. Java applications are also arguably more robust than corresponding C or C++ applications, because the Java runtime system manages all memory. The same features that provide robustness also provide safety. Its main attraction, however, is that Java applications are completely portable. Java originated in early 1990 with James Gosling, a software developer at Sun, who was part of a research team investigating advanced software techniques for a wide variety of network devices and embedded systems.

(Hamilton 1996)


At RMIT it is important that students get jobs on graduation (RMIT 1998), and so a programming language in the curriculum must be seen to have ‘commercial credibility’; it must have a substantial number of commercial allies; it must be ‘real’. Without accepting these attributes a programming language would not be permitted to form an association with the RMIT Information Systems curriculum. The influence that RMIT exerts here, partially through the Course Advisory Committee, is considerable and is felt by all academic staff in the department (John 1997). Lack of commercial credibility as an OO language meant that VB had not been able to mount a sufficiently convincing case to be considered for a role in the final programming subject. Visual Basic and Applications Development-II If the final programming subject was to teach object concepts and be based around an object-oriented language then $SSOLFDWLRQV 'HYHORSPHQW�,, would need to take account of this (John 1997); it would need to introduce object concepts and there was some debate whether Visual Basic was the right vehicle to provide this grounding.

“I hear a number of staff saying it is because VB5 is already on course to become more objectified. If VB5 does enable the introduction of these object concepts, which it appears it can, then we see no reason why it should not be continued for the foreseeable future. That seems the most sensible, they have got experience in using it, all the reasons it was there in the first place are still applicable, and if it increasingly enables some sort of focus on objects, or at least getting across those basic concepts adequately, then it will suite the purpose.” (John 1997)

In the second key moment of the OO challenge, I will describe the negotiations undertaken to assign VB a role in the introduction of OO concepts. If $SSOLFDWLRQV 'HYHORSPHQW�,, was to change to use a language other than VB the question was: which language should be chosen? Visual Basic is not the only programming language of its type and its rivals: Borland Delphi, IBM Visual Age and PowerBuilder are also all visual, event-driven languages. Furthermore, Delphi and Visual Age are OO languages as well. Although he himself taught with Visual Basic at Deakin University, Donald remarked:

“OO is becoming all-pervasive, as you say. Another reason to seriously consider Delphi in lieu of VB?” (Donald 1996)

As John (1997) had remarked, if “all the reasons VB was there in the first place are still applicable” why question what was working well? Visual Basic certainly had an established and quite long network on its side but its place in the curriculum, although becoming more durable, was always open to challenge as circumstances changed. The ground upon which VB had entered the curriculum had moved. It now not only had to be different to Pick/BASIC and be able to illustrate event-driven, GUI programming in this subject, it also needed to be able to introduce object-oriented concepts as well. To avoid losing its place in the curriculum to another language Visual Basic had to undergo another translation; it had to become “VB the language to introduce OO programming”. When Visual Basic was first introduced into the Information Systems curriculum at RMIT, as I have shown there was not much debate on whether to introduce Visual Basic or one of the alternatives; VB just seemed, to its proponents, like the obvious choice at the time. Before the move towards objects this choice was not questioned, and VB remained free from serious challenge. Paul suggested that this was because of:

“… inertial mass for starters. You have people with the expertise, you have got textbooks. People have put a fair bit of time into becoming expert at VB, so dropping it and taking


up something else is not something you’d take on lightly. This is probably the biggest point.” (Paul 1997b)

According to Paul, there was often debate in the Course Team meetings about which programming languages should be taught, and Visual Basic and Delphi had recently been discussed. He describes how he himself did a course on Delphi and how a number of lecturers had a look at it, but that although they found it a good language they did not think it was significantly different to Visual Basic to make it worth the trouble to change. It was thought that the features of the two languages were pretty well matched and so changing did not offer any significant advantages (Paul 1997b). VB had attached enough associations by now that to disassemble this network and replace it with one from Delphi would have been very difficult. In addition, Paul and the others were beginning a translation of Delphi so that it would be viewed as being much the same as VB, but not quite so easy to use. With this role Delphi was not in a good position to challenge VB for a place in the curriculum. Another problem Paul saw that would discourage moving to Delphi was in the underlying language being Pascal instead of Basic. This, combined with the good support for VB in the form of expertise and textbooks, meant that there was little reason to change, he suggested. VB was now seen, by its users, to have assembled a considerable number of allies and immutable mobiles to support its use. After Visual Basic had gained its place in the curriculum Paul said he thought it was incumbent upon any challenger to prove itself better so that such a change would be worthwhile (Paul 1997a). The challenger would have to recruit enough allies to destabilise the existing network and put itself in its stead. VB had defined the programming problem for this subject with itself as the solution, and any competitor would need to force a redefinition, but Delphi had not been able to muster sufficient allies who were prepared to desert VB. Had it been an advantage that the underlying language was Pascal and not Basic things may have been different, but this was not the case. Rebecca suggested that the language used in teaching is not as important as the underlying programming concepts, and that once you have learned one language it is not hard to move to another. She supported continued use of VB because, apart from its visual interface and other features, it was also used as the macro language in Excel and Access making it very well known and hence:

“... more ‘out there’ than Delphi which is not as widely used or heard of.” (Rebecca 1997b)

To gain and maintain a place in the Information Systems curriculum at RMIT a programming language must have industry acceptance; it has to be ‘real’ and its supporters must mobilise industry on its behalf (Nespor 1994). Although many people would consider Delphi to be ‘real’, judging by the job advertisements in the newspapers its acceptance in the commercial world was not a fraction of that of Visual Basic (Paul 1997a). Paul agreed that in comparing Delphi and Visual Basic, industry acceptance was something he would consider.

“One of the reasons for going to VB is that is was being demanded by employers. If you look in the newspapers you will see that VB outnumbers Delphi probably about ten to one. So yes that does carry weight, particularly when you are trying to pick between two and there is not much to pick between them otherwise.” (Paul 1997b)

Fred (1998) described how Wally, another business programming lecturer, had recently done a survey of event-driven programming languages as a part of his own studies in Computer Science, and had found that many people he surveyed thought Delphi to be the better product. Importantly, however, he had not felt so strongly about this that he was then


prepared to go around lobbying for change from VB to Delphi in the Information Systems curriculum. He acknowledged VB’s established place and offered no challenge to it. Delphi might perhaps be better, he reasoned, but it was not sufficiently better to justify a change. Delphi had made an ally of Wally, but the role Wally subsequently negotiated for it meant that Delphi did not challenge VB. Fred (1998) assigned Delphi a different role as he disagreed that Delphi was a better product; just a little different. He suggested that many people interested in programming style liked Delphi because it was based on Pascal rather than Basic, and that while this may be significant in a Computer Science course, what mattered in Information Systems was building applications. Fred’s problematisation of business programming had much more to do with easily building a good application than with programming style. In this view VB, which made for easy application development, came out ahead of what Wally saw as Delphi’s more elegant style. In the previous year Fred had looked at Oracle Forms 4.5, Visual Age and X-Windows products but had not found anything ‘more suitable’ in his estimation than VB. His negotiations with these products did not result in any being given a new role in the curriculum.

“So far I haven’t moved because other products don’t seem to have enough advantages to warrant me wanting to move. And Visual Basic, of course, has got major revisions every twelve months or so that mean that if there is a product in the market that is better than it for some reason, VB just absorbs that difference. If there was pressure to move to another language, we’d consider moving; there is no one staunchly defending the VB ground.” (Fred 1997b)

Although it is probably true that no one was “staunchly defending the VB ground” (Fred 1997b) at that time Fred, Paul and Rebecca had been mobilised to speak for and to support Visual Basic. Perhaps none of them was going to stand up and publicly fight for VB, but they did not need to; their continued support in upholding the VB network and keeping it in place were enough. The difficulty for Visual Basic now was that others were trying to re-define the problem to which it was the solution by the introduction of new actors (Grint and Woolgar 1997). OO Technology had attempted this, but the Visual Basic network had anticipated the challenge and had already made translations to VB ready to meet it. Fred also questioned the need for the language used in this subject to be fully object-oriented. He suggested that although it was important for students to come to grips with the concepts of encapsulation, inheritance and polymorphism, the idea of writing reusable code was probably just as important. This redefinition of the requirements for a programming language for this subject open the way for negotiations on the use of VB in this role. Fred said that from his reading and investigation of programming languages, reuse of code and a closer correspondence with reality often do not happen any more in a fully object-oriented language than with loosely coupled programming libraries in other languages like Visual Basic (Fred 1998). Rine (1997) agrees that software reuse has proven difficult to achieve, and Jacobson (1997) remarks that the use of an OO programming language does not guarantee a high level of code reuse. It thus appears that this phenomenon is mirrored in general programming practice:

“The traditional OOP113 vision was, at best, vague on the subject of reuse ... There were two major roadblocks. Most OOP language systems, including C++, lack the means to package and distribute objects effectively in binary form. More subtly, the skills and disciplines needed to build components are often quite different from those needed to use them.” (Udell 1994)

113 Object-Oriented Programming.


Fred suggested that VB’s usefulness in the construction of extensible systems making use of re-useable code (Pountain and Szyperski 1994) represented a significant reason to continue with Visual Basic in this subject. He also pointed out that, despite its lack of full object-orientation, continued use of VB is also strongly supported in the literature (eg Dukovic and Joyce (1995), Hardgrave and Douglas (1998)) and considered quite suitable for introduction of object concepts.

Alternatives to Java

“Does this mean that the software developer of the late ‘90s will be forced to learn Java in order to succeed? Not necessarily. Although Java has certainly captured the industry’s mind-share over the past year, it won’t have a monopoly on this kind of technology. Microsoft is pursuing the same approach with an Internet-enabled version of its Visual Basic and OLE technology; Powersoft is preparing an Internet-enabled version of PowerBuilder; ParcPlace-Digitalk has announced an Internet-enabled version of its Smalltalk environment; and Centura (formerly Gupta) has introduced an Internet-enabled version of its SQL Windows technology, to name just a few.” (Yourdon 1996)

After all this debate and negotiation, in December 1997 the decision to teach the fourth programming subject using Java as the vehicle was finalised, and several lecturers were sent off for three days training in Visual Age for Java at IBM. The role of Java as a language suitable for teaching OO programming was thus confirmed. It was also decided that $SSOLFDWLRQV 'HYHORSPHQW�,, would introduce students to OO concepts using the object-oriented aspects of Visual Basic. Fred was to be the coordinator of $SSOLFDWLRQV 'HYHORSPHQW�,, when it next ran in second semester 1998, and he was given the task of working out how to teach this subject to stress the OO aspects of VB and so act as an introduction to object concepts. This meant a change of role for VB in this subject that would require further negotiations. But just when Visual Basic’s future in the RMIT curriculum seemed secure, another problem became apparent in what is the third and final moment to be considered in this part of the study.

Problems with Using Visual Basic in Two Subjects In 1996 and 1997 both $SSOLFDWLRQV 'HYHORSPHQW�,, and *UDSKLFDO 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ were taught using Visual Basic, and a difficulty had arisen in differentiating what should be taught in each subject. When *UDSKLFDO 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ was originally proposed it was the only VB subject and so needed to start teaching Visual Basic from scratch and show students how to use the VB environment before moving on to general VB programming. It had to do this before getting to the more important issues of graphical-user interface programming. When the fine details of $SSOLFDWLRQV 'HYHORSPHQW�,, were being worked out it was seen that as *8, DQG (YHQW�'ULYHQ was an elective it could not be assumed that students had completed it before tackling $SSOLFDWLRQV 'HYHORSPHQW�,, and so this subject also had to introduce VB from the beginning. The problem was exacerbated because some students took *UDSKLFDO 8VHU�,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ as an elective before taking the core subject $SSOLFDWLRQV 'HYHORSPHQW�,,, while some non-computing students took only the former subject. This meant that one subject could in no way act as a precursor for the other and that both subjects had to be able to handle both VB beginners, and students who had already studied the other subject. VB had become too successful! Rebecca pointed out that:

“If we don’t change $SSOLFDWLRQV 'HYHORSPHQW�,, we will have to change the GUI subject, because there is far too big an overlap between the two subjects and it’s really hard to avoid it. That overlap may be cleaned up if we do a couple of things. One is to change the flavour


of the way we teach VB in $SSV 'HY�,, so that it becomes OO driven – this will change the whole look of the subject from that point of view. The other alternative is to replace VB in one of the subjects.” (Rebecca 1997b)

In this third moment of the OO challenge I will show how Visual Basic was translated into two different forms; one for each of these subjects, and how this final pair of translations led to VB finding a durable place in the curriculum. The decision to have $SSOLFDWLRQV 'HYHORSPHQW�,, introduce object concepts using an OO translation of VB provided a partial solution to this problem. If it approached Visual Basic from an object standpoint this would differentiate this subject from the other, but not sufficiently so on its own. Also it would not solve the problem due to differences in which subject students did first. The other part of the solution, suggested by Fred, was to convert *UDSKLFDO 8VHU ,QWHUIDFHDQG (YHQW�'ULYHQ 3URJUDPPLQJ into a subject to teach ‘Visual Basic for non-programmers’. This would be done by making extensive use of VB’s many different controls; building the system by setting control properties and then using as little programming code as possible. Although this sounds like a contradiction, it is quite possible to produce some useful applications with VB by just assigning properties and using the “odd single line of programming code” (Fred 1998) here and there. This was what was planned for *UDSKLFDO 8VHU�,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ when it was next taught in second semester 1998. It should now not matter if students took this subject before or after the other as they were teaching quite different aspects of visual programming. Here we see Visual Basic undergoing more translations. It had been translated into a ‘programming language for non-programmers’ by Fred’s actions in preparing it for this subject. With this translation Visual Basic can be seen to have appeared in several different forms: as a ‘language for event-driven Windows programming’, a ‘language for creating graphic user-interfaces’, a ‘language for rapid prototyping’, a ‘language for rapid application development with databases’, and a ‘language for non-programmers to create business applications’. It could also be seen as an ‘object-oriented language’ and one that was fun to use. Negotiations by Fred and his colleagues had resulted in VB being assigned different roles in each of these subjects. These translations, summarised in Figure 9.1 below, meant that because of the network of allies they had associated, Visual Basic’s place in the RMIT Information Systems curriculum was now quite secure for the foreseeable future.

Visual Basic 6.0

“New features included in version 6.0 of Visual Basic - the world’s most popular rapid application development (RAD) tool - extend support for the creation of browser-independent Web applications and Dynamic HTML pages. Simpler creation of Web applications is possible with the new WebClass Designer, which provides an easy-to-use object model for the Web server. The new Dynamic HTML Page Designer enables developers to create Internet Explorer 4.0 based applications that combine Dynamic HTML with the performance of Visual Basic.”

(Communique 1998)

Innovation and Change in Inform

ation Systems C

urriculum

page 177

Location

Private consulting job

Phillip Institute

Phillip Institute

PIT (RMIT)

RMIT

RMIT

RMIT

RMIT

Date introduced

Late 1992

Semester 1, 1993

Semester 1, 1994

Semester 2, 1995

Semester 2, 1996

Semester 2, 1998

Semester 2, 1998

Some time in the future

Translation of VB

VB as a language offering screen-drivers for various MS-DOS screens.

VB as a language for rapid prototyping. A visual environment that is fun to use.

VB as a language for event-driven Windows programming.

VB as a language for creating graphic user-interfaces. A programming language that is fun to use.

A language for rapid application development with external databases. A programming language that is fun to use.

VB as an environment for ‘non-programmers’ to create small scale business applications using minimal code.

VB as a language for introducing object-oriented programming.

A language for WWW programming.

VB features of interest in this application

Device independent screen-drivers.

Screen prototyping tool.

Windows programming.

User interface programming. Event-driven programming.

Connection to external databases.

Systems development with minimal code.

Introduction to object-oriented programming.

WWW programming?

Visual Basic version

VB for MS-DOS

VB for MS-DOS

VB 3 (for Windows)

VB 3

VB 4

VB 5

VB 5

VB 6

Area of use

Fred’s discovery of Visual Basic.

%XVLQHVV ,QIRUPDWLRQ6\VWHPV�$

2SHUDWLQJ 6\VWHPV3URJUDPPLQJ

*UDSKLF 8VHU ,QWHUIDFH DQG(YHQW�'ULYHQ 3URJUDPPLQJ

$SSOLFDWLRQV 'HYHORSPHQW�,,

*UDSKLF 8VHU ,QWHUIDFH DQG(YHQW�'ULYHQ 3URJUDPPLQJ(version 2)

$SSOLFDWLRQV 'HYHORSPHQW�,,(version 2)

Possible future developments

Figure 9.1 E

volution and adaptation of Visual B

asic in the IS curriculum


Programming Languages and Future Curriculum Changes Although RMIT’s system of Educational Quality Assurance had little influence in the design of the new Information Systems degree in the mid 1990s, its effect was by now beginning to be felt in the process of on-going curriculum change. Whereas the process of designing the new Information Systems degree pre-dated the full introduction of EQA, by 1996 all curriculum changes were subject to EQA guidelines. This meant that curriculum discussions after about mid-1996 had to be fully documented and all suggestions and criticisms formally taken into account. EQA’s importance as an actor in curriculum innovation was increasing as it took on the role of an ‘obligatory passage point’ (Callon 1986b) for curriculum change. The main venue for these discussions was the degree Course Team meetings and issues relating to OO programming were brought up with increasing frequency in these meetings from early 1997 (Paul 1997a). It was here that VB needed to mount and formalise its arguments against the challenge of OO programming. Whereas under the old arrangement a lecturer wanting to make a change to a subject did need to build some alliances to support this change, under EQA this process was much more formal with more and different people to convince. OO Technology was able to make a convincing case to the Course Team for its inclusion by again re-defining business programming, this time to include object concepts and software re-use. It argued that the computer industry was increasingly requiring programmers with OO skills and, as RMIT understood and acknowledged industry needs, the course had better include some teaching of these skills. The evolution of Visual Basic continued and, anticipating future directions, version 6.0 was released in August 1998. One of the future trends anticipated by VB was an increased need for tools that could be used in programming Web-based applications. In late 1998 RMIT was not making much use of these Web features in VB, but there was discussion on the inclusion of new topics on the building of Web-based systems in either $SSOLFDWLRQV 'HYHORSPHQW�,, or *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ in 1999. Fred (1998) indicated that this matter had been raised a couple of times at recent Course Team meetings. John (1997) commented that after all the debate, programming languages should be left as they are in the curriculum for a while. He suggested that as Visual Basic, and even more so Java, had just been introduced, no further change should be contemplated for a year or two. In relation to Pick/BASIC he suggested that despite the on-going criticisms, it should also be left unchanged for the moment because the subject teams had “put a lot of effort into getting the first two programming subjects running as they want them” (John 1997). And what would replace it? They had been down this track before.

“If we are going to stay with the idea of the first two subjects being a good sound solid introduction to the structured paradigm, what can we replace it with? Some people would say, what about VB? But VB’s opponents would suggest that it has its problems too. I get that feeling, that it is not the best language to be teaching beginners. It’s a hybrid and perhaps is better left where it is. Then again I wouldn’t be a party to chucking out the work people have done on Pick to put in Pascal either. We would have to make staff reinvent the wheel again and learn how to use Pascal; set all our infrastructure up again. Then there is no niche market in a commercial sense for Pascal at all. Is this progress? I doubt it.” (John 1997)

A recent issue, that is only just starting to affect the curriculum at RMIT, relates to potential accreditation of industry-based qualifications from companies like Microsoft, Lotus, Novel and SAP. In a recent press release (ACS 1998), the ACS announced that it was proposing to offer associate membership to IT practitioners who had successfully completed industry-based qualifications such as Novell’s &HUWLILHG 1HW:DUH (QJLQHHU �&1(�, 0LFURVRIW &HUWLILHG 6\VWHPV (QJLQHHU�0&6(�, 0LFURVRIW &HUWLILHG 6ROXWLRQ 'HYHORSHU �0&6'� and &HUWLILHG /RWXV 3URIHVVLRQDO �&/3�.


Competition for students is becoming ever more important in Australian universities and any curriculum change that it is thought will attract extra students tends to be welcomed. Recently Dougherty (1997) predicted that some universities in the United States would soon begin to adapt their courses so that students could end up with a degree and an industry certification like one of those mentioned above114. While nothing as radical as this has yet been proposed at RMIT, a new elective based on the use of SAP115 was recently suggested to the Course Advisory Committee. As SAP is one of the largest independent software houses in the world there are plenty of jobs advertised for IT professionals with knowledge and skills in the use of R/3, ABAP/4 and other SAP products. There have also been a number of papers by IS academics (eg Watson and Schneider 1998) explaining how they use SAP in their courses and advocating its inclusion in the Information Systems curriculum. The Course Advisory Committee minutes (RMIT Department of Business Computing Course Advisory Committee 1997a) however, show that the Committee advised against the development of ‘product based electives’ like this as software products often become out of date by the time students graduate. It is unlikely that the issue of industry certification will go away, and Visual Basic, Java and Pick may soon see another challenge from SAP and its programming language ABAP/4. How they meet this challenge will make another interesting addition to this story and could become the subject of some future research project. In this chapter I have traced the negotiations and alliances that allowed Visual Basic to retain its place in two subjects in the Information Systems curriculum, but that failed to obtain it a place in the final programming subject. In 1999 John is looking for consolidation in the curriculum and intends that in the near future, Course Teams will be asked to focus more precisely on sources of information that they should be considering for change; sources such as model curricula, other university courses, benchmarks, student feedbacks, peer group input and employer comments. Nothing in the computer world remains constant for long however, and this is certainly true of Information Systems curriculum. In this dynamic discipline what is planned at one stage does not always eventuate at a later stage. Stephen put it this way:

“… each semester it’s different because of the nature of the technology.” (Stephen 1997)

114 This was discussed more fully in Chapter 2. 115 SAP is a German company that markets ‘standard software for integrated business solutions’. According to

SAP’s Web site (http://www.sap.com) the idea is that use of SAP R/3 software could link together disparate business functions and ‘help the whole enterprise run more smoothly’. The SAP programming language is called ABAP/4.


Chapter 10

What is Real? The mobilisation of business programming

‘What is REAL?’ asked the Velveteen Rabbit one day, when they were lying side by side near the nursery fender, before Nana came to tidy the room. ‘Does it mean having things that buzz inside you and a stick-out handle?’ (Williams 1922 :14)

One of the questions often asked of a programming language in this research has been whether or not it is a ‘real programming language’, normally meaning ‘is it a language that is used extensively in the computer industry?’. Of the programming languages used in the RMIT Information Systems curriculum in the mid-1990s Cobol, Pick/BASIC and Visual Basic were all considered real by the Information Systems academic staff, but Pascal and Alice never achieved this status (Chapters 7, 8,). Being considered to be a ‘real programming language’ was important at RMIT where catering for industry’s needs was paramount. It was important because it gave legitimacy to the inclusion of this language in the Information Systems curriculum. The idea of a programming language being ‘real’ is a key element in this research as it was commonly used as a device for securing or blocking alliances. How a programming language comes to have this status conferred upon it is the subject of this chapter.

Apples, Mobiles, Trains, Monsters and Velveteen Rabbits The question of whether or not something is ‘real’ has often also been put of computers and other technological entities. The Apple II computer was briefly popular with business in the late 1970s and early 1980s because it allowed users to run VisiCalc - the first spreadsheet program (Sculley and Byrne 1989). Sculley, CEO of Apple during this period, notes that VisiCalc was responsible for “putting the Apple II on many business desks” (Sculley and Byrne 1989 :207) but that when the IBM PC came along with Lotus 1-2-3 in 1983, business dropped the Apple and VisiCalc in favour of the IBM combination. The Apple II was thus never entirely ‘real’, except perhaps in education. It was the spreadsheet program that business wanted, and the Apple II was just a means of delivering this. The IBM PC, on the other hand, quickly moved from the status of an expensive toy used only to play games and run Lotus 1-2-3, to being considered a real and useful machine (Sculley and Byrne 1989). Following the IBM PC’s successful acceptance by business, other microcomputers of the MS-DOS variety were soon also considered real. When the Apple Macintosh was released in 1984 it was a long time before it was used enough by business to eventually be considered real. ‘Is it a real ... ?’ tends to be a question asked by human actors of non-human actors in an attempt to decide how seriously to take them; to decide whether they are worth further investigation and could possibly be of some use. People asked this question, although probably not in these words, of the first mobile phones, of electronic organisers and of other technological innovations they were unsure whether they could find a use for (Franklin 1990 :94-113). It is interesting to note that in respect of a given (non-human) actor the question ‘Is it real?’ is fairly uncontroversial and most people will agree on the answer. Although they would probably use a quite different vocabulary to express it, almost everyone would agree that mobile phones and PCs are now ‘real’, but that videophones and SmartCards are at present not real.


It is probably true to say that initially most new technologies are not considered to be real, and only become real after some time. People need a period in which to evaluate the innovation to see whether or not it might be of use to them and so become something they might think of as real. This raises the question of how something becomes real.

‘Real isn’t how you are made,’ said the Skin Horse. ‘It’s a thing that happens to you. When a child loves you for a long, long time, not just to play with, but REALLY loves you, then you become Real.’ (Williams 1922 :14)

Perhaps, like toys, an item of technology only becomes real when enough people really ‘love’ it, but love it not just to play with. Perhaps it becomes real when they find what they see as a significant use for it. When it is just fun to play with it is still a toy, but when we can use it for something significant that we want to do it is well on the way to becoming real. In actor-network terms, things become real when they have gathered enough intermediaries, enrolled enough allies, and have made enough associations to be seen to be of use by lots of people. Like most new technology, the innovative Parisian transport project known as Aramis (Latour 1996) was not seen as being real at the beginning of its development. In common with other technological projects it could not possibly be real at the beginning as it did not then exist for people to see and to evaluate whether it might be something they could use. The problem was that Aramis never did succeed in becoming real and hence eventually died. Latour describes Aramis as “merely realizable” and “not yet real” (Latour 1996 :85) and notes that Aramis should have taken on reality by degrees.

“But anything can become more real or less real, depending on the continuous chains of translation. It’s essential to continue to generate interest, to seduce, to translate interests. You can never stop becoming more real.” (Latour 1996 :85)

VAL, Aramis’ predecessor, also began as a technological project but went on to be fully implemented in the French city of Lille. Unlike Aramis it did succeed in becoming real, and the people of Lille found it useful.

“VAL, for the people of Lille, marks one extreme of reality: it has become invisible by virtue of its existence. Aramis, for Parisians, marks the other extreme: it has become invisible because of its nonexistence.” (Latour 1996 :76)

Victor Frankenstein (Shelley 1992) never permitted his creation to become real. His revulsion at what he had done, and his refusal to accept the creature or even to give it a name, meant that the creature’s quest to become real and so to be accepted was doomed to failure. But if Frankenstein’s monster never succeeded in becoming real in the world of Shelley’s novel, in many ways it has become real, even if only as a concept, in our world. We have found a use for the analogy of Frankenstein’s monster to describe any ‘unnatural creation’ of modern technology. For instance, in a recent article on human cloning Weiss (1999) raises the spectre of Frankenstein’s monster without any further explanation, confident that this concept is well known to his readers. The concept of creating something that seems to go against the natural order of things (Anderson 1999) is one that is closely linked in our minds with the monster of the novel, and Frankenstein’s monster has become real in that sense. In using the concept of a monster like this, we have made it ‘real’ in much the same way that the term Luddite has become real as a concept used to refer to those people who oppose the increased use of technology. Of course the Luddites (Grint and Woolgar 1997 :56) did actually exist whereas Frankenstein’s monster is only a work of fiction, but in each case it is the concept that is real, and it is real because we have found a good use for it.


Mythology about computer companies has also come to be very ‘real’ to many computer users. The myth that IBM is a bureaucratic company that supplies over-priced hardware and conservative solutions to business problems; the myth that Apple is a small innovative company that produces simple-to-use computers and cares deeply about education; and the myth that all Microsoft is interested in is making money by writing quick-and-dirty software of low quality, probably all have some basis in reality but have been taken far beyond this in the popular imagination. To many people, these myths have become ‘real’ and an accepted part of the way they see the world. They have become real to the extent that they affect the way we relate to these companies and whether we willingly purchase and use their products. These concepts have shaped our view of the world of technology and computing in much the same way that concepts of Frankenstein’s monster and the Luddites have shaped this view. There are thus many different ways that something can be seen as real, and different ways that this can affect what we do, but once something becomes real it will remain real providing that the allies who made it real remain loyal.

‘The Boy’s Uncle made me Real,’ the Skin Horse said. ‘That was a great many years ago; but once you are Real you can’t become unreal again. It lasts for always.’ (Williams 1922 :15)

Real Programming Languages Whether or not a programming language is considered to be ‘real’ within the Information Systems community is generally related to its use in industry and in commerce. Cobol and Fortran are considered real because they have long been used, and indeed relied upon, in commerce and science respectively. Pascal, with its academic origins and quite small user-base in business has never been thought of as real (Juliff 1992). Basic, which was invented over thirty years ago as a simple teaching language, has had great difficulty shaking off its unstructured, ‘quick-and-dirty’ image, and its image as a language for beginners in programming. Although never seriously used as a mainframe programming language, the growth in respectability of the microcomputer in the 1980s contributed to making Basic, and later Visual Basic, the ‘real programming languages’ they are seen as being today. Not all computer professionals like Visual Basic, but few would challenge its reality. In actor-network terms, what matters is the length of the network, its allies, and the intermediaries it is able to marshal on its behalf. VB’s network was now long; it had attracted many allies and was able to make use of many intermediaries. One of the first tools by which computer professionals defined themselves was the use of programming languages. But to be considered a computer professional it could not be just any programming language that you used; you had to use a ‘real’ programming language (Maynard 1990; Juliff 1992) or else you were seen as just a hobbyist playing with a toy. In similar vein, the operating system you worked with was another way of determining whether you were a ‘real’ computer professional. Apple II DOS was definitely not considered real whereas CP/M and Unix were. At one extreme some would also not consider MS-DOS, Windows 98 or Mac OS as real either; to them it had to be something like MVS or OS/400. Franklin puts it this way:

“The historical process of defining a group by their agreed practice and by their tools is a powerful one.” (Franklin 1990 :16)

Cobol was certainly real when used at Phillip Institute and RMIT; it had been considered real for many years. Pascal was seen only to be used in education, despite the fact that it did


have some practical uses, and thus was not considered real. This, however, did not prevent the use of Pascal for several years at Phillip Institute although there was always some suspicion that this was not the right thing to do in an Institute of Technology. While the more traditional universities might take the view that, although a given language was not used much in business, if it was a ‘good teaching language’ they would ‘use it anyway’ (Juliff 1992), this view was much harder to sustain in an Institute of Technology where applied knowledge was considered much more important (Maynard 1990). Educational institutions have always had to suffer the criticism of being detached from the ‘real world’, and have attempted to address this criticism in two different ways. In relation to Information Technology, the more traditional universities have often taken the line that it is their purpose to educate, not train, and so it does not matter if the programming languages they teach with are not those used in industry as long as they are appropriate for teaching programming. Institutions like RMIT and other Institutes of Technology, on the other hand, have generally attempted to make their educational offerings more relevant to commerce and industry and so be seen to cater for the ‘real world’ in this way. These institutions have defined their educational context as containing the real and relevant (Seddon 1995 :402) but to do this they have considered it necessary to use only ‘real’ programming languages and other real ‘industry standard’ technology where this has been possible. In doing so they have defined Information Systems curriculum as necessarily practical and proceeded to use teaching practices to reinforce this definition. As Seddon says:

“... this ‘reality’ is not only the tangible, obdurate, empirical world of everyday experience; it is also discursively constituted through practices that re-present and therefore, define, the ‘real’ and what is ‘relevant’.” (Seddon 1995 :401)

Can something, such as a programming language, be real in education only, even if it is not used in commerce and industry? It may be possible to argue that this is the case in some situations, but with the definition accepted by computer professionals and by academics at institutions like RMIT, there is only one version of real: it must be extensively used in business. Although conceding that at primary and secondary school the situation is different and that something might be seen as real in this context, arguing this in Australia at a University of Technology would be very difficult. Pick was considered real from the beginning of its use at RMIT; otherwise it would not have been chosen. It was considered real because it was used in business and because it provided a niche market for RMIT graduates (Chapter 7). Another reason that was relevant at the time, although not now, was that Pick initially needed a minicomputer rather than a microcomputer to run on. At a time when the microcomputer was still fighting for respectability against these larger machines this helped make Pick seem more real (Stephen 1997). It could now be asked when Visual Basic became real. The answer is that initially most people considered VB as just a toy; good fun to play with in displaying pretty fonts and graphics on the screen, but that was all. It was probably the inclusion of the Data Control in version 3.0 which led to it becoming real. In allowing easy access to remote databases the Data Control meant that everyone could easily see how VB could be used to good effect in business. The rapid growth of job advertisements for VB programmers that appeared in the newspapers, along with Microsoft’s adoption of Visual Basic for Applications (VBA) as the standard macro language for all its Office application software (Chapter 6, 8) clinched the deal and Visual Basic became real in about 1994. One thing that made VB’s bid for reality somewhat harder though, was that it was only a microcomputer language, not available for mini or mainframe computers, and also that it


was a ‘proprietary language’ developed and sold only by Microsoft. Most other real programming languages were available to run on different platforms and were generic and so available from several different vendors. Not every real language was generic however, as Pick/BASIC was also a propriety language which made any arguments against Visual Basic on this score very hard to sustain at RMIT. When first introduced by Fred at RMIT in *UDSKLFDO 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ there was still some doubt about whether or not Visual Basic was real, but VB was soon able to prove itself and to prove that it was both used in industry and also had some value in showing students database and other computing concepts that were difficult to show in other ways. The consensus then emerged that VB was real, or at least almost real.

Using ‘Real’ to Mobilise the Computer Industry RMIT academic staff did not invent the concept of a programming language being either real or not real; it had been used by programmers and other computer professionals for many years. It was, however, through the concept of specifying whether a programming language was real that RMIT was able to speak on behalf of computer programmers and the computer industry. It was by their use of the concept of ‘real programming languages’ that RMIT Information Systems academics and the Course Advisory Committee were able to ‘mobilise business programming’ (Callon 1986b :196; Nespor 1994 :14-18) and Information Systems. The concept of ‘real’ was used to enlarge the RMIT Information Systems network by the addition of many other ‘absent entities’ (McMaster, Vidgen et al. 1997) in the form of business programmers and other computing professionals who the Information Systems Department would now claim to represent. It gave the IS academics the opportunity to effectively bring professional programmers into their classrooms to endorse RMIT’s choice of programming language (Nespor 1994). It was used as one means of showing the world that RMIT had the authority and the right to speak on behalf of, and to represent the view of the Information Systems community. Now it was not just RMIT Information Systems academic staff who were saying that this programming language was appropriate to teach for business students, and that one inappropriate. It was now also the much enlarged network of business programmers and other computer professionals who were also used to support this view. The mobilisation of business programming added many new actors to the RMIT Information Systems network making it much longer. It also enhanced its ability to convince students and others that what it said about business programming should be taken seriously. Nespor (1994) writes of how physical space was used by an American university to mobilise the disciplines and communities of Physics and Management, but in quite different ways. He describes how the physical spaces of the buildings where these students attended lectures and worked on their studies acted as boundaries to regulate the access of outsiders and also to represent the different worlds into which these students would move after graduation. In this mobilisation the ‘spatially compressing’ (Nespor 1994 :110) ideology of the discipline was used to bring physics students to see that they could reduce the world to ‘mathematised terms’ (Nespor 1994 :110) in their future roles in academic physics. In Management, on the other hand, a representation of ‘corporate space’ acted to mobilise ‘social practice’ (Nespor 1994 :110) and to lead students into the corporate world that they would enter after graduation. Mobilisation of Information Systems at RMIT has elements of each of these examples. The mobilisation of business programming in which students were led to see themselves as future members of a profession who use particular tools, and who subscribe to certain values and traditions, has some similarity to the mobilisation of the physics students Nespor


describes. Other (non-programming) elements of the curriculum however, are designed to prepare students for entry into the business world, and so acted to mobilise this world in the much same way as for the management students in Nespor’s study. For its students and its courses, mobilisation of business programming at RMIT represented not only the setting up of barriers to the entry of what were considered by RMIT to be unacceptable programming languages, but also a mechanism for locking the students into the Information Systems actor-network by showing them only languages and programming practices used in the computer industry. This had the effect of “translating students into mobile practitioners of a discipline” (Nespor 1994 :14) so furthering RMIT’s mission of attending to the needs and practices of industry and commerce.

Gaining a Real Place in the Curriculum Visual Basic is now quite real in the Information Systems curriculum at RMIT but is was not seen as real when Fred first experimented with it at Phillip. At that stage it had few allies and had not yet managed to attach any intermediaries to further its network. How does something gain a ‘real place’ in the curriculum? From the research described in this study I contend that Visual Basic became real in the RMIT Information Systems curriculum when the consensus among the academic staff was that it occupied a useful place and fitted in well with RMIT’s educational mission of preparing its students to cater for industry needs. It became real when it had enrolled enough of the academic staff in its support, and mobilised them to speak on its behalf. Visual Basic took its first small step to becoming real in the curriculum when Fred formally implemented it as a serious screen prototyping tool in %XVLQHVV ,QIRUPDWLRQ 6\VWHPV�$ by incorporating its use as part of student assessment. This assessment was able to act as an ‘intermediary’(Callon 1991 :134) that added to the durability of VB’s network. VB took another step, acquired more intermediaries, and gained more allies when Fred also incorporated it into 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ and a giant leap when it was given its own subject in *UDSKLFDO 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ 3URJUDPPLQJ. VB was now almost at the point of mobilising business programming at RMIT. The final step to Visual Basic becoming real in the curriculum however, was its adoption as the programming language used in $SSOLFDWLRQV'HYHORSPHQW�,,; a core computing subject in the degree. This last adoption put VB in a similar position to Pick/BASIC as an indispensable part of the Information Systems curriculum. Visual Basic had now acquired a network that would be very difficult to disassemble, making VB very hard to challenge. Visual Basic’s progress towards becoming real in the curriculum could be pictured as follows:

Figure 10.1 Becoming ‘real’ in the curriculum

Industry

VB released onto market

‘Played with’ by programmers

Used extensively in computer industry

Becomes a ‘real programming language’

Education Language ‘discovered’ by an academic

‘Played with’ in the curriculum

Gains a formal place in the curriculum

Becomes ‘real in the curriculum’


A ‘real’ place in the curriculum is however, not guaranteed forever and Visual Basic needed the support of all its allies to keep this place, under challenge from object-oriented languages.

“Nothing becomes real to the point of not needing a network in which to upkeep its existence.” (Latour 1991 :118)

That Visual Basic was able to retain its place is due to the loyalty of its allies and also to its own ability to renegotiate roles and adapt to the changing world of business programming. Visual Basic had no intention of risking its status as a ‘real programming language’ or of loosing its place as real in the RMIT Information Systems curriculum.


Chapter 11

Conclusion The progress of an Information Systems curriculum innovation

In this study I have described how Visual Basic was introduced into the RMIT Information Systems curriculum and how it has retained an important place there despite some serious challenges. The study showed that Information Systems curriculum is heterogeneous, consisting of the contributions of both human and non-human actors, and that a consideration of this heterogeneity is important to an understanding of IS curriculum innovation. Without a consideration of entities like PC laboratories, programming languages, Course Advisory Committees, the computer industry and niche markets for graduating students, as well as Information Systems academics, only a limited view of the innovation process could have been obtained. I found that the innovation being investigated originated from a source external to the university, and that its subsequent path into the curriculum could not have been predicted. It was influenced by the merger between RMIT and PIT, and by the need for any programming language used in the RMIT curriculum to be seen as being a ‘real’ programming language. My study detailed the negotiations, and the assignment of roles to both human and non-human actors, that resulted in the innovation being adopted. It showed that the way that the adoption of Visual Basic into the curriculum was supported relied on these negotiations and alliances, and that VB retained its place only because frequent renegotiation and network formation took place. Consideration of these negotiations, alliances and role assignments shows just how tenuous IS curriculum innovation is; a slight variation and the result could have been quite different. I found that an actor-network approach involving considerations of how Visual Basic was translated to fill different roles in the curriculum provided a useful way of tracing the progress of the innovation. Research of this kind has not previously been reported in the literature, so making this study significant. In the study I have shown how, over several years, Visual Basic was translated by Fred and others to fill various roles in the curriculum. The details of how the innovation occurred were subjected to an actor-network analysis as eleven key moments, identified in conjunction with the actors themselves as being crucial to the formation of the actor-networks of interest to the study. These key moments were:

• How Fred found out about Visual Basic while at Phillip Institute. • How Fred became convinced that VB’s very different style of programming should

be considered, investigated and eventually adopted in his teaching. • The discovery, translation and adoption of Pick/BASIC at RMIT before the merger. • The design, building and use of the Alice computer simulator at RMIT prior to the

merger, to introduce students to machine-level computing concepts. • VB’s introduction, during the merger, in a new elective designed especially for it. • Visual Basic’s adoption in a core programming subject in the new RMIT degree. • Pick’s successful efforts at warding off attempts to displace it from the curriculum. • Alice’s unsuccessful struggle for survival. • Java’s entry into the curriculum as an object-oriented programming language. • The response of the Visual Basic network to the introduction of Java.


• A line of demarcation dispute between the two subjects using Visual Basic, that led to a more durable place for VB in the curriculum.

This is a study in innovation translation in which ‘Visual Basic: the graphical, event-driven programming language developed by Microsoft’ is translated, by Fred and his colleagues, into a number of different forms to enable its use in various situations. In each case the requirements were for different aspects of VB, and the concept of innovation translation assists in showing how these adoptions were able to be made. For instance, when building their small commercial programming project in the early 1990s, Fred and George were not, at first, interested in all the event-driven aspects of VB, only its ability to make MS-DOS graphics look the same on different screens. Their translation of VB to become ‘Visual Basic: the language offering screen-drivers for various MS-DOS screens’ made it suitable for use in this situation. For use in the PIT Information Systems curriculum VB’s ability to make use of MS-DOS screen-drivers for different types of screen was irrelevant as all the PCs in the student laboratories were of the same type. When it came to introducing Visual Basic in %XVLQHVV,QIRUPDWLRQ 6\VWHPV�$, which was teaching systems analysis and design, and not programming, the event-driven aspects of Visual Basic were also irrelevant. It was Fred’s translation of VB to become ‘Visual Basic: the language for rapid screen prototyping’ that facilitated its entry into the curriculum in this subject. For use in 2SHUDWLQJ 6\VWHPV 3URJUDPPLQJ Fred needed the programming aspects of VB rather than its screen design features, and his translation of VB as ‘Visual Basic: the language for Windows operating systems programming’ was the language chosen to fill this role. During the period of the merger with RMIT, Fred developed *UDSKLF 8VHU ,QWHUIDFH DQG (YHQW�'ULYHQ3URJUDPPLQJ using another translation of VB as ‘Visual Basic: the GUI programming language’. Fred also spoke of a translation of the Visual Basic he personally liked and found exciting as ‘Visual Basic: a programming language that was fun to use’. The core programming subject: $SSOLFDWLRQV 'HYHORSPHQW�,, required a Windows programming language that was quite different to Pick/BASIC, and was also able to interact with database systems such as Oracle. VB’s translation to become ‘Visual Basic: the language for rapid application development with external databases’ was the language adopted. With the introduction of object-oriented programming in Java in the final core programming subject, VB survived to retain its place in $SSOLFDWLRQV 'HYHORSPHQW�,, by its translation to also become ‘Visual Basic: the language to introduce OO programming’. After the dispute between those taking the two subjects in which VB was used at RMIT, the translation that created ‘Visual Basic: the programming environment for non-programmers to create business applications using minimal code’ allowed VB to retain a place in both subjects during the period of the study. Fred (1998) has suggested, however, that in 2000 VB may have to undergo yet another translation to become ‘Visual Basic: a language for WWW programming’ in order to remain the programming language for use in $SSOLFDWLRQV'HYHORSPHQW�,,. Although each of these translations involved Fred and his colleagues utilising some aspects of Visual Basic rather than others, they can more usefully be seen as different programming languages consisting of different translations of Visual Basic in which different alliances had been negotiated. It was not just Visual Basic, however, that underwent a series of translations like this as Pick/BASIC retained its place in the curriculum by translating from ‘the Pick operating


system’, to ‘Pick under Unix’, and finally to ‘Pick on a PC’. Also, in innovation translation terms, Alice’s removal from the curriculum could be seen as due to a failure by James to recruit sufficient allies to make the translation of Alice into a new form that was more suitable for the changed circumstances in which it found itself in the mid 1990s.

Innovation Translation and Innovation Diffusion While it would have been possible to use a diffusion model to investigate the adoption of Visual Basic at RMIT, this approach would have placed more emphasis on supposedly in-built characteristics of both Visual Basic and the human actors than has been the case with the innovation translation approach used in this study. A diffusion approach would have investigated Visual Basic’s visual environment and considered whether this offered programmers some relative advantage (Rogers 1995) over the text-based one commonly used. Similarly it would have examined this environment’s compatibility with traditional programming environments like those used at the time, its complexity, its trialability and its observability (Rogers 1995). In each case the researcher would have attempted to determine whether Visual Basic’s characteristics would have been likely to aid or discourage adoption in the RMIT Information Systems curriculum. A significant difficulty that would have been encountered with an innovation diffusion approach, however, is how to judge whether a given characteristic of Visual Basic would have enhanced or reduced its likelihood of adoption into the RMIT curriculum; through whose eyes should the researcher make this judgement? An obvious answer to this question, given the acknowledgment that it cannot be absolute, is to judge through Fred’s eyes as he was seen as the change agent (Rogers 1995). But Fred was not alone in being interested by Visual Basic, enthusing about it to his colleagues and students, and playing a part in its adoption and continued use. Perhaps the researcher should also attempt a judgement of the advantages of VB’s features towards adoption through Fred’s, Paul’s and Rebecca’s eyes; if the same view could be obtained from each. But then the researcher should probably also consider John and the Course Advisory Committee. As the group to solicit views from becomes larger and larger, the situation begins to look more like a network of allies assembled by Visual Basic and by Fred, and less like something that can easily be explained using a diffusion model. Of course Visual Basic does have attributes like its drag and drop interface, its use of objects and its data control, but whereas innovation diffusion sees these as important in themselves, a translation approach sees them only as significant in so far as other actors such as Fred, Paul, Rebecca, John, and the Course Advisory Committee relate to them, are interested by them, negotiate roles for and with them, appropriate them, and adapt them to suit their own needs and the needs of the Information Systems curriculum. Visual Basic can be considered to have many attributes, but the issue then for an innovation diffusion approach is how to judge which of these attributes were significant in explaining whether or not it was adopted to fill a specific role in the curriculum. Actor-network theory contends that it is the actors themselves that make this choice, and that any a priori determinations on their behalf have no validity. For instance, in deciding on the adoption of Visual Basic for their private consulting job, out of all VB’s attributes and new possibilities it was only one specific characteristic of the language that interested Fred and George and that they considered significant for the job in hand: its device-independent screen-drivers. Apart from its similarity to QuickBasic, VB’s other attributes were irrelevant to them in making their adoption decision. Likewise, in choosing Visual Basic to illustrate screen prototyping in ,QIRUPDWLRQ 6\VWHPV�$, out of all the attributes given to VB by its designers, only a few were relevant to the adoption decision. The same was the case for each of VB’s other


uses in the RMIT Information Systems curriculum as the translations of VB for each of these purposes were in the hands of Fred and the other actors involved. This study has shown that in the adoption of Visual Basic into the Information Systems curriculum at RMIT, rather than any pre-determined attributes or essences, what was important were negotiations and alliances by various human and non-human actors that led to various translations of VB into new forms to fill specific curriculum roles. Innovation translation sees the importance of these attributes not as essences, but as the result of associations due to the construction of networks, and this study has shown the value of this approach. I have shown the advantages of an approach to innovation that details the construction of networks and alliances to support and embed the changes in order to make them durable. Innovation diffusion and innovation translation are based on quite different philosophies, one stressing the properties of the innovation and the change agent and routed in essentialism, and the other emphasising negotiations and network formation. I conclude that in a study like this of technological innovation in a university curriculum, an innovation translation approach has much to offer in providing a useful explanation of the process of change.

IS Curriculum Innovation: External Ideas and Serendipity It is clear from the results of the study that contrary to Hefferlin’s (1969) contention that curriculum change in higher education results mainly from the diffusion of educational ideas from one university to another, the curriculum innovation described here cannot be attributed to copying what was done elsewhere. On the contrary, and more in line with the positions taken by Busch (1997) and also by Stark and Lattuca (1997), external influences, particularly in the form of commercial consultancies undertaken by the academics involved, played a significant part. A striking thing about the introduction and use of Visual Basic in the Information Systems curriculum at RMIT is the extent to which it illustrates a process that appears fortuitous rather than well thought out or planned in advance. No investigation of the curricula of other similar universities, or of model curriculum documents, could have predicted the direction taken by the innovation. This suggests that, given all the different actors, alliances and interests involved, any planned or co-ordinated IS curriculum change will be quite difficult to achieve, and that model curricula are, at best, intermediaries that may indicate a likely direction for the change. Research, development and diffusion models (Havelock 1971; Nordvall 1982) which posit a rational and orderly transition from research and development to diffusion and ultimately adoption can be seen to be completely unsuited to explaining curriculum innovations such as RMIT’s adoption of Visual Basic in its Information Systems curriculum. Fred’s discovery of VB was not directly associated with his teaching at Phillip Institute; it resulted from his son’s advice about solving a problem concerned with graphics display on different types of computer screens that they had encountered in a private consulting job (Chapter 6). Fred’s use of Visual Basic, in place of QuickBasic that they had originally planned to use for this job, began as the pragmatic solution to the screen problem and not as the result of a search for a new approach to programming. At this stage, VB had only interested Fred in its ability to solve this specific problem by offering a set of in-built screen-drivers, and not in any possibilities it may have offered as a replacement for QuickBasic as his preferred programming language in teaching.


None of this was the result of a well thought out plan on Fred’s part. Had Fred not discovered VB for MS-DOS when he did as an aspect of the consulting job, then the path of Visual Basic into the Information Systems curriculum at RMIT would, at least, have been different. One can only speculate on whether Fred might have discovered Visual Basic in some other way or whether someone else at RMIT, perhaps Paul or Rebecca, might have first learned about it. Perhaps VB would not have entered the curriculum at all. The only thing that can be said for certain is that this curriculum innovation would not have happened in the same way had Fred not discovered Visual Basic when, and how, he did. The subsequent path of VB’s adoption into the curriculum, spurred on by the entry of a number of new human and non-human actors during the merger, was also one that exhibits no characteristics of careful planning or orderly diffusion. It can better be related to successful and unsuccessful attempts by VB, and by Fred, to build alliances to support the use of the Visual Basic programming environment. In a similar way, Stephen had discovered Pick and Pick/BASIC at RMIT because of a trade union’s preference for a computer system using ergonomic terminals (Chapter 7) and not because the Pick system was inherently better than the other possibilities offered, or because he went out to look for a different programming environment to use in teaching his students. Like Fred, he then experimented with using Pick in his teaching before becoming convinced of its value as a business programming environment and building it into several subjects in the Information Systems curriculum. Had the trade union’s preferences been different or the supplier of the Pick system offered different terminals, the outcome may have been different. Pick’s adoption at RMIT hung on a thread that had little to do with Information Systems curriculum. Things could easily have been otherwise and a different language could well have been adopted at that time. Development of Alice, on the other hand, followed a path that was a good deal more planned (Chapter 7). James had a fair idea right from the start of what he was trying to create and proceeded to do so in stages, but only after negotiations with students and academic staff confirmed that the innovation was likely to succeed. It was not until after Alice was quite well established in the curriculum that these negotiations finally broke down during the merger with Phillip Institute and Alice lost its way in the changing situation of advances in computing technology and their affect on what students ‘needed’ to know about computers. The issue of external influences on Information Systems curriculum innovation raises questions of whether IS academics should be more strongly encouraged to engage in external consulting activities. This study has produced evidence that such activities can provide a significant source of ideas that may result in curriculum innovation, and can also assist an applied discipline like Information Systems to remain in contact with industry and commerce. There is little in the IS curriculum literature to indicate that this factor has been given due credit.

Research Contributions of this Study As I outlined in the second chapter, there is a considerable gap in the Information Systems curriculum literature when it comes to research on how IS curriculum innovation actually takes place. It is to this gap that my research has been directed. In this study I have attempted to redress the shortcoming in the published literature by describing and analysing in detail the process by which one particular curriculum innovation took place. I have described this innovation in actor-network terms, as this approach offered a unique way of coming to grips with the socio-technical nature of IS curriculum innovation. By


giving due and impartial consideration to the contributions of both human and non-human actors it has been possible to avoid privileging one set of actors over the other. Some of those writing on IS curriculum innovation speak of the inevitability of technological change, and consider IS curriculum to be technologically driven. This study has shown such views to be simplistic at best. One difficulty I did experience in reporting my findings, however, was how to give an appropriate voice to the non-human actors. As far as I am aware, no one has attempted to do so before in a setting like this and, at times, I had to struggle for an adequate way of representing the contributions of the non-humans. Ensuring that the viewpoints of these actors were faithfully represented proved to be quite difficult. I attempted impartiality towards the non-humans by asking humans about them and by having other actors speak on their behalf, but finding the language to express this did present problems. Despite these difficulties, however, the process of curriculum innovation, at least in the example studied, has been shown to be complex and unpredictable, and to depend on the contributions of both human and non-human actors. The use of innovation translation has allowed the series of negotiations and compromises between all the human and non-human actors involved to be made apparent, signalling the strength of an actor-network approach.

Possibilities for Further Research in this Area Viewing curriculum innovation in terms of a translation model also offers advantages in highlighting the different problematisations of IS curriculum made by different actors, so making explicit the relationship between these actors. It shows not just how human actors problematise the curriculum, but also how technology and other non-human actors can do this in different ways. The findings of this research suggest that in investigating curriculum innovation in an area such as Information Systems, which necessitates the study of rapidly changing technology, it can be useful to adopt an innovation translation approach so giving a voice to the technology itself. Even within the discipline of Information Systems there are many other recent examples of curriculum innovation which involve technological change. Innovations such as the recent move towards object-oriented programming and the increasing interest in the creation of World Wide Web applications in many Information Systems curricula may also lend themselves to investigation using actor-network theory. Outside the discipline of Information Systems, research into innovation in other curriculum areas involving technological change may also benefit from the use of an innovation translation approach, and this should be further investigated. A question then arises on whether this approach is suited only to situations involving technological innovations rather than to ‘idea-only’ (Rogers 1995) innovations of other types. This topic also opens up another interesting research direction that would probably involve conducting a number of case studies of innovations, both technological and idea-only, and comparing the use of the innovation theories of diffusion and translation. Perhaps the most interesting extension of this work from my point of view professionally however, lies in the use of actor-network theory to study other business innovations. Innovation is important in all businesses for many reasons not the least of which is in its contribution to profits. There is still plenty of scope for the study of innovation in business, particularly through the application of innovation translation. This is likely to be a fruitful research direction as most studies in this area are now based only on use of an innovation diffusion model. The possibilities here are endless.


Bibliography Abrahamson, E. and Rosenkopf, L. (1993). ‘Institutional and Competitive Bandwagons:

Using Mathematical Modeling as a Tool to Explore Innovation Diffusion’. Academy of Management Review (18): 487-517.

Abrahamson, E. and Rosenkopf, L. (1997). ‘Social Network Effects on the Extent of Innovation Diffusion: a Computer Simulation’. Organizational Science 8(3): 289-309.

Achterberg, J. S., van Es, G. A. and Heng, M. S. H. (1991). ‘Information Systems Research in the Postmodern Period’. Information Systems Research: Contemporary Approaches and Emergent Traditions. Nissen, H. E., Klein, H. K. and Hirschheim, R. (Eds). Elsevier Science Publications, Amsterdam: 281-294.

ACS (1997). ‘The Core Body of Knowledge for Information Technology Professionals’. Australian Computer Society, http://www.acs.org.au/national/ postpaper/bokpt1.htm, 20 September 1997.

ACS (1998). ‘ACS to Credit Leading Industry-Based Qualifications’. Australian Computer Society, http://www.acs.org.au/news/certify.html, 7 April 1998.

Adams, C. R. and Song, J. H. (1989). ‘Integrating Decision Technologies: Implications for Management Curriculum’. MIS Quarterly June 1989: 199-209.

Adams, T. (1991). ‘MA Colloquium on Business Computing Curriculum’. Deakin University, Geelong.

Agarwal, R., Krudys, G. and Tanniru, M. (1997). ‘Infusing Learning into the Information Systems Organization’. European Journal of Information Systems 6(1): 25-40.

Ahmadi, M. and Brabston, M. (1997). ‘MIS Education: Differences in Academic Practice and Business Managers Expectations’. Journal of Computer Information Systems 38(2): 18-25.

Akrich, M. (1992). ‘The De-scription of Technical Objects’. Shaping Technology/Building Society: studies in sociotechnical change. Bijker, W. E. and Law, J. (Eds). The MIT Press, Cambridge, Ma: 1-14.

Alavi, M. and Carlson, P. (1992). ‘A Review of MIS Research and Disciplinary Development’. Journal of Management Information Systems 8(4): 45-62.

Alexander, S. (1997). ‘Are you Certified to do that?’. InfoWorld 19(32): 91-92. Alter, S. (1996). Information Systems: a Management Perspective. (2nd edition).

Benjamin/Cummins, Menlo Park, CA. Anderson, A. (1999). ‘Beware the F Word, Unless You Know What it Means’. New

Scientist. 20 March 1999: 3. Ang, A. Y. (1992). ‘Australian Information Systems Curricula: A Comparison between the

Views of Universities and TAFE Colleges’. Third Australian Conference on Information Systems, Wollongong, NSW.

Arrington, C. E. and Francis, J. R. (1989). ‘Letting the Chat out of the Bag: Deconstruction, Privilege and Accounting Research’. Accounting, Organizations and Society 17(6): 511-533.

Astley, W. G. (1985). ‘Administrative Science as Socially Constructed Truth’. Administrative Science Quarterly 30(4): 497-513.

Bagert, D. J. (1998). ‘A Model for the Software Engineering Component of a Computer Science Curriculum’. Information and Software Technology 40(4): 195-201.

Baldwin, H. P. J. (1991). ‘Higher Education: Quality and Diversity in the 1990s’. AGPS, Canberra.


Banville, C. (1991). ‘A Study of Legitimacy as a Social Dimension of Organizational Information Systems’. Information Systems Research: Contemporary Approaches and Emergent Traditions. Nissen, H. E., Klein, H. K. and Hirschheim, R. (Eds). Elsevier Science Publications, Amsterdam: 107-129.

Banville, C. and Landry, M. (1989). ‘Can the Field of MIS be Disciplined?’. Communications of the ACM 32(1): 48-60.

Baron, N. S. (1986). Computer Languages, a Guide for the Perplexed. Penguin Books, London.

Baskerville, R. L. and Wood-Harper, T. (1998). ‘Diversity in Information Systems Action Research Methods’. European Journal of Information Systems 7(2): 90-107.

Beck, K. (1994). ‘Patterns and Software Development’. Dr Jobbs Journal (February). Benbasat, I., Goldstein, D. K. and Mead, M. (1987). ‘The Case Study Strategy in Studies of

Information Systems’. MIS Quarterly 11(3): 369-386. Benjamin, J. and Bricknell, L. (1997). Educational Quality Assurance System at RMIT: a

Handbook. RMIT, Melbourne. Bergquist, W. H., Gould, R. H. and Greenberg, E. M. (1981). Designing Undergraduate

Education: A Systematic Guide. Jossey-Bass, San Francisco. Berlyne, D. E. (1962). ‘Uncertainty and Epistemic Curiosity’. British Journal of

Psychology 53: 27-34. Berlyne, D. E. (1965). Structure and Direction in Thinking, New York. Bigum, C. (1998a). ‘Boundaries, Barriers and Borders: Teaching Science in a Wired

World’. Australian Science Teachers Journal 44(1): 13-24. Bigum, C. (1998b). ‘Solutions in Search of Educational Problems: Speaking for Computers

in Schools’. Educational Policy 12(5): 586-596. Bijker, W. E., Hughes, T. P. and Pinch, T. J., Eds. (1987). The Social Construction of

Technological Systems: New Directions in the Sociology and History of Technology. MIT Press, Cambridge, Ma.

Bloom, B. S., Englehart, M. D., Furst, E. J., et al. (1956). Taxonomy of Educational Objectives. Handbook 1: Cognitive Domain. Longmans, Green and Co Ltd, Ann Arbor, Michigan.

Bloomfield, B. P. and Best, A. (1992). ‘Management consultants: systems development, power and the translation of problems’. The Sociological Review 40(3): 533-560.

Bob (1997). ‘Object oriented programming’. Visiting US professor, Melbourne. Bogdan, R. and Biklen, S. K. (1992). Qualitative Research for Education. (2nd edition).

Allyn and Bacon, Needham Heights, MA. Bonnici, J. and Warkentin, M. (1995). ‘Revisited: Fabbri and Mann’s Criticism of the

DPMA Model Curriculum’. Journal of Computer Information Systems 35(3): 96-98. Boomer, G., Lester, N., Onore, C., et al. (1992). Negotiating the Curriculum: Educating for

the 21st Century. The Falmer Press, London. Bowden (1997a). ‘Educational Quality Assurance at RMIT - interview’. Director of

Educational Program Improvement, RMIT, Melbourne. Bowden, J. (1997b). ‘Continual Quality Improvement in Learning and Teaching through a

Centralised Approach to Educational Quality Assurance’ Managing the Quality of University Learning and Teaching. Bowden, J. A. and Sacks, J. Higher Education Division, Department of Employment, Education, Training and Youth Affairs, http://www.deetya.gov.au/divisions/hed/operations/Bowden/chapter8 .htm#head1, 20 June 1997.

Bowden, J. and Boyle, P. (1995). ‘Understanding RMIT’s Approach to Educational Quality Assurance’. RMIT, Melbourne.


Bowden, J. and Knowles, D. (1994). ‘A Proposal to Academic Board for a System of New Course Approval, Course Discontinuance, Course Re-Accreditation and Quality Assurance’. RMIT, Melbourne.

Boyle, P. (1995). ‘Educational Quality Assurance System - Information for Course Leaders and Teams: Examples of EPQM File Summaries’. RMIT, Melbourne.

Brey, P. (1997). ‘Philosophy of Technology meets Social Constructivism’. Society of Philosophy & Technology 2(3-4).

Bricknell, L. and Bowden, J. A. (1997). ‘Contextualising Quality in Australian Universities in the 1990s’ Managing the Quality of University Learning and Teaching. Bowden, J. A. and Sacks, J. Higher Education Division, Department of Employment, Education, Training and Youth Affairs, http://www.deetya.gov.au/ divisions/hed/operations/Bowden/chapter1.htm, 20 June 1997.

Bromley, H. (1997). ‘The Social Chicken and the Technological Egg: Educational Computing and the Technology/Society Divide’. Educational Theory 47(1): 51-63.

Brooks, F. P. (1987). ‘No Silver Bullet: Essence and Accidents of Software Engineering’. IEEE Computer 20(4): 10-19.

Bryant, D. P., Erin, J., Lock, R., et al. (1998). ‘Infusing a Teacher Preparation Program in Learning Disabilities with Assistive Technology’. Journal of Learning Disabilities 31(1): 55-69.

Burn, J. M. (1997). ‘Innovation in IS Education - Practising what we Preach’. Information Resources Management Journal 10(4): 16-25.

Burns, R. B. (1994). Introduction to Research Methods. (2nd edition). Longman Australia, Melbourne.

Busch, K. V. (1997). ‘Applying Actor Network Theory to Curricula Change in Medical Schools: Policy Strategies for Initiating and Sustaining Change’. Midwest Research-to-Practice Conference in Adult, Continuing and Community Education Conference, Michigan State University.

Callon, M. (1986a). ‘The Sociology of an Actor-Network: The Case of the Electric Vehicle’. Mapping the Dynamics of Science and Technology. Callon, M., Law, J. and Rip, A. (Eds). Macmillan Press, London: 19-34.

Callon, M. (1986b). ‘Some Elements of a Sociology of Translation: Domestication of the Scallops and the Fishermen of St Brieuc Bay’. Power, Action & Belief. A New Sociology of Knowledge? Law, J. (Ed). Routledge & Kegan Paul, London: 196-229.

Callon, M. (1987). ‘Society in the Making: The Study of Technology as a Tool for Sociological Analysis’. The Social Construction of Technological Systems. Bijker, W. E., Hughes, T. P. and Pinch, T. P. (Eds). The MIT Press, Cambridge, Ma.: 85-103.

Callon, M. (1991). ‘Techno-Economic Networks and Irreversibility’. A sociology of monsters. Essays on power, technology and domination. Law, J. (Ed). Routledge, London: 132-164.

Callon, M. (1992). ‘The Dynamics of Techno-Economic Networks’. Technological Change and Company Strategies. Coombs, R., Saviotti, P. and Walsh, V. (Eds). Hartcourt Brace Jovanovich, London: 72-102.

Callon, M. (1999). ‘Actor-Network Theory - The Market Test’. Actor Network Theory and After. Law, J. and Hassard, J. (Eds). Blackwell Publishers, Oxford: 181-195.

Callon, M., Courtial, J. P., Turner, W. A., et al. (1983). ‘From Translations to Problematic Networks: An Introduction to Co-Word Analysis’. Social Science Information 22(2): 191-235.

Callon, M. and Latour, B. (1981). ‘Unscrewing the big Leviathan: how actors macro-structure reality and how sociologists help them to do so’. Advances in social theory and methodology. Toward an integration of micro and macro-sociologies. Knorr-Cetina, K. and Cicourel, A. V. (Eds). Routledge & Kegan Paul, London: 277-303.


Callon, M. and Latour, B. (1992). ‘Don’t Throw the Baby out with the Bath School: a Reply to Collins and Yearley’. Science as Practice and Culture. Pickering, A. (Ed). Chicago University Press, Chicago: 343-368.

Caplan, N. and Nelson, S. D. (1973). ‘On Being Useful: The Nature and Consequences of Psychological Research on Social Problems’. American Psychologist 28: 199-211.

Carlson, J. (1966). ‘On Determining Computer Science Education Programs’. Communications of the ACM 9(3): 135.

Carlson, P. J. and Wetherbe, J. C. (1989). ‘Revamping the IS MBA’. CIO October: 68-70. Chagani, F. (1998). ‘Postmodernism: Rearranging the Furniture of the Universe’.

Irreverence 1(3): 1-3. Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley, Chichester. Checkland, P. (1991). ‘From Framework through Experience to Learning: the Essential

Nature of Action Research’. Information Systems Research: Contemporary Approaches and Emergent Traditions. Nissen, H. E., Klein, H. K. and Hirschheim, R.A. (Eds). North-Holland, Amsterdam: 397-403.

Checkland, P. and Scholes, J. (1991). Soft Systems Methodology in Action. Wiley, Chichester.

Checkland, P. B. (1988). ‘Soft Systems Methodology: an Overview’. Journal of Applied Systems Analysis (15): 27-30.

Clarke, R. (1996). ‘Industry and Professional Viewpoints on IS Courses’. The Australian Debate on Information Systems Curriculum. Arnott, D., Dampney, K. and Scollary, A. (Eds). Monash University, Melbourne: 82-84.

Clarke, R. (1998). 'A Primer in Diffusion of Innovations Theory'. Australian National University, http://www.anu.edu.au/people/Roger.Clarke/SOS/InnDiff.html, 21 January 99.

Clear, T. (1997). ‘Coupling and Cohesion Among Disciplines: Some Curriculum Paradigms’. ACM SIGCSE Bulletin 29(4): 14-16.

Coleman, J. S. (1958). ‘Relational Analysis: the Study of Social Organizations with Survey Methods’. Human Organization 14: 28-36.

Collins, H. M. and Yearley, S. (1992). ‘Epistemological Chicken’. Science as Practice and Culture. Pickering, A. (Ed). Chicago University Press, Chicago: 301-326.

Communique (1990). ‘The GUI: A Milestone in Human Communication’. Microsoft Communique (6): 13.

Communique (1992). ‘Professional Toolkit for Visual Basic debuts’. Microsoft Communique (26): 7.

Communique (1993). ‘Visual Basic Plus DbControl Equals Database’. Microsoft Communique (33): 28.

Communique (1998). ‘Introducing Visual Studio 6.0’. Microsoft Communique (95): 12. Cook, R. (1990). ‘Full Circle’ Byte: 211-214. Cooper, A. (1996). ‘Why I am Called ‘the Father of Visual Basic’’, http://www.cooper.com

/alan/father_of_vb.html, 22 April 1996. Cooper, R. B. and Zmud, R. W. (1990). ‘Information Technology Implementation

Research: A Technological Diffusion Approach’. Management Science 36: 123-139. Cougar, J. D., Davis, G. B., Gorgone, J. T., et al. (1995). ‘Information Systems IS’95

DRAFT Report. Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems’. AIS, ACM, DPMA, USA.

Cougar, J. D. and McFadder, F. R. (1975). Introduction to Computer Based Information Systems. Wiley, USA.

Courtial, J. P., Cahlik, T. and Callon, M. (1994). ‘A Model for Social Interaction Between Cognition and Action Through a Key-Word Simulation of Knowledge Growth’. Sociometrics 31(2): 173-192.


Crandall, D. and Associates (1982). People, Policies and Practice: Examining the Chain of School Improvement (Vol 3 1-10). The Network, Andover, MA.

Cronbach, L. J. and Suppes, P. (1969). Research for Tomorrow’s Schools: Disciplined Inquiry for Education. Macmillan., New York.

Crow, G. B. and Rariden, R. L. (1992). ‘Strengthening the Computer Information Systems Curriculum through Cooperative Education’. Journal of Computer Information Systems 32(3): 52-55.

Cusumano, M. A. and Selby, R. W. (1997). ‘How Microsoft Builds Software’. Communications of the ACM 40(6): 53-61.

Davey, B. and Tatnall, A. (1995). ‘Introducing Object Environments: Cognitive Difficulties’. Software Education Conference: SRIG-ET’94. Purvis, M. (Ed). IEEE Computer Society Press, Los Alamitos, Ca: 128-133.

Davey, B. and Tatnall, A. (1996). ‘Tools for Client-Server Computing’. Software Engineering: Education and Practice. Purvis, M. (Ed). IEEE Computer Society Press, Los Alamitos, Ca: 280-285.

Davis, D. C., Rhodes, R. and Baker, A. S. (1998). ‘Curriculum Revision: Reaching Faculty Consensus through the Nominal Group’. Journal of Nursing Education 37(7): 326-329.

Davis, G. B., Gorgone, J. T., Cougar, J. D., et al. (1997). ‘IS’97 Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems’. Association for Information Technology Professionals, USA.

Dawkins, J. S. (1988). ‘Higher Education Policy Statement’. AGPS, Canberra. de Vries, G. (1995). ‘Should we send Collins and Latour to Dayton, Ohio?’. EASST Review

14(4). Deakin University (1985). Curriculum Design and Innovation. Deakin University Press,

Geelong. Deely, J. (1990). Basics of Semiotics. Indiana University Press, Bloomington. Denning, P. J., Comer, D. E., Gries, D., et al. (1989). ‘Computing as a Discipline’.

Communications of the ACM 32(1): 9-23. Denning, P. J. E. (1989). ‘A Debate on Teaching Computing Science’. Communications of

the ACM 32(12): 1397- 1414. Dent, M. (1996). ‘Trust and Whatever Happened to Professional Dominance?’. SCOS

Conference Department of Education Employment and Training (1990). ‘Education and Training

Needs of Computing Professionals and Para-professionals in Australia’. Department of Employment Education and Training, Economic and Policy Analysis Division, Canberra.

Department of Education Employment and Training, Department of Industry Technology and Commerce and Information Industries Education and Training Foundation (1992). ‘Report of the Discipline Review of Computing Studies and Information Sciences Education, Volume 2, Main Report’, Canberra.

Department of Employment Education Training and Youth Affairs (1998). ‘Higher Education Student Data Collection’. DEET, Canberra.

Deutschmann, P. J. and Fals Borda, O. (1962). ‘Communication and Adoption Patterns in an Andean village’. Programa Interamericano de Informacion Popular, San Jose, Costa Rica.

Dick, B. (1998). ‘Soft Systems Methodology’ Action Research and Evaluation on Line, http://www.scu.edu.au/schools/sawd/areol/areol_session13, 11 October 1998.

Donald (1996). ‘Personal communication to HOD Business Computing’. Donald (1998). ‘Interview on Curricula at RMIT’. Chairman of RMIT Course Advisory

Committee, Melbourne.


Dougherty, J. (1997). ‘The Business of Information Technology Education’. Course Technology, http://www.course.com/news/joe_isecon.html, 3 Nov 1997.

Douglas, J. D. (1985). Creative Interviewing. Sage Publications, Beverly Hills, Ca. Downs, G. W. J. and Mohr, L. B. (1976). ‘Conceptual Issues in the Study of Innovations’.

Administrative Science Quarterly 21: 700-714. Dukovic, J. M. and Joyce, D. T. (1995). ‘An Evaluation of Object-Based Programming

with Visual Basic’. IEEE Computer. Eidahl, L. D., Mackenzie, D. and Mauer, L. (1999). Using Visual Basic 6, Platinum

Edition. Que Corporation, Minneapolis. Entrialgo, M., Fernandez, E. and Vazquez, C. J. (1999). ‘The Success Impact of Strategic

Managerial Characteristics Coalignment: an Empirical Examination of Spanish SMEs’. Entrepreneurship: Building for the Future, Groupe ESC Rennes, St Malo, France.

Emery, F. E., Ed. (1969). Systems Thinking. Penguin, Middlesex. Emurian, H. H. (1998). ‘Information Systems: an Interdisciplinary Perspective’.

Information Resources Management Journal 11(4): 3-4. Epstein, B. (1998). ‘Interpreting the World (without necessarily changing it)’. New Politics

6(4): 1-7. Fabbri, T. and Mann, R. A. (1993). ‘A Critical Analysis of the ACM and DPMA

Curriculum Models’. Journal of Computer Information Systems 34(1): 77-80. Farhoomand, A. F. (1992). ‘Scientific Progress of Management Information Systems’.

Information Systems Research: Issues, Methods and Practical Guidelines. Galliers, R. (Ed). Blackwell Scientific Publications, Oxford: 93-111.

Fein, L. (1967). ‘ACM has a Crisis of Identity?’. Communications of the ACM 10(1): 1. Feldman, P., Jennings, R., Seymour, B., et al. (1993). Using Visual Basic 3. Que

Corporation, Indianapolis. Festinger, L. (1957). A Theory of Cognitive Dissonance. University of Stanford Press,

Stanford, CA. Fichman, R. G. and Kemerer, C. F. (1997). ‘Object Technology and Reuse: Lessons from

Early Adopters’. IEEE Computer 30(10): 47-59. Finegan, A. (1994). ‘Soft Systems Methodology: an Alternative Approach to Knowledge

Elicitation in Complex and Poorly Defined Systems’. RMIT Centre for Remote Sensing and Land Information, http://www.csu.edu.au/ci/vol1/Andrew.Finegan/paper.html, 15 Nov 1998.

Finkelstein, A. (1993). ‘European Computing Curricula: A Guide and Comparative Analysis’. The Computer Journal 36(4): 299-319.

Fortune, R. E. and Palmer, H. (1990). ‘A Definition of the AACSB MIS Undergraduate Course. Partnership in Information Technology Roles of Academia and Business in the Nineties.’. Eighteenth Annual North American Conference of the International Business Schools Computer Users Group, Omaha, Nebraska.

Franklin, U. (1990). The Real World of Technology. CNC, Montreal. Fred (1993). ‘Stephen and Pick’. Private correspondence, Melbourne. Fred (1997a). ‘Interview on Educational Quality Assurance at RMIT’. Senior lecturer,

RMIT, Melbourne. Fred (1997b). ‘Interview on Programming Curricula at RMIT’. Senior lecturer, RMIT,

Melbourne. Fred (1998). ‘Interview on Programming Curricula at RMIT’. Senior lecturer, RMIT,

Melbourne. Fullan, M. (1993). Change Forces: Probing the Depths of Educational Reform. The Falmer

Press, London. Fullan, M. and Hargreaves, A. (1991). What’s Worth Fighting For: Working Together For

Your School. Ontario Public School Teacher’s Federation, Toronto.


Fullan, M. and Hargreaves, A. (1992). ‘Teacher Development and Educational Change’. Teacher Development and Educational Change. Fullan, M. and Hargreaves, A. (Eds). The Falmer Press, London.

Fullan, M. G. and Stiegelbauer, S. (1991). The New Meaning of Educational Change. (2nd edition). Teachers College Press, New York.

Gagne, R. M. and Briggs, L., J. (1988). Principles of Instructional Design (3rd edition). Holt, Rinehart and Winston, NY.

Galliers, R. D. and Land, F. F. (1987). ‘Choosing Appropriate Information Systems Research Methodologies’. Communications of the ACM 30(11): 900-902.

Gambill, S. and Jackson, W. (1992). ‘Applicability of MIS Curriculums to the Business Environment: An Examination of Business Criticism and an Academic Response’. Journal of Computer Information Systems 33(1): 13-17.

Gates, B. (1991). ‘Information At Your Finger Tips’. Microsoft Communique (11): 8-13. Geertz, C. (1979). ‘From the Native’s Point of View: on the Nature of Anthropological

Understanding’. Interpretive social science. Radinow, P. and Sullivan, W. (Eds). University of California Press, Berkeley.

Geoff (1992). ‘Personal communication’, RMIT, Melbourne. George (1999). ‘Interview on Visual Basic programming’. University student, IT

consultant, Melbourne. Gilding, T. (1997). ‘Student Construction of a Knowledge-based System as an Actor

Network’ School of Education. Deakin University, Geelong. Ginzberg, M. (1979). ‘A study of the Implementation Process’. TIMS Studies in

Management Science (13): 88. Glass, R. L. (1992). ‘A Comparative Analysis of the Topic Areas of Computer Science,

Software Engineering, and Information Systems’. Journal of Systems and Software 19(3): 277-289.

Goetz, J. P. and LeCompte, M. D. (1984). Ethnography and Qualitative Design in Educational Research. Academic Press, Orlando, Fl.

Goff, L. (1997). ‘Curriculums: Cobol be Damned, give them ‘Sexy’’ Computerworld. 31: 94.

Goldweber, M., Impagliazzo, J., Bogoiavlenski, I. A., et al. (1997). ‘Historical Perspectives on the Computing Curriculum (report of the ITiCSE’97 working group on historical perspectives in computing education)’. ITiCSE-’97 Working Group Reports and Supplemental Proceedings: 94-111.

Goode, W. J. and Hatt, P. K. (1952). Methods in Social Research. McGraw-Hill, New York.

Goodman, D. and Watts, M. J., Eds. (1997). Global/ising Food: Agrarian Questions and Global Restructuring. Routledge, London.

Goodson, I. F. (1991). ‘History, Context and Qualitative Methods’. Biography, Identity and Schooling: Episodes in Educational Research. Goodson, I. F. and Walker, R. (Eds). The Falmer Press, UK: 114-136.

Gorgone, J. T., Cougar, J. D., Davis, G., et al. (1994). ‘Information Systems ‘95 Curriculum Model - a Collaborative Effort’. Data base 25(4): 5-8.

Goslar, M. D. and Deans, P. C. (1993). ‘A Pilot Study of Information Systems Curriculum in Foreign Educational Institutions’. Journal of Computer Information Systems 34(1): 8-17.

Goslar, M. D. and Deans, P. C. (1994). ‘A Comparative Study of Information Systems Curriculum in U.S. and Foreign Universities’. DATA BASE for Advances in Information Systems 25(1): 7-20.

Gries, D., Walker, T. and Young, P. (1989). ‘The 1988 Snowbird Report: a Discipline Matures’. Communications of the ACM 32(3): 294-297.


Grint, K. and Woolgar, S. (1997). The Machine at Work - Technology, Work and Organisation. Polity Press, Cambridge.

Guba, E. G. and Lincoln, Y. S. (1988). ‘Do Inquiry Paradigms Imply Inquiry Methodologies?’. Qualitative approaches to evaluation in education: the silent scientific revolution. Fetterman, D. M. (Ed). Praeger, New York.

Guba, E. G. and Lincoln, Y. S. (1994). ‘Competing Paradigms in Qualitative Research’. Handbook of qualitative research. Denzin, N. K. and Lincoln, Y. S. (Eds). Sage, Thousand Oaks: 105-117.

Hall, R. (1997). ‘Knowledge use and the dynamics of managing curriculum change’. Science Communication 18(4): 342-361.

Hamilton, M. A. (1996). ‘Java and the Shift to Net-Centric Computing’. IEEE Computer 29(8): 31-39.

Hamilton, S. and Ives, B. (1982). ‘MIS research strategies’. Information and Management 5(December): 339-347.

Hammersley, M. and Atkinson, P. (1983). Ethnography: Principles in Practice. Tavistock Publications, New York.

Haraway, D. J. (1991). Simians, cybords, and women: the reinvention of nature. Routledge, New York.

Hardgrave, B. C. and Douglas, D. E. (1998). ‘Trends in Information Systems Curricula: Object-Oriented Topics’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Hargreaves, A. (1992). ‘Cultures of Teaching: A Focus for Change’. Understanding Teacher Development. Hargreaves, A. and Fullan, M. (Eds). Teachers College Press (Cassell), New York.

Harriger, A. R. and Lisack, S. (1998). ‘Tools to Facilitate Event-Driven Program Design in Introductory Courses’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Haslam, N. O. (1998). ‘Natural kinds, human kinds, and essentialism’. Social Research 65(2): 291-314.

Hassinger, E. (1959). ‘Stages in the adoption proces’. Rural Sociology 24: 52-53. Havelock, R. (1969). ‘The process and strategy of beneficial change: an analysis and

critique of four perspectives’. Centre for Research on the Utilization of Scientific Knowledge, University of Michigan., Ann Arbour.

Havelock, R. (1971). ‘Planning for Innovation Through Dissemination and Utilization of Knowledge’. Centre for Research on Utilization of Scientific Knowledge, Institute for Social Research, University of Michigan, Ann Arbor.

Hawking, S. W. (1989). A Brief History of Time. Bantam Books, UK. Haworth, D. A. and van Wetering, F. J. (1994). ‘Determining Underlying Corporate

Viewpoints on Information Systems Education Curricula’. Journal of Education for Business 69(5): 292-295.

Hefferlin, J. L. (1969). Dynamics of Academic Reform. Jossey-Bass, San Francisco. Henry (1997). ‘Interview on Business Computing Curricula at RMIT’. Contract lecturer,

RMIT, Melbourne. Higher Education Council (1992). ‘Higher Education: Achieving Quality’. AGPS,

Canberra. Hilton, T. S. E. (1990). ‘The Place of Interpersonal Communication Skill in Business

Information Systems Curricula’. IBSCUG Quarterly 2:3(Fall 1990): 10-15. Hirschheim, R. A. (1992). ‘Information Systems Epistemology: an Historical Perspective’.

Information Systems Research: Issues, Methods and Practical Guidelines. Galliers, R. (Ed). Blackwell Scientific Publications, Oxford: 28-60.


Hopcroft, J. E. (1987). ‘Computer Science: the emergence of a discipline’. Communications of the ACM 30(3): 198-202.

House, E. R. (1979). ‘Technology versus craft: a ten year perspective on innovation’. Journal of Curriculum Studies (11): 1-15.

House, E. R. (1981). ‘Three perspectives on innovation’. Improving schools: using what we know. Lehming, R. and Kane, M. (Eds). Sage, Beverly Hills: 17-41.

Hoyle, E. and Bell, R. (1972). Problems of curriculum innovation. Open University Press, Bletchley.

Hu, Q., Saunders, C. and Gebelt, M. (1997). ‘Research report - diffusion of information systems outsourcing: a reevaluation of influence sources’. Information Systems Research 8(3): 288-301.

Hubbard, L. A. and Ottoson, J. M. (1997). ‘When a buttom-up innovation meets itself as a top-down policy’. Science Communication 19(1): 41-55.

Hughes, T. P. (1983). Networks of Power: Electrification in Western Society, 1880-1930. Johns Hopkins University Press, Baltimore and London.

Hughes, T. P. (1988). ‘The Seamless Webb: Technology, Science, et cetera, et cetera’. Technology and Social Progress. Elliott, B. (Ed). Edinburgh University Press, Edinburgh.

Hughes, T. P. and Sheehan, J. R. (1999). ‘What Has Influenced Computing Innovation’. IEEE Computer (February): 33-43.

Humphrey, C. and Scapens, R. W. (1996). ‘Methodological Themes Theories and Case Studies of Organizational Accounting Practices: Limitation or Liberation?’. Accounting 9(4).

Ian (1994). ‘Some Comments on BI940 - Business Systems’. RMIT internal working document, Melbourne.

IBM (1987). ‘The Graduates: Bridging the IS-Business Management Gap’. IBM Directions (Fall 1987): 20-21.

Information Industries Education and Training Foundation (1992). ‘The Supply of Skilled People in Information Technology: A Statistical Profile’, Canberra.

Information Resource Management Association and Data Administration Managers Association (1996). ‘IRMA/DAMA Curriculum Model’.

Izadi, M., Kashef, A. E. and Stadt, R. W. (1996). ‘Quality in Higher Education: Lessons Learned from the Baldrige Award, Deming Prize, and the ISO 9000 Registration’. Journal of Industrial Teacher Education 33(2): 60-76.

Jackson, W. M. and Nath, R. (1989). ‘Publication patterns of MIS researchers’. Interface 11(4): 15-20.

Jacob, E. (1987). ‘Qualitative research traditions: a review’. Review of Educational Research 57(1): 1-50.

Jacobson, I., Griss, M. and Jonsson, P. (1997). ‘Making the Reuse Business Work’. IEEE Computer 30(10): 36-42.

Jaeger, R. M. (1988). Complementary Methods for Research in Education. American Educational Research Association, Washington, DC.

James (1997). ‘Interview on Programming Curricula at RMIT’. Senior lecturer, RMIT, Melbourne.

Jean (1998). ‘Interview on Curricula at RMIT’. Member of RMIT Course Advisory Committee, Melbourne.

Jennings, R. (1996). Database Developers Guide with Visual Basic 4. (2nd edition). SAMS Publishing, Indianapolis.

John (1993a). ‘A Process for the Integration of the Degree in Business Information Systems and Computing’. RMIT internal working document, Melbourne.


John (1993b). ‘Undergraduate Review Working Paper’. RMIT internal working document, Melbourne.

John (1994). ‘Course Structure’. RMIT internal working document, Melbourne. John (1997). ‘Interview on Programming Curriculum at RMIT’. HOD Business

Computing, RMIT, Melbourne. Juliff, P. (1986). Program Design. (2nd edition). Prentice Hall, Melbourne. Juliff, P. (1990). ‘Personal communication’, Melbourne. Juliff, P. (1992). ‘Personal communication’, Melbourne. Jungk, R. (1956). Brighter than a Thousand Suns. Pelican, Harmondsworth. Kaplan, B. (1985). ‘Barriers to Medical Computing: History, Diagnosis, and Therapy for

the Medical Computing “Lag”’. The Ninth Annual Symposium on Computer Applications in Medical Care, IEEE Computer Society, Silver Springs, MD.

Kaplan, B. (1991). ‘Models of Change and Information Systems Research’. Information Systems Research: Contemporary Approaches and Emergent Traditions. Nissen, H. E., Klein, H. K. and Hirschheim, R. (Eds). Elsevier Science Publishers, Amsterdam: 593-611.

Kaplan, B. and Duchon, D. (1988). ‘Combining Qualitative and Quantitative Methods in Information Systems Research: a Case Study’. MIS Quarterly 12(4): 571-586.

Kayatekin, S. A. (1998). ‘Observations on some theories of current agrarian change’. Review of African Political Economy 25(76): 207-219.

Keen, C. (1996). ‘The Organisational Environment of Australian Information Systems Education’. The Australian Debate on Information Systems Curriculum. Arnott, D., Dampney, K. and Scollary, A. (Eds). Monash University, Melbourne: 35-48.

Kellehear, A. (1993). The unobtrusive researcher: a guide to methods. Allen & Unwin, St Leonards, Australia.

Kemmis, S. and McTaggart, R. (1982). The Action Research Planner. (2nd edition). Deakin University Press, Geelong.

Kemmis, S. and McTaggart, R. (1988). The Action Research Reader. (3rd edition). Deakin University Press, Geelong.

Kemmis, S. and Stake, R. (1988). Evaluating Curriculum. Deakin University Press, Geelong.

Kendall, K. E. and Kendall, J. E. (1992). Systems Analysis and Design. (2nd edition). Prentice Hall, New Jersey.

Kishmore, R. and McLean, E. (1998). ‘Diffusion and Infusion: Two Dimensions of ‘Success of Adoption’ of IS Innovations’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Kolakowski, L. (1972). Positivist Science. Penguin Books, Harmondsworth. Kolb, D. A. and Frohman, A. L. (1970). ‘An organization development approach to

consulting’. Sloan Management Review (12): 51-65. Kung, D., Gao, J., Hsia, P., et al. (1995). ‘Developing an Object-Oriented Software Testing

and Maintenance Environment’. Communications of the ACM 38(10): 75-87. Kwon, T. H. and Zmud, R. W. (1987). ‘Unifying the Fragmented Models of Information

Systems Implementation’. Critical Issues in Information Systems Research. Borland, R. J. and Hirschheim, R. A. (Eds). John Wiley and Sons, Chichester: 227-251.

Lambright, W. H. (1994). ‘Administrative entrepreneurship and space technology: the ups and downs of “Mission to Planet Earth”’. Public Administration Review 54(2).

Larsen, T. J. (1998). 'Information Systems Innovation and Diffusion Studies', http://www.bi.no/dep2/infomgt/research/tor-innovation/index.htm, 21 January 1999

Latour, B. (1986). ‘The Powers of Association’. Power, Action and Belief. A new sociology of knowledge? Sociological Review monograph 32. Law, J. (Ed). Routledge & Kegan Paul, London: 264-280.


Latour, B. (1987). Science in Action: How to Follow Engineers and Scientists Through Society. Open University Press, Milton Keynes.

Latour, B. (1988a). The Pasteurization of France. Harvard University Press, Cambridge, Ma.

Latour, B. (1988b). ‘The Prince for Machines as well as for Machinations’. Technology and Social Process. Elliott, B. (Ed). Edinburgh University Press, Edinburgh: 20-43.

Latour, B. (1991). ‘Technology is society made durable’. A Sociology of Monsters. Essays on Power, Technology and Domination. Law, J. (Ed). Routledge, London: 103-131.

Latour, B. (1993). We have never been modern. Harvester Wheatsheaf, Hemel Hempstead. Latour, B. (1996). Aramis or the Love of Technology. Harvard University Press,

Cambridge, Ma. Latour, B. (1997). ‘On actor-network theory. A few clarifications’. Centre for Social

Theory and Technology, Keele University, http://www.keele.ac.uk/depts/stt/stt /ant/latour.htm, 2 May 1997.

Latour, B., Mauguin, P. and Teil, G. (1992). ‘A Note on Socio-Technical Graphs’. Social Studies of Science 22(1): 33-57.

Law, J. (1986a). ‘The Heterogeneity of Texts’. Mapping the Dynamics of Science and Technology. Callon, M., Law, J. and Rip, A. (Eds). Macmillan Press, UK: 67-83.

Law, J. (1986b). ‘On the methods of long distance control: vessels, navigation and the Portugese route to India’. Power, Action and Belief: A New Sociology of Knowledge? Law, J. (Ed). Routledge & Kegan Paul, London: 234-263.

Law, J. (1987). ‘Technology and Heterogeneous Engineering: The Case of Portuguese Expansion’. The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology. Bijker, W. E., Hughes, T. P. and Pinch, T. J. (Eds). MIT Press, Cambridge, Ma: 111-134.

Law, J. (1988). ‘The Anatomy of a Socio-technical Struggle: the Design of the TSR2’. Technology and Social Process. Elliott, B. (Ed). Edinburgh University Press, Edinburgh: 44-69.

Law, J. (1991). ‘Introduction: monsters, machines and sociotechnical relations’. A Sociology of Monsters: Essays on Power, Technology and Domination. Law, J. (Ed). Routledge, London.

Law, J. (1992). ‘Notes on the Theory of the Actor-Network: Ordering, Strategy and Heterogeneity’. Systems Practice 5(4): 379-393.

Law, J. (1997). Topology and the Naming of Complexity (Draft)’ Actor Network and After Workshop. Department of Sociology, Lancaster University, http://www.lancaster.ac.uk/ sociology/stslaw3.html, 31 July 1997.

Law, J. (1999). ‘After ANT: complexity, naming and topology’. Actor Network Theory and After. Law, J. and Hassard, J. (Eds). Blackwell Publishers, Oxford: 1-14.

Law, J. and Callon, M. (1988). ‘Engineering and Sociology in a Military Aircraft Project: A Network Analysis of Technological Change’. Social Problems 35(3): 284-297.

Law, J. and Callon, M. (1992). ‘The Life and Death of an Aircraft: A Network Analysis of Technical Change’. Shaping Technology/Building Society: Studies in Sociological Change. Bijker, W. and Law, J. (Eds). MIT Press, Cambridge, Ma.: 21-52.

Layton, D. (1972). ‘Science as General Education’. Trends in Education (January). Lee, A. S. (1989). ‘A scientific methodology for MIS case studies’. MIS Quarterly 13(1):

33-50. Lee, N. and Brown, S. (1994). ‘Otherness and the Actor Network: The Undiscovered

Continent’. American Behavioral Scientist 37(6): 772-790. Lee, R. and Leigh, W. (1998). ‘A specialization of object-oriented design for the fourth

generation language, business environment’. Journal of Computer Information Systems 38(3): 93-98.


Lewin, K. (1946). ‘Action Research and Minority Problems’. Journal of Social Issues (2): 34-46.

Lewin, K. (1947). ‘Frontiers in group dynamics’. Human Relations (1): 5-41. Licker, P. S. and Miller, M. (1989). ‘How are DP/MIS graduates doing?’. Journal of

Systems Management April: 25-32. Linderoth, H. C. J. (1997). ‘Information Technology Infusion - Beyond Information

Technology Implementation?!’. Information Systems Research in Scandinavia, IRIS20 Conference, University of Oslo, Hanko, Norway.

Lindgaard, G. (1994). Usability Testing and System Evaluation. Chapman & Hall, London. Linton, J. (1998). ‘Technology Briefs: Diffusion of Innovations’. Circuits Assembly 9(4):

24-28. Lo, B. W. N. (1991). ‘Australian Information Systems Curricula’. Journal of Computer

Information Systems 31(3): 20-33. Longenecker, H., E. Jr and Feinstein, D., L. (1990). ‘Information Systems (IS’90) DRAFT

report: The DPMA Model Curriculum for a Four Year Undergraduate Degree’. DPMA (CTF-90), USA.

Longenecker, H. E. J., Feinstein, D. L., Couger, J. D., et al. (1994). ‘Information Systems ‘95: A Summary of the Collaborative IS Curriculum Specification of the Joint DPMA, ACM, AIS Task Force’. Journal of Information Systems Education Winter 1994-95: 174-186.

Lowe, P. and Ward, N. (1997). ‘Field-level bureaucrats and the making of new moral discourses in agri-environmental controversies’. Global/ising food: agrarian questions and global restructuring. Goodman, D. and Watts, M. J. (Eds). Routledge, London: 256-272.

Luis (1994). ‘Memo to the Course Advisory Committee re New Course Structure’. RMIT internal working document, Melbourne.

Lundberg, N. (1997). ‘Intermediaries in a Social Network: An Empirical Study of Radiology Departments’. Information Systems Research in Scandinavia, IRIS20 Conference, University of Oslo, Hanko, Norway.

Lynn, J. and Jay, A. (1984). The Complete Yes Minister - The Diaries of a Cabinet Minister. British Broadcasting Corporation, London.

MacDonald, B. and Walker, R. (1976). Changing the Curriculum. Open Books, London. Machiavelli, N. (1995). The Prince. Penguin Classics, London. Macquarie University (1981). The Macquarie Dictionary. Macquarie Library, Sydney. Mahajan, V. and Peterson, R. A. (1985). Models for Innovation Diffusion. (Sage University

Papers). Sage Publications Inc, Newbury park. Marris, P. (1975). Loss and Change. Anchor Press/Doubleday, New York. Martin, P. Y. and Turner, B. A. (1986). ‘Grounded Theory and Organizational Research’.

The Journal of Applied Behavioral Science 22(2): 141-157. Massey, P. D. and Douglas, D. E. (1993). ‘Object-Oriented Technologies in Information

Systems Curricula’. Journal of Computer Information Systems 34(1): 3-7. Maynard, G. (1990). ‘Personal communication’, Melbourne. McBride, G. and Rademacher, R. (1992). ‘A Profile of IS Research 1986-1991’. Journal of

Computer Information Systems Spring 1992: 1-5. McKelvy, M., Martinsen, R., Webb, J., et al. (1997). Using Visual Basic 5 - Special

Edition. Que Corporation, Indianapolis. McKeown, B. and Thomas, D. (1988). Q methodology. Sage Publications, Newbury Park,

CA. McMaster, T., Vidgen, R. T. and Wastell, D. G. (1997). ‘Towards an Understanding of

Technology in Transition. Two Conflicting Theories’. Information Systems Research in Scandinavia, IRIS20 Conference, University of Oslo, Hanko, Norway.


Merriam, S. B. (1988). Case study research in education. Jossey-Bass, San Francisco. Microsoft (1991a). ‘Microsoft Announces Visual Basic for Windows’ Microsoft History.

Microsoft, http://library.microsoft.com/mshist/1991.htm, 20 May 1998. Microsoft (1991b). ‘Microsoft Visual Basic 1.0 - Product Package’. Microsoft, USA. Microsoft (1993). Microsoft Visual Basic Programmer’s Guide (version 3.0). Microsoft

Corporation, USA. Microsoft (1995). Microsoft Visual Basic Programmer’s Guide (version 4.0). Microsoft

Corporation, USA. Microsoft (1997). Microsoft Visual Basic Programmer’s Guide (version 5.0). Microsoft

Corporation, USA. Mol, A. and Law, J. (1994). ‘Regions, Networks and Fluids: Anaemia and Social

Topology’. Social Studies of Science 24: 641-671. Montgomery, T. (1992). ‘Business Computing Curriculum’. Director, Division of

Information Technology, RMIT, Melbourne. Murray-Smith, S. and Dare, A. J. (1987). The Tech: a centenary history of the Royal

Melbourne Institute of Technology. Hyland House, Melbourne. Myers, M. D. (1997). ‘Qualitative Research in Information Systems’. MIS Quarterly,

http://misq.org/misqd961/isworld/, 20 May 1997. Nespor, J. (1994). Knowledge in Motion: Space, Time and Curriculum in Undergraduate

Physics and Management. Falmer Press, London. Nias, J. (1988). ‘Creating a collaborative culture’. Histories and Ethnographies of Teaching

as Work, St Hilda’s College, Oxford, St Hilda’s College, Oxford. Nissen, H. E., Klein, H. K. and Hirschheim, R. (1991). ‘A Pluralist Perspective of the

Information Systems Research Arena’. Information Systems Research: Contemporary Approaches and Emergent Traditions. Nissen, H. E., Klein, H. K. and Hirschheim, R. (Eds). Elsevier Science Publications, Amsterdam: 1-20.

Nordvall, R. C. (1982). ‘The process of change in higher education institutions’. American Association for Higher Education, Washington DC.

Nunamaker, J. F., Daniel, C. J. and Davis, G. B. (1982). ‘Information Systems Curriculum Recommendations for the 80s: Undergraduate and Graduate Programs’. Communications of the ACM 25(11): 781-805.

Nunamaker, J. F. E. (1981). ‘Educational Programs in Information Systems: a report of the ACM Curriculum Committee on Information Systems’. Communications of the ACM 24(3): 124-133.

O’Neill, H. M., Pouder, R. W. and Buchholtz, A. K. (1998). ‘Patterns in the diffusion of strategies across organizations: insights from the innovation diffusion literature’. Academy of Management Review 23(1): 98-114.

Orlikowski, W. J. (1993). ‘CASE Tools as Organizational Change: Investigating Incremental and Radical Changes in Systems Development’. Management Information Systems Quarterly 17(3): 1-28.

Orlikowski, W. J. and Baroudi, J. J. (1991). ‘Studying Information Technology in Organizations: Research Approaches and Assumptions’. Information Systems Research 2(1): 1-28.

OSRA (1997). ‘Office Systems Research Association (OSRA): Organizational & End-user Information Systems Curriculum Model’.

Ousterhout, J. K. (1998). ‘Scripting: Higher-Level Programming for the 21st Century’. IEEE Computer 31(3): 23-30.

Parsons, J. and Wand, Y. (1997). ‘Using Objects for Systems Analysis’. Communications of the ACM 40(12): 104-110.


Patnayakuni, R. and Rai, A. (1998). ‘The Impact of Technological Characteristics on the Infusion of Software Tools’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Patricia (1997). ‘Interview on Educational Quality Assurance at RMIT’. Senior Lecturer, RMIT, Melbourne.

Paul (1997a). ‘Interview on Educational Quality Assurance at RMIT’. Senior Lecturer, RMIT, Melbourne.

Paul (1997b). ‘Interview on Programming and Curriculum at RMIT’. Senior Lecturer, RMIT, Melbourne.

Pearcey, T. (1988). A History of Australian Computing. Chisholm Institute of Technology, Melbourne.

Philipson, G. (1998). ‘A sad but instructive tale’ The Age, Melbourne: 60. Phillip Institute of Technology (1990). 1990 Handbook. Phillip Institute of Technology,

Melbourne. Phillip Institute of Technology (1992). 1992 Handbook. Phillip Institute of Technology,

Melbourne. Pick Systems (1998a). ‘An Incomplete History of Pick/BASIC’. Pick Systems,

http://www.picksys.com/articles/pw/119407.html, 22 September 1998. Pick Systems (1998b). ‘The Pick Systems Approach: Now more than ever’. Pick Systems,

http://www.picksys.com/company/approach.html, 22 September 1998. Pinch, S. (1998). ‘Review: Innovation, networks and learning regions?’. Regional Studies

32(1): 98-99. Pincus, J. (1974). ‘Incentives for innovation in public schools’. Review of Educational

Research 44: 113-144. Pitman, A. (1981). ‘The Necessary Distortion of Disseminated Innovations’. Journal of

Curriculum Studies 13(3): 253-265. Pitman, A. and Romberg, T. (2000). ‘Teachers’ Use of Time in a Period of Change’. The

Dimension of Time and the Challenge of School Reform. Gandara, P. (Ed). State University of New York Press, Albany, NY.

Pountain, D. and Szyperski, C. (1994). ‘Extensible Software Systems’. Byte May 1994: 57-62.

Preiss, K. (1999). ‘Dali’s Paradox: Creating Confusion to Set Innovation Creativity Free’. Entrepreneurship: Building for the Future, Groupe ESC Rennes, St Malo, France.

Press, L., Burkhart, G., Foster, W., et al. (1998). ‘An Internet Diffusion Framework’. Communications of the ACM 41(10): 21-26.

Prout, A. (1996). ‘Actor-network theory, technology and medical sociology: an illustrative analysis of the metered dose inhaler’. Sociology of Health & Illness 18(2): 198-219.

Purvis, M., Ed. (1996). Software Engineering: Education and Practice. IEEE Computer Society Press, Los Alamitos, California.

Radder, H. (1992). ‘Normative Reflexions on Constructivist Approaches to Science and Technology’. Social Studies of Science 22(1): 141-173.

Rai, A., Ravichandran, T. and Samaddar, S. (1998). ‘How to Anticipate the Internet’s Global Diffusion’. Communications of the ACM 41(10): 97-106.

Rapoport, R. N. (1970). ‘Three Dilemmas in Action Research’. Human Relations 23(4): 449-513.

Rasmussen, C. (1989). Poor Man’s University. Footscray Institute of Technology, Melbourne.

Ratcliff, B. and Siddiqi, J. (1985). ‘An Empirical Investigation into Problem Decomposition Strategies used in Program Design’. International Journal of Man-Machine Studies 22(1): 77-90.


Rational Software Corporation (1997). Unified Modelling Language. Rational Software Corporation, Santa Clara.

Rebecca (1994). ‘Memo to the Course Advisory Committee re New Course Structure’. RMIT internal working document, Melbourne.

Rebecca (1997a). ‘Interview on Educational Quality Assurance at RMIT’. Senior Lecturer, RMIT, Melbourne.

Rebecca (1997b). ‘Interview on Programming Curriculum at RMIT’. Senior Lecturer, RMIT, Melbourne.

Richards, R. M. and Sanford, C. C. (1992). ‘An Evolutionary Change in the Information Systems Curriculum at the University of North Texas’. Computers and Education 19(3): 219-228.

Rifkin, G. (1987). ‘Crisis in Education: MIS Courses Fall Short’. Computerworld June 22, 1987: 70-71.

Rine, D. C. (1997). ‘Supporting Reuse with Object Technology’. IEEE Computer 30(10): 43-45.

Rip, A. (1986). ‘Mobilising Resources Through Texts’. Mapping the Dynamics of Science and Technology. Callon, M., Law, J. and Rip, A. (Eds). Macmillan, London.

RMIT (1995). ‘Teaching and Learning at RMIT: philosophy and principles’. RMIT, Melbourne.

RMIT (1997a). ‘About RMIT University’ RMIT hotTYPE. RMIT, http://www.rmit.edu.au/ About/, 1 December 1997.

RMIT (1997b). ‘Key Dates in RMIT University’s History’ RMIT hotTYPE. RMIT, http://www.rmit.edu.au/About/hotTYPEv1n1/keydates.htm, 3 February 1997.

RMIT (1998). ‘About RMIT University’ About RMIT. RMIT, http://www.rmit.edu.au/About/, 2 December 1998.

RMIT Department of Business Computing Course Advisory Committee (1992). ‘Minutes of Department of Business Computing Course Advisory Committee’. RMIT, Melbourne.



RMIT Department of Business Computing Course Advisory Committee, April. (1997a). ‘Minutes of Department of Business Computing Course Advisory Committee’. RMIT, Melbourne.

RMIT Department of Business Computing Course Advisory Committee, October. (1997b). ‘Minutes of Department of Business Computing Course Advisory Committee’. RMIT, Melbourne.

RMIT Department of External Studies (1971). ‘“Data Processing-1” subject description’. RMIT, Melbourne.

RMIT Faculty of Business (1990). 1990 Faculty of Business Handbook: Undergraduate and Postgraduate Programs. RMIT, Melbourne.


RMIT Faculty of Business (1993a). 1993 Faculty of Business Handbook: Undergraduate and Postgraduate Programs. RMIT, Melbourne.

RMIT Faculty of Business (1993b). ‘RMIT Undergraduate Business Course Review. Progress Report: for Circulation and Comment’. RMIT internal working documents, Melbourne.





RMIT Faculty of Business (1997). 1997 Faculty of Business Handbook: Undergraduate, TAFE and Postgraduate Programs. RMIT, Melbourne.

Robertson, L. A. (1993). Simple Program Design. (2nd edition). Thomas Nelson, Melbourne.

Rogers, E., M and Kincaid, D. L. (1981). Communication Networks: Towards a New Paradigm for Research. The Free Press, New York.

Rogers, E. M. (1995). Diffusion of Innovations. (4th edition). The Free Press, New York. Rogers, E. M., Daley, H. and Wu, T. (1980). ‘The diffusion of personal computers’.

Stanford University, Institute for Communication Research, Stanford CA. Rogers, E. M. and Shoemaker, F. F. (1971). Communication of Innovations: A Cross-

Cultural Approach. Free Press, New York. Rogers, E. M. and van Es, J. C. (1964). ‘Opinion leadership in traditional and modern

Columbian peasant communities’. Michigan State University, Department of Communication, East Lansing.

Romberg, T. A. and Price, G. G. (1981). ‘Assimilation of innovations into the culture of schools: impediments to radical change’. NIE Conference on Issues Related to the Implementation of Computer Terminology in Schools, Washington DC.

Rose, J. (1997). ‘Soft systems methodology as a social science research tool’. Systems Research and Behavioral Science 14: 249-258.

Roy (1997). ‘Educational Quality Assurance at RMIT - interview’. Director of Teaching Quality, Faculty Of Business, RMIT, Melbourne.

Ryan, B. and Gross, N. C. (1943). ‘The Diffusion of Hybrid Corn Seed in Two Iowa Communities’. Rural Sociology 13: 273-285.

Ryan, B. and Gross, N. C. (1950). ‘Acceptance and Diffusion of Corn Seed in Two Iowa Communities’. Iowa Agricultural Experiment Station: Research Bulletin 372: 665-666, 679.

Saga, V. L. (1994). ‘The Nature and Determinants of Information Technology Infusion: an Organizational Level of Analysis’. Florida State University, Florida.

Saga, V. L. and Zmud, R. W. (1994). ‘The Nature and Determinants of IT Acceptance, Routinization and Infusion’. Diffusion, Transfer and Implementation of Information Technology. Levine, L. (Ed). Elsevier, Amsterdam: 67-86.

Sahay, S. (1997). ‘Implementation of Information Technology: A Space-Time Perspective’. Organization Studies 18(2): 229-260.

Sandman, T. E. (1993). ‘A Framework for Adapting a MS/MIS Curriculum to a Changing Environment’. Journal of Computer Information Systems 34(2): 69-73.

Schaefler, G. F. (1972). ‘Post-Tertiary Courses in Computer Science’. RMIT, Melbourne. Schein, E. H. (1961). ‘Management development as a process of influence’. Industrial

Management Review (2): 59-77. Schmidt, K. H. (1999). ‘Human Resources, Employment and Economic Development: the

Case of Small Firms’. Entrepreneurship: Building for the Future, Groupe ESC Rennes, St Malo, France.

Schön, D. A. (1971). Beyond the stable state: Public and Private Learning in a Changing Society. Temple Smith, London.

Scott, P. (1991). ‘Levers and Counterweights: a Laboratory that Failed to Raise the World’. Social Studies of Science 21(1): 7-35.


Sculley, J. and Byrne, J. A. (1989). Odyssey: Pepsi to Apple. Fontana, UK. Seddon, T. (1995). ‘Defining the real: context and beyond’. Qualitative Studies in

Education 8(4): 393-405. Seymour, D. T. (1988). ‘Developing Academic Programs: The Climate for Innovation’.

American Association for Higher Education, Washington DC. Shackleton, P. (1998). ‘Event Driven Languages for Novice Programmers’ Department of

Information Systems. Victoria University of Technology, Melbourne: 211. Shackleton, P. and McConville, D. (1998). Program Design Through Visual Basic. (4th

edition). Data Publishing, Melbourne. Shackleton, P., O’Connor, M. and Tatnall, A. (1997). ‘Visual Programming Environments

in Information Systems Curricula’. 8th Australasian Conference on Information Systems, Adelaide.

Shaw, M. (1990). ‘Prospects for an Engineering Discipline of Software’. IEEE Software (November 1990): 15-24.

Shelley, M. (1992). Frankenstein, or the Modern Prometheus. (Penguin Classics edition). Penguin Classics, London.

Shipman, M. (1988). The limitations of social research. (3rd edition). Longman, London. Shulman, L. S. (1988). ‘Disciplines of Inquiry in Education: an overview’. Complementary

Methods for Research in Education. Jaeger, R. M. (Ed). American Educational Research Association, Washington, DC.

Sikes, P. J. (1992). ‘Imposed Change and the Experienced Teacher’. Teacher Development and Educational Change. Fullan, M. and Hargreaves, A. (Eds). The Falmer Press, London.

Simmie, J., Ed. (1997). Innovation, networks and learning regions? Jessica Kingsley, London.

Singleton, V. and Michael, M. (1993). ‘Actor-Networks and Ambivalence: General Practitioners in the UK Cervical Screening Programme’. Social Studies of Science 23: 227-264.

Slezak, P. (1994). 'Sociology of Scientific Knowledge and Science Education Part 2: Laboratory Life Under the Microscope'. Science and Education(3): 329-355.

Solway, E. (1993). ‘Should we teach students to program?’. Communications of the ACM 36(10): 21-24.

Spann-Merchant, S. (1998). ‘A Proposed Model of the Influence of Communication on the Diffusion of Technological Innovations’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Stake, R. E. (1988). ‘Case Study Methods in Educational Research: Seeking Sweet Water’. Complementary Methods for Research in Education. Jaeger, R. M. (Ed). American Educational Research Association, Washington, DC: 253-265.

Stake, R. E. (1995). The Art of Case Study Research. Sage Publications, London. Star, S. L. (1995). The Cultures of Computing. Blackwell Publishers, Oxford. Star, S. L. and Griessemer, J. R. (1989). ‘Institutional Ecology, ‘Translations’ and

Boundary Objects: Amateurs and Professionals in Berkley’s Museum of Vertebrate Zoology, 1907-39’. Social Studies of Science 19: 387-420.

Stark, J. S. and Lattuca, L. R. (1997). Shaping the College Curriculum - Academic Plans in Action. Allyn and Bacon, Boston.

Statts, W. J. (1998). ‘A Three-Pronged Approach to an Object Oriented Computer Information Systems Curriculum’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Stephen (1997). ‘Interview on Business Computing Curriculum at RMIT’. Senior Lecturer, RMIT, Melbourne.


Stephenson, W. (1953). The study of behavior: Q-technique and its methodology. University of Chicago Press, Chicago, IL.

Stolen, J. (1992). ‘The Undergraduate MIS Curriculum: a Sampling of AACSB Schools’. Journal of Computer Information Systems 33(2): 54-57.

Stoner, J. A. F., Yetton, P. W., Craig, J. F., et al. (1994). Management. (2nd edition). Prentice Hall Australia, Sydney.

Suchman, L., A. (1987). Plans and Situated Actions. The problem of human-machine communication. Cambridge University Press, Cambridge.

Sullivan, C. H. J. (1985). ‘Systems Planning in the Information Age’. Sloan Management Review Winter: 3-11.

Tatnall, A. (1993). ‘A Curriculum History of Business Computing in Victorian Tertiary Institutions from 1960 - 1985’ Education. Deakin University, Geelong.

Tatnall, A. (1994). ‘The Beginnings of Business Computing’. Asia Pacific Information Technology in Training and Education, APITITE’94, APITITE 94 Council, Brisbane.

Tatnall, A. (1997). ‘Building Executive Information Systems - Visual Basic for management: students’. The Place of Information Technology in Management and Business Education. Barta, B. Z., Tatnall, A. and Juliff, P. (Eds). IFIP / Chapman & Hall, London: 177-184.

Tatnall, A. and Davey, B. (1995). ‘Conceptual Development in an Object Environment’. World Conference on Computers in Education VI, WCCE/95, Aston University, Birmingham, UK.

Tatnall, A., Davey, B., Burgess, S., et al. (1998a). Management Information Systems - concepts, issues, tools and applications. Data Publishing, Melbourne.

Tatnall, A., Davey, B. and McConville, D. (1995). A Guide to Visual Basic. Data Publishing, Melbourne.

Tatnall, A., Davey, B. and McConville, D. (1997). Visual Basic for Business Applications. Data Publishing, Melbourne.

Tatnall, A., Davey, B. and McConville, D. (1998b). Visual Basic for Business Applications. (2nd edition). Data Publishing, Melbourne.

Tesch, R. (1990). Qualitative Research: analysis types and software tools. The Falmer Press, Hampshire.

Thomas, N. (1991). ‘Jubjub, the Glass Computer’. Computers - Contributing to Chaos or Change? Conference Proceedings; Computers in Education Group of Victoria. McDougall, A. (Ed). CEGV, Melbourne.

Thomas, N. (1994). The Alice Computer Simulator. Data Publishing, Melbourne. Thomas, N. and Tatnall, A. (1995). ‘Teaching Computer Programming and Architecture

with Simulators - Some Comparative Design Approaches’. World Conference on Computers in Education - WCCE95, Liberating the Learner, Conference Abstract Proceedings. Selwood, I., Fox, P. and Tebbutt, M. (Eds). Aston University, Birmingham: 54.

Thomas, W. I. and Znaniecki, F. (1927). The Polish Peasant in Europe and America. Knopf, New York.

Thomsett, R. (1993). Third Wave Project Management: a handbook for managing the complex information systems for the 1990s. Prentice Hall, Englewood Cliffs, NJ.

Toombs, W. (1978). ‘The Application of Design-Based Curriculum Analysis to General Education’. Review of Higher Education 1: 18-29.

Toombs, W. and Tierney, W. G. (1991). ‘Meeting the Mandate: Renewing the College and Departmental Curriculum’. George Washington University, School of Education and Human Development, Washington DC.


Turner, A. J. and Tucker, A. B. (1991). ‘Computing Curricula 1991 - Report of the ACM/IEE-CS Joint Curriculum Task Force’. Communications of the ACM 34(6): 69-84.

Tye, E., Ng, M. W., Poon, R. S. K., et al. (1995). ‘Information Systems Skills: Achieving alignment between the Curriculum and the needs of IS Professionals in the future’. DATA BASE for Advances in Information Systems 26(4): 47-61.

Udell, J. (1994). ‘Componentware’. Byte May 1994: 46-56. Vidgen, R., T. and McMaster, T. (1996). ‘Black Boxes, Non-Human Stakeholders, and the

Translation of IT through Mediation’. Information Technology and Changes in Organizational Work. Orlikowski et al. (Ed). Chapman & Hall, London: 250-271.

Vincent, A. and Ross, D. (1998). ‘Software: what are businesses using? Implications for computer education’. Journal of Computer Information Systems 38(4): 75-77.

Vogel, D. R. and Wetherbe, J. C. (1984). ‘MIS research: a profile of leading journals and universities’. Database (Fall, 1984): 3-14.

Walsham, G. (1993). Interpreting Information Systems in Organizations. Wiley, Chichester.

Walsham, G. (1995). ‘Interpretive case studies in IS research: nature and method’. European Journal of Information Systems (4): 74-91.

Watson, E. F. and Schneider, H. (1998). ‘Integrating the SAP R/3 System into an MIS Program’. Association for Information Systems - 1998 Americas Conference, Association for Information Systems, Baltimore, USA.

Watson, R., T., Kelly, G. G., Galliers, R. D., et al. (1997). ‘Key issues in information systems management: an international perspective’. Journal of Management Information Systems 13(4): 91-107.

Weiss, R. (1999). ‘Facing Frankenstein ...’ The Age, Melbourne: 24. Wertheim, M. (1997). ‘The Love of Technology Bites Back’ 21-C. 1-97: 80-81. Wetherbe, J. C. (1988). Systems Analysis and Design. (3rd edition). West Publishing, St

Paul. Whatmore, S. and Thorne, L. (1997). ‘Nourishing networks: alternative geographies of

food’. Global/ising food: agrarian questions and global restructuring. Goodman, D. and Watts, M. J. (Eds). Routledge, London: 287-304.

Wiersba, R. K. (1991). ‘Business Information Systems in Transition - the Challenge for Academia’. Journal of Computer Information Systems Winter 1991-92: 50-55.

Williams, M. (1922). The Velveteen Rabbit, or How Toys Become Real. Heinemann, London.

Winner, L. (1977). Autonomous Technology. MIT Press, Cambridge, MASS. Winner, L. (1985). ‘Do Artifacts have Politics?’. The Social Shaping of Technology.

Mackenzie, D. and Wajcman, J. (Eds). Open University Press, Milton Keys. Wolcott, H. F. (1988). ‘Ethnographic research in education’. Complementary Methods for

Research in Education. Jaeger, R. M. (Ed). American Educational Research Association, Washington, DC: 187-250.

Wood, L. and Davis, B. G. (1978). Designing and Evaluating Higher Education Curricula. American Association for Higher Education, Washington.

Wood-Harper, A. T., Corder, S., Wood, J. R. G., et al. (1996). ‘How we profess: the ethical systems analyst’. Communications of the ACM 39(3): 69-80.

Woodhouse, D. (1992). ‘Personal communication’, Hong Kong. Wysocki, R. K. and Young, J. (1990). Information Systems: Management Principles in

Action. John Wiley and Son, NY. Yaffe, J. (1989). ‘MIS Education: A 20th Century Disaster’. Journal of Systems

Management April 1989: 10-13. Yin, R. K. (1984). Case Study Research - Design and Methods. Sage Publications, London.


Yin, R. K. (1994). Case Study Research, Design and Methods. (2nd edition). Sage Publications, Newbury Park.

Yourdon, E. (1996). ‘Java, the Web, and Software Development’. IEEE Computer 29(8): 25-30.

Zmud, R. W. and Apple, E. L. (1992). ‘Measuring Technology Incorporation/Infusion’. Journal of Product Innovation Management 9(2): 148-155.

Zuboff, S. (1988). In the Age of the Smart Machine. Basic Books, New York.


Appendix A

RMIT University

The institution now known as RMIT University opened its doors to students in June 1887 as the Working Men’s College (WMC). A campus was set up in central Melbourne and, in the beginning, the college was essentially an evening institute which taught a wide range of subjects on demand (Murray-Smith and Dare 1987). The WMC quickly proved popular with students and by the mid-1890s enrolments had grown to about 2,000 students per term. The college’s first director was Frederick Campbell, a former engineer. Unlike its London namesake which was devoted to “literary subjects, Christian principles and the humanities” (RMIT 1997b), the Working Men’s College in Melbourne was more concerned with general and technical education. A number of different technical, scientific, commercial and cultural subjects were initially taught including applied mechanics, surveying, physics, physiology, book keeping, shorthand, violin and elocution. The WMC also taught elementary school English and arithmetic, and trades such as carpentry, plumbing and gas-fitting (Murray-Smith and Dare 1987). In 1899 the WMC began to offer full-time diploma courses in engineering and in applied science. From early times the college pioneered practical trade teaching of printing, plumbing, gas-fitting and carpentry, using its own workshops. Murray-Smith and Dare (1987) note that at the time this was a controversial step as many people believed that only theory should be learned in college classes. In 1934 the WMC changed its name to Melbourne Technical College and in 1954 to the Royal Melbourne Technical College. During the 1950s the college developed new courses in food technology, transport studies, accountancy, real estate and advertising. In 1960 it adopted the name Royal Melbourne Institute of Technology (RMIT).

Universities and Colleges of Advanced Education Creation of the Binary System in the 1960s In 1961 two things occurred that were important to all the technical colleges. In the first of these the Victorian Government asked A.H. Ramsay (a retired Director of Education) to set up the ‘Committee for Development of Tertiary Education in Victoria’. Secondly the Commonwealth Government set up the ‘Commonwealth Committee on the Future of Tertiary Education in Australia’, chaired by Sir Leslie Martin. The report of the Martin Committee, published in August 1964 and presented to Parliament in March 1965, recommended the establishment of a binary system for tertiary education involving the creation of a number of new Colleges of Advanced Education (CAEs) to operate alongside the existing universities. The report recommended that the established universities would remain as highly academic, research-based institutions, and the new CAEs would be initially restricted to a teaching role. The CAEs would be allowed to award only diplomas and were not to be offered research funding. Rasmussen (1989) notes that prior to the Martin Report the Victorian Technical Colleges were the most highly developed and regarded in Australia, and that they greatly influenced Martin’s conclusions. The Martin Committee proposed that the new CAEs were to be “equal but different” (Rasmussen 1989 :142), offering their own style of tertiary education somewhat different to that of the universities. John Gorton, then Commonwealth Minister for Education, is quoted as saying at a public meeting at RMIT that the colleges should be:


“... biased more towards practical attainment in some specific form combined with general education, and less towards pure scholarly research.” (Murray-Smith and Dare 1987 :389)

In 1965 RMIT became a College of Advanced Education and a member of the Victoria Institute of Colleges. The non-tertiary parts of RMIT were then reconstituted as RMIT Technical College (RMIT 1997b). Universities and CAEs - The ‘Dawkins’ Amalgamations Over twenty years later in 1987 John Dawkins, at that time Commonwealth Minister for Employment, Education and Training, released a discussion paper on higher education. In July 1988 this appeared as a policy ‘White Paper’ (Dawkins 1988) which recommended, among other things, the abolition of the binary divide between universities and Colleges of Advanced Education and the reduction, by merger, of the number of institutions designated as universities. In 1990 RMIT, Footscray Institute of Technology and Western Institute began working towards a merger that was intended to form Victoria University of Technology, but in 1991 RMIT withdrew and Footscray Institute and Western Institute alone formed the new university. In July 1992 RMIT amalgamated with Phillip Institute of Technology and the new enlarged RMIT was then granted university status (RMIT 1997b).

The Birth of Information Systems at RMIT116 The teaching of accounting as a professional subject had its origin in Melbourne in the 1930s when A.G. Robinson, an accountant in private practice, began conducting evening classes in his offices in the city, at Footscray Technical College, and then at Melbourne Technical College (Murray-Smith and Dare 1987). These courses were to prepare students for the examinations of the various institutes of accountants. In 1944 at Melbourne Technical College the recently established Department of Commerce offered three-year courses for students wishing to gain admission to the Commonwealth Institute of Accountants. Completion of a fourth year gave students a Diploma, but the majority were happy with the three year course (Murray-Smith and Dare 1987). In 1962 the Head of RMIT’s Mathematics Department, Hartley Halstead, began to give serious thought to computing after being offered a used computer at a substantially reduced price. He was then instrumental in the setting up of a computer committee that soon granted approval in principle for the Institute to acquire a computer. An Elliot 803, at that time regarded as a medium-sized computer, was obtained under a hiring arrangement over five years. This arrangement gave Elliot the right to let out the computer’s excess capacity on a commercial basis during this period. The arrangement inevitably produced some conflicts.

“No institute staff were involved in the computer’s day-to-day operation, a matter of some concern to the institute. In 1964, in an attempt to bring the centre more firmly under institute control, the Computer Centre was officially linked to the Department of Mathematics. Two years later the centre was still without any full-time institute staff.

The Department of Mathematics was responsible for mathematical, scientific and technological applications of the computer while the other major user, the Department of Accountancy, was responsible for commercial data processing. Four hundred students were studying computer subjects in 1965. It was decided to investigate the purchase of a larger, more up-to-date computer.” (Murray-Smith and Dare 1987 :344)

116 Much of the material in this section is adapted from my unpublished MA thesis (Tatnall 1993).


Geoff completed a Diploma of Physics at RMIT in the early 1960s. While studying at RMIT he also held the position of Secretary of the Student Representative Council and so managed to get into a course in Algol117 programming intended for RMIT staff, when the Elliot 803 computer118 arrived in 1962. Geoff then undertook a machine code course, after which he went out to Caulfield Technical College and took some subjects out of one of the courses offered there. About this time he decided that computing was more interesting than physics, looked around for some jobs, and took up a position at Monash Computer Centre (Geoff 1992). An example of RMIT computing curricula in the early 1970s is seen in the course in Data Processing offered in 1971 by the Department of External Studies. It contained the following topics: 7KH %XVLQHVV (QYLURQPHQW, )LOH 3URFHVVLQJ &RQFHSWV, /HYHOV RI 'DWD 3URFHVVLQJ 6\VWHPV, 0DQXDO 'DWD3URFHVVLQJ 6\VWHPV, 6HPL�$XWRPDWHG 6\VWHPV, )XOO\�$XWRPDWHG 6\VWHPV, (OHFWURQLF &RPSXWHUV, 3UDFWLFDO $SSOLFDWLRQV RI ('36\VWHPV, and &RPSXWHU 3URJUDPPLQJ (RMIT Department of External Studies 1971). The Department of Mathematics and Computer Science had, up until the late 1970s offered what was basically a mathematics degree with some computer science subjects: &RPSXWHU6FLHQFH, ,QGXVWULDO 6\VWHPV, and (OHFWURQLFV DQG &RPSXWHUV. ‘The Bachelor of Applied Science (Computer Science)’ course had grown out of the fellowship diploma course (with only a few minor changes), which had in turn derived from the still earlier mathematics fellowship diploma. Schaefler, an RMIT lecturer, describes the department’s resources in 1972 as follows:

“Computer equipment at RMIT consists basically of an I.C.L. System 4-50 with 196 kbytes of core, four R.D.S. and six M.T. units, card and paper tape readers, paper tape punch, incremental plotter and line printer. Fast in-core compilers are expected shortly. A number of on-line terminals are expected to be available to users in 1972, including one terminal to be located at the Department of Mathematics and Computer Science.” (Schaefler 1972)

By the late 1970s this course was to change to become a true Computer Science degree. In 1978 Geoff was offered a six months contract lecturing position which later became permanent. A computing specialist had recently been brought in from Caulfield Technical College as ‘Principal Lecturer in Charge of Computing’ to head up the computer group, but when a new Department of Computer Science was created in 1981 he was not appointed to head it. This position was re-advertised several times and eventually filled by Tony Montgomery from Monash University in 1982 (Geoff 1992). Until this time RMIT had offered little in Information Systems but, perhaps somewhat perversely, the new Computer Science degree was to put around 70% of its graduates into positions in business.

“The course did not have much in the way of business subjects, but it was still really preparing people for careers in business.” (Adams 1991)

The new Department of Computer Science was initially very “under-resourced” (Geoff 1992). Geoff remembered Montgomery, the new Head of Department, demanding that he needed eighty terminals, not the five currently available. Unfortunately, those who would have to pay for the upgrade considered this an outrageous demand (Adams 1991) and it took much argument and some years before the department was adequately equipped. Geoff attributed much of the credit for this to Montgomery’s constant pressure. In 1985 Montgomery took up the newly created position as Head of RMIT’s Information Technology Division. Geoff (1992) related that elements at RMIT had been keen to create a 117 Algol was an early computer language. Pascal was developed from Algol. 118 A 40-bit serial machine using paper tape, and fairly slow according to Adams (1991) .


Faculty of Computing but had been unable to get agreement from all the parties involved. Computer Science had no objection, but the Engineers did not want to lose their computing staff and the group from the Faculty of Business also did not want to be a part of any such faculty. The compromise position was to establish an IT Division which was intended to be a matrix grouping that would drive all the departments involved in computing in a common direction. RMIT’s idea of an IT Division was unique in Victoria and Geoff believed that it worked ‘pretty well’ for a while, but that in the end ‘democracy’ created problems. Montgomery originally worked with the heads of the groups (or departments) concerned, with whom he met once every couple of weeks. Then the Academic Board insisted on the inclusion of staff representatives, resulting in a new group of 20-30 people. This turned out to be quite unworkable and the Division was disbanded in 1990 (Geoff 1992). Since the early 1970s most of RMIT’s computing had grown up as Computer Science, in the Faculty of Applied Science, rather than in business. The Business Faculty had been teaching Information Systems subjects back in the mid 1960s but had no formal courses in computing. In 1978 the Faculty of Business’s Department of Administrative Studies began its first computing course: the ‘Graduate Diploma in Computer Studies’. By the early 1980s, Geoff had been promoted to Senior Lecturer in Computer Science. In Business, the Department of Administrative Studies had a computer group and a principal lecturer had recently been recruited from ‘down town’. He had been given a mission to “clean up the act, and to get hard service subjects” (Geoff 1992). According to Geoff he was told:

“You are teaching Cobol programming to bloody accountants and you’ve got to make it hard. The reason for making it hard is that they have got to know it, and to know that computing is a non-trivial thing.” (Geoff 1992)

Failure rates were 40%, he could not get used to RMIT politics and left within a year. Geoff was asked to fill the position on a temporary basis, but then stayed on. Some years later, in 1987, a separate Department of Business Information Systems was set up with Geoff at its head. Geoff related that as a latecomer to the area of Information Systems the department decided “not to take on Chisholm at producing Cobol programmers” (Geoff 1992) but to go for a niche market, catering to an intelligent user approach. They were looking for people like the accountant who had been told that next year her company was to buy a million-dollar computer, and that she should go and find out about computing. The way that the department got its degree course is also interesting. Geoff related that RMIT had run ‘brilliant’ Secretarial Studies degrees and graduate diplomas in the 1960s and 70s and had an outstanding reputation in this area. In the late 70s, a razor gang went through it and said “well Secretarial Studies is not really degree stuff so it’s going” (Geoff 1992). An attempt was then made to redefine the course as an Office Systems degree. Geoff said that this was “an appalling degree, very badly structured” (Geoff 1992), but it was a good shell, it was running, and it had EFTSU119. With the creation of the new department this course became Geoff’s responsibility, and he turned it into the ‘Bachelor of Business (Information Systems)’. A ‘Master of Business (Information Technology)’ was put together as a course-work masters in 1988.

119 Equivalent Full-Time Student Unit - student places.


Montgomery regretted that it was not possible for the Departments of Computer Science and Business Information Systems to work more closely together.

“What should be taught to a Business Information Systems person is in many respects what we are teaching to our Computer Science students: information processing techniques. There should be one decent systems analysis course at RMIT.” (Montgomery 1992)

In criticising the view that computing should be taught in a different way to Business and to Computer Science students, Montgomery said that:

“Exactly because you teach in a different way is a reason why they will not be able to communicate one to the other. Surely we need to use the same language. Our guys need to know how your guys think and there will be a big plus if we have all in the one class instead of having two different cultures. The opportunity to have a closer coupling between their students and our students, between their staff and our staff, the opportunity to use our resources more effectively, to really have excellent teaching materials ... has been lost.” (Montgomery 1992)

In 1975, in the forward to their new text Introduction to Computer Based Information Systems, Cougar120 and McFadder (1975) noted that curriculum in the field of computing was changing in the United States. They remarked that tertiary institutions, and particularly Schools of Business, were revising courses that had previously offered only computer programming and hardware concepts to include topics such as an introduction to systems analysis and design. They also stated that their book was intended for both users and practitioners, acknowledging that students studying functional areas of business such as accounting, or management also required a knowledge of computing.

“They need the same foundation course as students who plan to become practitioners in the systems design field. With this common background, the user and practitioner will be able to communicate better in order to produce effective systems.” (Cougar, Davis et al. 1995 :viii)

The similarity of these views to those espoused above by Montgomery should be noted. Maynard (1990) also considered that computing at RMIT had always been quite fragmented with Engineering, Business and Applied Science each holding on to their own bits. He believed that “it is just territorial matters that keep them separate” (Maynard 1990).

RMIT’s Educational Quality Assurance System Australian universities receive most of their funds from the Commonwealth Government and so have little choice but to respond to important government initiatives. This is particularly the case on matters concerning the quality of their educational offerings, a subject which was brought into prominence by a 1991 government policy statement entitled ‘Higher Education: Quality and Diversity in the 1990s’ (Baldwin 1991) which outlined measures intended to improve the quality of university research and teaching in this country. Following this policy statement, in 1992 the Higher Education Council produced a report – ‘Higher Education: Achieving Quality’ (Higher Education Council 1992) recommending establishment of a special quality assurance mechanism to review the operations of Australian universities. The Committee for Quality Assurance in Higher Education (CQAHE) which resulted from these recommendations then proceeded to conduct three rounds of ‘quality reviews’ of Australian universities between 1993 and 1995. These reviews were into both the process and outcome of all the major activities in which the

120 Twenty years later Daniel Cougar was involved in the design of IS’95 (Chapter 2).


universities engaged. The three rounds were focused as follows (Bricknell and Bowden 1997):

1st round, 1993 - overview of teaching, learning, research and community service 2nd round, 1994 - teaching and learning 3rd round, 1995 - research and community service

RMIT had no option but to respond to the Commonwealth Government’s requirement for universities to be audited by CQAHE and so set up a system of Educational Quality Assurance in response. The concept of making improvements to educational quality was, however, not new to RMIT (Bowden 1997b) which first set up an Educational Development Unit in the late 1960s. After the first CQAHE quality round in 1993, RMIT needed to think out and design a suitable response to educational quality assurance in readiness for the second round in 1994. From July 1993 to February 1994 Bowden undertook the task of going around the university to speak to Faculty groups about the need to introduce some sort of EQA system, and discussing how this might best be done. In May 1994 a proposal to Academic Board by Bowden and Knowles (1994) resulted in RMIT setting up EQAC (Educational Quality Audit Committee) and in the adoption of a new EQA system. The system had seven key elements:

y The focus is on educational programme (degree course) teams working together to continually improve the quality of teaching and learning and taking responsibility for that quality and its evaluation.

y Course Teams are expected to engage in continual improvement of student learning experiences and learning outcomes through attention to teaching, curriculum, assessment and course management issues.

y The continual improvement processes and their outcomes are fully documented for each course in an Educational Quality (EQ) Log.

y Development support is provided through a Director of Teaching Quality in each Faculty, in liaison with the Office of the Director, Educational Quality Assurance, Research and Development (now Educational Program Improvement Group), to ensure that such improvements are soundly based in terms of pedagogical theory and evaluation practice.

y Brief summaries of each document in the EQ Log are recorded on a centralised Educational Programme Quality Management (EPQM) computer file developed for the purpose; this file also contains student performance data and is used to monitor the progress of quality improvement processes within each course so that timely support can be given in a targeted fashion.

y Each course is audited once every five years. y The course quality assurance processes are intended to be linked to the

University’s strategic planning, performance planning and academic promotion procedures to minimise duplication of effort by academic staff. This process has become more coherent since the adoption by Academic Board in August 1995 of an RMIT Teaching and Learning Strategy.

(Bowden 1997b :6) All those involved in the design and development of RMIT’s system of educational quality assurance go to pains to point out how this differs from industrial concepts of Total Quality


Management (TQM). They reject ideas like those expressed in the United States by Izadi, Kashef and Stadt who suggest that:

“TQM concepts may be used to improve qualities of an education system” (Izadi, Kashef et al. 1996 :7).

Bowden (1997b) notes that as the TQM notions of product, manufacturer, supplier and customer do not easily relate into the university context, TQM concepts seem to have little to offer higher education. In an explanatory document Bowden and Boyle (1995) note that the system incorporates two major objectives: to maintain the autonomy of the education professional, and to allow RMIT to publicly demonstrate accountability in the evaluation and improvement of its educational programs. Bowden further enunciates this as follows:

“Furthermore, the RMIT EQA system is in the form of a framework, with the majority of the activities undertaken being at the discretion of the academics who teach the courses. The system has been designed to achieve a balance between the autonomy of the academic as a professional and control by the organisation which carries formal responsibility for the conduct of activities within it.” (Bowden 1997b :2)

Course Teams and the EQA Process One of the consequences of the introduction of the EQA system was a requirement for each academic department to set up appropriate ‘Course Teams’ to oversee the operation of each degree or diploma program. As related earlier a Course Team is typically composed of the subject coordinators of each subject offered in the course and is normally chaired by the Course Coordinator. Course Team meetings are held regularly to discuss teaching and learning issues related to the particular course (Benjamin and Bricknell 1997). RMIT’s EQA system is evidence-based which means that Course Teams need to establish Quality Improvement Cycles (QIC) of design, reflection, change and evaluation. They need to accumulate and document evidence of the strengths and weaknesses of current programs, and to develop appropriate course change processes. All documentation is collected into an Educational Quality Log, more commonly known as a Course Log (Bowden 1997b). The Course Log is made up of Teaching and Course Quality Improvement (TACQI) files and Course Management Performance (CMP) files. These files consists of surveys, analyses and reports, minutes of Course Advisory Committee and Staff-Student Consultative Committee meetings, papers and reports from Course Team meetings, and data demonstrating student performance. Another aspect of quality documentation is the Educational Program Quality Management (EPQM) computer file which is used to centrally store a summary of the data contained in each of the Course Logs. The intended purpose of the EPQM file was to provide a brief summary of important aspects of each Course Log with reference links to relevant parts of these documents. It was envisaged that the EPQM file would be used both by individual Faculties and by the EQAC itself to monitor the progress of quality improvement (Boyle 1995). Each Course Team Leader has responsibility for ensuring that the EPQM file is regularly updated. Course Reviews An integral part of the EQA process is a regular ‘Review’, every five years, of each course in the university. The purpose of the Review is to evaluate the quality assurance processes in relation to each specific course. The review committee is composed of two or three


reviewers who are normally academics from other departments or from Bowden’s group. The review committee looks at whether an ‘appropriate’ quality assurance process has been followed by the Course Team in relation to the course under consideration. The Review does not so much look at what has been done by the Course Team as at how it has been done. Members of the Review Team are

“... selected on the basis of demonstrated qualities and areas of expertise with which they will enhance both the evaluative and developmental aspects of the Course Review.” (Benjamin and Bricknell 1997 :17)

As such, they will often know little of the academic content of the course they are reviewing, but as the review process looks at processes and not content, this presents no problems. In 1996, Fred was selected as a Course Reviewer and has now sat on a number of Review Panels for non-business courses. Different Opinions on EQA’s Virtues There is however, some difference of opinion among academic staff on whether or not the complexity of the EQA process might act to inhibit change. A number of academic staff from various departments still see RMIT’s system of EQA as a “Machiavellian attempt to regulate and stifle professional freedom in course design and teaching” (Patricia 1997). Given the size of the institution, the diversity of its staff, and some mistakes made in EQA implementation, this view is understandable even though many would claim that current use of the system does little to support it (Fred 1997a). Another criticism of the system is the amount of time it takes to document the activities required, as the operation of the EQA system means that everything relating to a course is now documented. This includes course outlines, subject descriptions, assignments, resources and examination papers. Concern with the EQA process when it was introduced extended also to the Course Advisory Committee which, at its April 1997 meeting, passed the following motion of concern:

“Whilst the Committee agrees with the philosophy of quality improvement, the Committee is concerned about the cumbersome and bureaucratic nature of the process which is detracting from the delivery of quality within the department.” (RMIT Department of Business Computing Course Advisory Committee 1997a)

In 1997 the Bachelor of Business (Business Information Systems) was to undergo a Quality Review when Paul, Course Coordinator, was asked about the effect of EQA on curriculum innovation. His response was quite strong and clear:

“What would I be doing this year if it wasn’t for the Review? I would probably be involved in two or three new curriculum initiatives like developing modelling tools for VB. Instead I’m doing this! I think in this department, because of the amount of time it is taking up for different people – and it is often the key people, the team leaders that are having their time occupied - new developments are not going to happen. They won’t come out of my office this semester for sure.

So it may be that the quality goes down because of the quality assurance, but certainly the paperwork to prove you have quality greatly increases.” (Paul 1997a)

On the other hand the Faculty of Business’s Director of Teaching Quality suggested that EQA facilitates small incremental curriculum changes but not large ones. He maintained that this was the case because “inertia works in favour of what you did last time” (Roy 1997). Fred contended that the EQA system actually improves the process of curriculum development by making it more systematic.


“I think it makes improvements steadily upwards, I think we had random change in the past – people made changes because they thought it was a good idea, everybody who took over a subject would reinvent the wheel – when you took over a subject the documentation wasn’t there for why things had happened in the past, so instead of making a change with due regard to the reasons for things being there, you made change in a vacuum. There was a lot of vacillation, so it’s an improvement in that respect. Also, because the Course Team formally involves everyone who is teaching in the course, it means that there is a bit more ownership of the course as a course, whereas in the past it was a gang of unrelated subjects, and there were things like unnecessary duplication of content.” (Fred 1997a)

Fred (1997a) noted that any course change involving, for example, altering the programming language used in a programming subject, could now not be made by the lecturer teaching that subject acting alone. The lecturer would first need to go to the Course Team meeting and argue a case for change. Assuming that the Course Team agreed that this was a good idea it would then be minuted as a course change for EQA purposes before the change could proceed. If a strong argument could not be sustained and the Course Team convinced that the change was desirable, then the change would be disallowed.

RMIT: Then and Now For over 110 years RMIT has played an important part in higher education in Victoria and Australia. From its beginnings as the Working Man’s College to the granting of university status over 100 years later in 1992, RMIT has offered its own distinctive brand of technological higher education focussed on producing graduates to satisfy the needs of industry and commerce. Today, RMIT is a large dual-sector tertiary institution of over 45,000 students, including around 5,000 from Malaysia, Singapore, Hong Kong, Vietnam, People’s Republic of China and elsewhere overseas121.

121 This brief description of some aspects of Business Computing at RMIT can be supplemented from

information on RMIT’s web pages at: http://www.rmit.edu.au/About/ and http://www.rmit.edu .au/About/ hotTYPEv1n1/keydates.htm


Appendix B

Visual Basic Development History

Visual Basic began its life in 1987 as a product called Tripod that was written as a shell program for Microsoft Windows by Alan Cooper. Strongly disliking the visual interface offered in Microsoft Windows 2.0, Cooper (1996) had seen a need to produce a better interface than that offered by Microsoft. His idea was to create a palette of tools, including push-buttons and list-boxes, and allow the user to create forms and populate them with instances of these tools. The interface was manipulated by dragging and dropping the tools, called ‘gizmos’, onto the form. It came with its own small programming language. In 1989 Cooper changed the product’s name to Ruby, and shortly after he sold it to Microsoft which intended to include it as the shell for Windows 3.0. After looking more carefully at the product’s potential, however, Bill Gates decided to convert it to a visual programming language by adding the Microsoft QuickBasic programming language. Later, this new product appeared commercially as Microsoft Visual Basic (Cooper 1996).

“I was the original inventor of Visual Basic’s visual programming interface. I sold this to Bill Gates in 1988, he added QuickBasic to it, and Visual Basic was born. I like to say that ‘I did the visual, Microsoft did the Basic.’ For this feat, I have been given the sobriquet ‘The Father of Visual Basic’. All swords have two edges, and Visual Basic is my sharpest two-edged sword. I now have the fabulous convenience of a one-phrase resume. All I need to say is ‘Father of VB’ and I have established my bonafides. On the other hand, I am now a creature of Visual Basic, a product that I have had no contact with nor influence on since 1990. Still, as goes VB, so go I. As luck would have it, Visual Basic is experiencing unprecedented success, but it would be disingenuous of me to take credit for that success. Certainly many, many creative, intelligent people at Microsoft have labored long and hard to make VB the success that it is. I tip my hat to these individuals.” (Cooper 1996)

“Visual Basic for Windows has been Microsoft Corporation’s most successful programming language product, as witnessed by world-wide sales of more than two million copies (by 1996). Microsoft’s original objective for Visual Basic was to expand the market for Windows 3.x by providing a means for fledgling programmers to create their own Windows applications without having to learn the C programming language. Microsoft achieved this goal with Visual Basic 1.0.” (Jennings 1996 :4)

By 1999 Visual Basic had evolved to version 6.0, a new version coming onto the market every eighteen months or so as shown below.

July 1991 Visual Basic 1.0 (for Windows) Standard edition October 1992 Visual Basic 1.0 for DOS Standard and Professional editions December 1992 Visual Basic 2.0 Standard and Professional editions July 1993 Visual Basic 3.0 Standard and Professional editions November 1995 Visual Basic 4.0 Std, Pro and Enterprise editions March 1997 Visual Basic 5.0 Std, Pro and Enterprise editions August 1998 Visual Basic 6.0 Std, Pro and Enterprise editions From 1995, with the inclusion of Visual Basic for Applications (VBA) as the macro language in all Microsoft Office applications, Visual Basic has taken on added importance. In 1999 Visual Basic is still selling well, is used extensively in commercial programming, and is taught in many university computing courses.

Date post:	11-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times