Reprinted from MUG QUARTERLY, Vol. XIII, Number 3/4. The MUG Quarterly has been replaced by M Computing which is published by:

M Technology Association
1738 Elton Road, Suite 205
Silver Spring, MD 20903 USA
Phone 301-431-4070
Fax 301-431-0017
Email mta@mtechnology.org
Website www.mtechnology.org

The OCR process may have introduced errors. Other than a spell check, the contents of the original document has not been changed, although the document has been formatted.

Software Engneering, Programmer Productivity and System Performance

End User Software Engineering: The Experience of the Veterans Administration Decentralized Hospital Computer Program

The automation of 169 Veterans Administraion (VA) hospitals will put powerful computing tools into the hands of nearly 200,000 end users. This paper describes those tools, how they are implemented, and how the VA is organizing this major effort. The methods and lessons have industry-wide implications for the management of the End User Computing (EUC) revolution. They reflect a transformation of the DP manager from quarterback to coach and Suggest the technical and organizational characteristics of a language which bridges the communications gap between end user and DP personnel.

Preface

Data processing professionals are gradually adjusting to the growing numbers of "end users" and their low-cost small computers. Though armed with powerful modern hardware the typical end user has little or no ADP background or training. This poses a number of questions. How should DP management deal with this movement? What does the DP professional have to offer the end user?

Many data processing professionals consider the phrase "end user software engineering" to be a contradiction in terms; end user computing is by definition pre-packaged or 'pre-engineered.' How can novices engineer software? Why suggest marrying these two recent developments in the ADP field? In the view of many, the end users should stick to their package software and leave data processing to the professionals.

A number of recent trends in data processing suggest that "end user software engineering" may be more than the concatenation of two buzzwords. For example, over the past two decades there has been a sharp drop in hardware price/performance ratios. Mean while we have seen a steady rise in the cost of labor-intensive software; the supply of programmers has lagged far behind the demand for their efforts. If we continue business as usual, James Martin says we will be in the absurd position of needing 20 million programmers by the year 2000. [7]

This leads to another trend: the growing ADP expectations of users: society is entrusting more and more critical decisions to increasingly complex systems. Many of these systems are far beyond the grasp of any single person. Yet, traditional software methods are tedious and error prone exercises in communications, not just with the computer but. more significantly, between programmer and end user. The combination of increased complexity and archaic methods will force us to commit a growing percentage of scarce human resources into maintenance at the expense of new systems. Thus, we need a major productivity breakthrough to prevent a breakdown in the performance of services crucial to our society.

One response is to rethink the role of the data processing professional: moving the DP manager from quarterback to coach. Frustrated by not being allowed to participate, the users are coming down from the stands onto the playing field. With pentup enthusiasm, they are executing the plays and sometimes even calling the plays. As coaches, the data processing professional will move to advising users and guarding the effectiveness of user tools and methods.

Many have cited the promises and perils of end user computing (EUC). On the positive side, we have heard that EUC will get the easy but time consuming jobs out of the DP queue. Also we are told that EUC will economize on scarce skilled DP personnel while customer autonomy will improve customer awareness and customer satisfaction (or dissatisfaction). Finally, EUC implemented tasks promise to yield clearer prototypes and more stable user requirements. If all goes well, EUC may generate the productivity gains the DP industry desperately needs.

Weinburg's essays on the microcomputer revolution [12] give insights into the pitfalls of EUC. He and other DP managers feel great frustration as end users repeat the history of data processing once again; end users are committing all the errors of the DP profession of the past three decades:

• ill defined and unrealistic objectives
• hasty design
• rush to write code
• failure to plan for follow-on requirements
• inefficient code and wasted storage
• little or no documentation unverified algorithms
• lack of concern for maintenance
• inadequate technical support to other users

Without the watchful supervision of experienced DP managers, applications can bestow job security to the amateur designer) implementer, but confusion to other users and the DP department. Another frustration comes when critical applications are suddenly thrust onto DP shops when the end user/developer leases: the DP staff is expected to overcome poor design, documentation, and implementation.

The primary objective of software engineering is to make good software ware on time at a reasonable cost. According to Bauer, software engineering is "The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines." [2] One indicator of software engineering would be a methodology, such as Life cycle management, for designing and implementing computer software. [5]

What are the characteristics of good software? We might expect the following:

reliability
maintainability
verifiability
portability
understandability
enhanceability
testability
utility

A good software engineering methodology would identify errors and encourage modifications at the earliest possible time. The cost of changes and mistakes rises dramatically with the stages of the development process. Deviations found during determination of need or documentation of requirements can usually be remedied inexpensively. However, once the system is in operation, the same problem can be quite expensive to fix.

Another common objective of software engineering is improved programmer productivity. But what do programmers do? Do they write programs? reports? files? data bases? Do programmers satisfy users? pacify DP managers? The nature of the programmer's output has inhibited efforts to measure their productivity. Software metrics, as they are called, have not yet captured the essence of "goodness." Lines of code, number of modules, number of programs and reports are poor productivity measures: DP shops find such quantitative indicators unreliable.

Measuring programmer productivity is difficult because the software development process is not well understood. There is Little consensus on what is good software and how it is produced. Since we lack a common methodology, we lack objective criteria. Therefore, we have trouble demonstrating the value of software techniques. Owing to the expense of experimenting with seasoned programmers, what little empirical evidence exists is based on research done on college students. Studies of production environments are rare because scientific research methods require doing the task repeatedly under controlled conditions. Thus. both government and business are too busy writing software to study the process.

Largely based on intuition, the following are judged to be valuable software techniques:

• structured programming
• code reading/desk checking
• modular coding
• top down design & development
• standard naming conventions
• chief programmer development team
• format standards (for code)
• ANS language standards
• removal isolation of hardware and system software dependencies
• in-code documentation
• parameters instead of hard code
• project management systems
• estimation/scheduling/costing models
• validation models
• programmer support libraries

II. BACKGROUND ABOUT THE NEEDS OF THE VA HOSPITAL SYSTEM

The Veterans Administration runs the largest health care system in the Free World. Its mission is to deliver quality medical care to the nation's veterans; about 190,000 employees filled 232 million prescriptions and performed 40 million procedures in 1982. This system includes 172 hospitals (VA Medical Centers or VAMCs) ranging in size from 100 to 1,200 beds with about 190,000 employees. Aside from the VAMCs there are 226 outpatient clinics, 98 nursing homes and 16 domiciliaries. Although the hospitals have common supply systems and policy. each has its own administration. Until recently, these institutions used manual records and processes.

Quality medical care has come to mean modern technology. Like other health providers, the VA hospitals need rapid information exchange. The first concern is the basics of managing the patient records -- admission,, discharge, and transfer. The latest patient medical abstracts must be available to several hospital clinics simultaneous!). This history assists medical professionals and hospital administration to nag patients for review and follow-up. The system should assist administrative staff in confirming the veteran's eligibility.

In light of public attention to the level of utilization of costly VAMC medical facilities, the system must support efficient scheduling of hospital resources. Staff must identify and assignments, match assignments, needs to facilities, eliminate scheduling conflicts, and minimize cost by making appointments for multiple clinic visits on the same day. (The VA provides transportation between home and hospital for many veterans.) To reduce 'no-shows,' the system must also generate automatic reminder letters to patients.

The administration of the clinical laboratories needs improvement. The goals of automation efforts are to reduce duplicate sating, get more accurate order entry and reporting, support automated interfaces to medical equipment, and generate better statistics. Likewise, the pharmacy needs to know of patient drug allergies and interactions and medication profiles. A system should streamline paperwork, improve drug stock management, and prevent fraud, waste and abuse. It should allow both ward stock and unit dose methods of dispensing medication.

Finally, the VA needs a system that will be flexible enough to permit future possibilities for better management of medical information resources. A VA-wide system would let the VA assess quality and consistency of medical care. A nationwide telecommunications network connecting these hospitals raises the following possibilities:

• sharing of records between hospitals
• automatic collection of descriptive statistics
• reporting of the latest big-medical research results
• access to state-of-the-art treatment protocols
• expert consultation within and outside the VA system
• access to medical literature in VA and non-VA computerized libraries
• eliminate duplication of patient services (re-ordering of lab work or medications before the first tests or prescriptions are received)

The central data processing staff allocated considerable resources and personnel, yet found these expectations difficult to satisfy. Initially the VA approached the hospital automation task by employing methods common to most civilian and military organizations: centralized software design, implementation, and maintenance with copies sent to each site. COBOL programs and due files were employed in a "one system fits all" solution.

When systems were installed. they were welcomed. However, the analysis, design, testing, and implementation stages of the traditional software engineering proved unsuccessful in producing in a timely manner a comprehensive, flexible system that fit the medical and organization requirements of the VAMCs. The COBOL software was capable but not responsive enough to the needs of hospitals; revisions were costly and time consuming. Implementations tailored to local needs were not feasible. Medical personnel resisted having to drop familiar procedures in favor of methods developed without, as they perceived it, adequate attention to their local and professional needs. The use of mainframes instead of mini-computers or micros appeared to keep computing resources from the purview of the local hospital administration. Frustrated with slow progress and administrative constraints. the VA's Department of Medicine and Surgery (DMS) took matters into its own hands.

How does the VA plan to achieve the contradictory goals of flexibility and coherence with a project of this size? Except for the three VAMCs to receive commercially developed systems, the Decentralized Hospital Computer Program (DHCP) is the VA's answer to balance freedom versus control. The strategy is centralized design and implementation of the CORE applications: admissions/discharge/transfer, clinic scheduling, pharmacy, and clinical laboratory. The CORE applications we" selected for their significance in the hospital operation and their procedural consistency across the VA hospital system. CORE provides a common technical and organizational foundation to the creative energy of the VAMC personnel. CORE is more than software; it and MUMPS are the language common to both medical and DP professionals. Not the property of either, they are the media for discussion, negotiation, and change.

MUMPS, the language used in writing the DHCP systems, is highly flexible and quite popular in the medical community. Numerous non-DP VA medical professionals have been attracted to the language and have written routines to use CORE data files and run them alongside CORE applications. Although VAMCs may see the CORE software, they are discouraged from changing it; the DHCP has a policy of "if you break it, you fix it." Nevertheless, VAMC system administrators have "programmer status" to facilitate their management of the applications. It reflects the philosophy of the DHCP that knowledge and power is delegated down to each VAMC; they believe the benefit from letting the VAMC see the example of the CORE code was greater than the risk of accidental damage or irresponsible behavior. Innovation and trust prevailed over security and control. However, this trust can be maintained only if the users have the opportunity to acquire skills and use them responsibly under centralized guidance.

Because system development is done in the hospital by staff accountable to the hospital administrator, the VAMC has both the authority and responsibility to implament and manage its information system. All 169 sites share the same hardware vendor, data naming conventions and standards for MUMPS routines. Thus, software developed at one hospital tan be transported to another. There it can be evaluated, modified, and tested in a 'live' organizational setting independent of the VAMC of origin.

The selection of the hardware and MUMPS implementation was conducted with a closely-observed fully competitive procurement. To stimulate competition, the VA grouped the VAMCs by size into five CPU classes. a strategy which could have resulted in five different hardware vendors and versions of MUMPS with the potential conversion and coordination problems. Instead, the VA got virtual DHCP-wide system compatibility at an excellent price. Digital Equipment Corporation won the award for the four largest configurations, using a deep discount pricing strategy intended to position DEC as equipment supplier to the VA medical system. The smallest systems were awarded to InterSystems Corporation which offered DEC equipment. Portability between these vendors does not appear to be a significant issue, although there is enough difference to discourage vendor specific MUMPS features.

Unless the VAMC changes are incorporated into CORE, the VAMC system administrators and the hospital staff know that their software must have a relatively clean interface with CORE. Changes to CORE made by a VAMC to permit local applications are discouraged and are recognized as impractical and even dangerous. But if access to the code is decentralized, changes will occur. Therefore, users must be educated about the significance of such changes, and administrative steps taken to limit their potential for damage. Every version of CORE arrives as a complete CORE system, not as separate "patches." Therefore, a new version will flush out local "fixes" to the last version of CORE, causing the local application to fail. Distribution of "patches" would allow CORE applications to diverge to the point where only a crisis could return the CORE to integrity VA-wide.

The organization supporting the DHCP reflects the philosophy of decentralization. The Medical Information Resource Management Office (MIRMO), under the Deputy Chief Medical Director for Operations, provides planning, policy, acquisition, coordination and ADP support from Washington. The six Verification and Development Centers (VDCs) conduct software design and testing and review VAMC ADP plans and requirements. However, MIRMO does not have direct authority over the VDCs; the six VDC Directors report to a Regional Director who in turn reports to the same Deputy Chief Medical Director. One VDC has lead responsibility for each CORE application and the changes thereto: the VDC in San Francisco is responsible for "the kernel:" the MUMPS systems. the VA File Manager (discussed below), and various utility programs.

CORE applications were developed by VAMC employees, with unit testing at the home VAMC. As they reached maturity, responsibility for the CORE systems was transferred to one of the six VDCs for system testing. The VDCs are staffed by DP professionals and medical professionals trained in MUMPS. The medical personnel prepare the documentation and evaluate the software for use in the variety of settings likely in the VAMCs. After testing at a small number of other VAMCs, the CORE application software was certified by the System Audit Staff of the Office of Data Management and Telecommunications, which is entirely independent of DM&S and DHCP. While this arrangement lasted, it provided a unique climate for rigorous inspection; few DP organizations submit their software to external scrutiny. Now, verification is done by another VDC.

There are seven Regional Medical Education Centers (RMECs) which are responsible for continuing education for most VAMC operations. The REMCs conduct high quality classroom instruction in complex medical technical fields. Although ADP is new to them. the REMCs have developed an extensive curriculum ranging from computer literacy to DHCP operations and system administration. To ensure the most realistic training environment possible outside of the individual VAMCs, each RMEC has a complete implementation of the DHCP hardware and CORE software for on site hands on training.

Although not formal VA organizations, the Special Interest User Groups (SlUGs) are integral to the success of the DHCP. Selected by the hospital administrators, SIUG members represent the user community in the establishment of DHCP software priorities, requirements, acceptance, and training. They have lead responsibility for data administration and the effectiveness of DHCP software are in meeting the needs of medical concepts and practice. The VDC personnel provide the SlUGs with coordination and technical advice, not supervision. DHCP-wide changes to CORE and distribution of local software are reviewed in a technical sense by the VDCs and sold in a political sense through the Special Interest User Groups.

There are two non-VA organizations which play tangential but significant roles in the success of the DHCP. The first is the MUMPS Users' Group (MUG) which conducts symposia, training, and conferences on he language and its applications: MUG publications are the principle source of documentation on MUMPS and its applications. MUG gives the MUMPS community considerable identity and connectivity. The second organization is the MUMPS Development Committee (MDC) which maintains the MUMPS ANSI standard and reviews vendor submissions for compliance. Periodically MDC revises the standards, documenting extensions that come into common usage. The MDC does not have the resources for an extensive validation capability.

III. WHY MUMPS?

MUMPS is an interpretive computer language used with a history of success in the medical community MUMPS (Massachusetts General Hospital Utility Multi-Programming System) started at that respected medical institution in 1966 but has since spread internationally to numerous applications far from medical care. Although COBOL and FORTRAN may have numerous applications in hospital settings, these languages are unfamiliar and 'owned' by a rival discipline: data processing. As Munnecke observed:

Therefore, objective comparison requires not only an understanding of each language but also an appreciation of the role of each language in influencing one's conceptual framework. Perhaps comparing COBOL and MUMPS is like comparing English and French; it can be done but the partisans will be unswayed by the outcome.

At the request of the House Government Operations Committee, the GSA Office of Software Development (OSD, since renamed the Of Office of Software Development and Information Technolgy) conducted a stud' of MUMPS in 1982. [1] The General Accounting Office prepared a shorter paper on the use of MUMPS. [3] Other papers by MUMPS ad vocates [4, 6, 8, 9, 11] emphasize its flexibility and power. What follows is a summary of the language's strengths and weaknesses as found by these sources and the author.

Like BASIC, MUMPS is an interpreter; each syntactically valid statement is executed immediately upon entry or as it is encountered in a file of statements. Interpretive languages are easier to use since they do not involve the user in job control language, a linkage editor, or a compiler. The users gets immediate reinforcement from commands instead of having to compile code and e evaluate the outcome. There is less syntax to remember so interpreters tend to be easier to learn.

However, MUMPS's embedded data base system is a remarkable advantage over BASIC, as well as most compiled languages. There is no interface or preprocessor between MUMPS and this feature. The user can move inperceptably from user defined variables to shared variables (called ‘globals') kept on disk. The requested globals are retrieved from disk and placed into the user workspace; the user does not need to remember syntax for l/O devices or even be aware of the concepts of input 'output and disk storage.

Even more important is that globals are data addressable relational data beas. The data elements of most applications are used as the data address in the global. This feature makes it often unnecessary that one assign a value to the addressed DBMS; all the information is elegantly kept in the address. For example, if the hospital kept a file of patient names, state of residence, and third part! insurer, the entry might be as follows:

PATIENT("HOUSER", "MARYLAND", "BLUE CROSS") = ""

The array is fully extensible without reorganization of the data structure. Data can be added without redefining the DBMS or affecting the organization of data already entered in the file. For example, this same file be augmented with data on my employer and organizational unit:

PATIENT("HOUSER","MD","GSA","AGENCY LIAISON")=""

Globals arc sparse arrays; one need not predefine the number of potential elements Since storage does not have to be preallocated, there is no need to fill the data base with null or zero entries. There are no field or element definitions which need maintenance.

As an interpreter with an embedded relational DBMS, MUMPS provides the user with a single all-purpose computing environment. There is only one set of syntax and semantics to learn instead of several. To clarify this, consider that comparable COBOL programming involves far more than just COBOL; it includes DBMS, JCL linkage editor, system macros, assembler language, and more. MUMPS on the other hand has a single set of syntax and documentation. This has a dramatic impact on the productivity of new and occasional users. MUMPS's shallow learning and relearning curves require far less specialization and permit more time for one to be something other than a DP professional.

MUMPS is an ANSI standard language which is implemented on a wide variety of hardware. Although GAO noted that the use of MUMPS could limit competition, in summer 1983 MUG reported 39 suppliers of MUMPS implementations, some providing more than one. These systems were implemented for 25 different hardware manufactures, some offering several equipment configurations, including for example: IBM PC and XT, IBM System 370, 43XX, 303X, DEC VAX 11/XX, PDP 11 /XX, Pro 350, Data General Nova and Eclipse, Harris, Tandem Convergent Technologies, Burroughs, Apple, and most UNIX and CPM-based equipment.

Indirection is a powerful MUMPS capability. Users can supply MUMPS code to the program dynamically during execution. Programmers can write programs to pass commands to executing code as the contents of variables. This feature is similar to, but more powerful than, the OBJECT command in SPEAKEZ, another interpretive language.

Because it is an interpreter, MUMPS has an inherent advantage over compilers when it comes to debugging the identification of the causes of unexpected results. Unless a problem is anticipated, the error conditions of a compiled program are usually lost; quite frequently the programmer must attempt to recreate the precise conditions under which the error occurred. This can be a tedious process that often puts the programmer and the user in an antagonistic relationship.

Oberst and Johnson show how MUMPS can be employed to solve problems quickly and avoid negative user relations. Before the user works himself into hysterics through futile repetitions of the command that revealed the programming error, the application terminates the session and advises the user to call Computer Services. All files and variables are saved exactly as they were when the problem occurred. The user may even be locked out until the problem is corrected. A message is sent to the owner/developer of the particular software, with the option to notify the console operator if the error is critical. With all the evidence promptly put in competent hands, often the problem is solved before the user contacts Computer Services [10].

The VA File Manager is another significant tool for developing and using MUMPS applications. Written with only 13 of the 19 commands of standard MUMPS, the File Manager is a package of routines which the end user employs to define a data base, enter and update the data, and retrieve and report the data. It also provides means for assigning various levels of security, validation of data, logging of transactions, and archiving inactive records.

The File Manager gives the task of developing a data dictionary to the person who knows the data bat: the end user. Through a question and answer dialogue, the user defines new fees and field names. A field can be one of the following:

• free text
• numeric
• date/time
• set (a set of discrete codes)
• pointer (to another file)
• computed (from other fields)

The last field type contains an algorithm that uses other fields, including eluding computed fields. Depending on the field type, the user is asked questions like: "is the field required to have a value for every entry?" and "how many decimal digits may the number have?" Only if the user identifies himself as an experienced MUMPS programmer, will the questions reveal more complex features of the MUMPS language.

Often, after entering a few observations, one encounters new data or discovers inadequacies in the original approach. For many languages and data base systems one must discard the original design and data or execute time-consuming revisions to accommodate unanticipated errors or conditions. But changing the File Manager data base design is nearly as easy as editing the data; text fields can be made into numeric and vice versa. When the definition is changed, File Manager flags all the nonconforming entries.

File Manager handles data entry with consistency: single-line queries with responses ending in a carriage return. Update and deletion uses the same sequence of queries as entry; the existing answer (or programmed default) appears. Entering a carriage return means no change, a space means ‘the same answer as above,’ and a "?" will provide the user with the programmed clarification for the prompt.

Data retrieval can be accomplished with Boolean queries (and, or, not) to select data to be reported. The user can specify the sort sequence desired. Report titles and headers are possible, though format control can become rather complicated.

Data security and integrity is provided by an access code assigned upon entering the File Manager. The user can only create or modify data and definitions in files created under his access code; unless the owner of the file specifically assigns read access, others will not know these fees even exist. The owner can permit others to add entries but not change existing entries. File Manager also supports the merger of files that use the same file names.

Being self-contained can be a liability as well as a virtue. Because it is an entire computing environment, implementers of the language have little need or incentive to tie it to other software systems. Because of limited interfaces with other languages, one must rely exclusively upon MUMPS for programming language, word processor, operating system, and data base manager. A weakness in any of these areas can not be corrected by moving to another software package; MUMPS like other integrated systems stems (e.g. Lotus 123, Context MBA) is expected to be all things to all users.

Another concern raised by the GAO [3] and GSA's Office of Software Development [1] is the lack of acceptance by the DP industry of MUMPS as a language. perhaps this is less indicative of a failing of a change in software technology. The GAO letter noted "... because of the diversity of applications used in Federal agencies, no one cat, base/quay language could meet enough general needs." [3] So-called fourth generation languages are more specialized than the general purpose pose languages of COBOL and FORTRAN. Because of their specialized nature, these languages will tend not to be as widespread.

However, of the fourth generation languages cited by the GAO (RAMIS II) and Martin (MAPPER, Easytrieve, NOMAD, and others), MUMPS has the broadest base of vendor implementations. The use of proprietary languages greatly limits the range of competition in the DP equipment market; this leads to higher costs, a matter of concern to GSA. Since fourth generation languages are clearly on the rise, Federal agencies should favor the use of those with a wide vendor base (such as MUMPS) over those with a much narrower implementation.

OSD expressed apprehension that validation by MCD of vendor implementations of MUMPS is voluntary, and the results are vendor confidential. Serious semantic problems result if the validation process is not rigorous. [1] MUMPS applications on one vendor's hardware may be executable on another's but the results may differ. This problem can limit portability and competition since software becomes too expensive to convert. To minimize the impact of this concern, the CORE software does not employ vendor specific commands, and DHCP standards prohibit them from use in applications. Finally, the DHCP systems are implemented on a single vendor's equipment, although two different MUMPS implementations were procured as a result of the DHCP acquisition strategy. Ensuring the semantic consistency of CORE is a major responsibility of the VDCs.

OSD was also concerned that MUMPS lacked software tools. Unlike compiled languages such as COBOL, interpreters have less need for dynamic debugging methods; pressing the break key interrupts execution and the contents of all variables are readily available in the user workspace. More significantly, MUMPS does not encourage readability; applications are usually written tersely. However, MUMPS programs can be PERFORMed, unlike BASIC's GOSUB command, so structured programming is possible. Nevertheless, owing to a lack of formal DP training, MUMPS programmers are more likely to write unstructured code, which is more difficult and costly to maintain. This can be a significant problem since maintenance is often from 60 to 70 percent of the budget of a DP shop.

The OSD criticized MUMPS' data structure as lacking non-numeric keys and the ability to define and manipulate data (fields) below the record level. For MUMPS users, the concepts of keys, records and fields are irrelevant. One can enter both alphabetic and numeric data as either the data address or its assigned value; all addresses are 'keyed' for retrieval using entries most familiar to the user: the data itself. Given the flexibility of MUMPS globals, there is nothing resembling a record to act as a barrier to the logical structure of the data base. The depth of the hierarchy or the breadth of the data siblings grows dynamically. As far as MUMPS advocates are concerned, fields, records, and keys are artifacts designed to overcome the deficiencies of less well-crafted languages.

Another common criticism of interpreters is their overhead; compilers are in general considered faster and more efficient than interpreters. Efficiency involves optimizing the use of resources to achieve a given output or maximizing the output given fixed resources. However, actual comparison of performance is quite complex. For instance, contrary to popular belief, a given hardware configuration (a DEC PDP 11/34) was found to support 11 VA users of the MUMPS based word processing package MULTIWORD compared to only three users of a FORTRAN based word processing system, although the latter appeared somewhat faster to the user. It is not clear whether this experience represents a more general conclusion.

The answer to the efficiency question can depend on the software, as well as the hardware, Some applications may be little more than compiled calls to a data base management system (DBMS) with the latter behaving like an interpreter; the benefits of compilation may be minimal compared to the sacrifice of semantic control of the program upon compilation. Additionally, some MUMPS implementations include compilers invoked without the user knowing it. The growing use of firmware and microcode may further blur the distinction between compilers and interpreters.

Moreover, efficiency in the traditional sense of machine time has become a minor concern; the big cost is the time of both DP and non-DP personnel. When people are Bating more expensive and hardware less so, it is good economics to use more hardware instead of costly programmers. This reality will propel the development of both compilers and interpreters perhaps to converge. The real issue is whether the organization finds one or the other more efficient; the answer often hinges on which is the easiest to learn and remember.

There are limitations of MUMPS that may inhibit its role in the DHCP and perhaps elsewhere. Most ANSI standard MUMPS applications lack a screen driver; the user cannot control the cursor directly with MUMPS commands. Consequently, one cannot have a full screen editor/word processor or graphics capability. Although the literature does not report much controlled experimentation, there is a widespread feeling in the in industry that screen handling is superior to line-by-line interactive dialog. Several vendors (InterSystems, Hoskins Group, and Bernd Cordes Software Consulting) have recently begun to offer MUMPS based packages with sophisticated screen handling. However, these systems are proprietary and their use in the DHCP could conflict with the policy of using ANSI standard MUMPS.

This shortcoming is painfully obvious when windowing, bit-mapped microprocessor graphics, fur-screen word processing and data entry are commonplace. Although this limitation is true of COBOL and FORTRAN, DHCP users will not compare MUMPS to these second generation languages. Instead, their expectations will be established by Lotus 1-2-3, VisiON, WINDOWS, dBase II and other packages. Experienced MUMPS users do not see this as inherently a failing of the language; simply that the implementations have been slow in coming. Now the MDC is faced with the challenge of responding to this issue.

Although such software may be available under operating systems that support MUMPS as a language, interface to MUMPS is awkward. This will become a greater inability as micros, minis and mainframes develop increasingly sophisticated interfaces with the user. If MUMPS fails to respond, DHCP and other MUMPS users will be drawn into complicated and expensive interfaces between MUMPS and other packages. Not only will precious staff time be committed, DHCP system performance may be degraded as these applications are added.

For the present, MUMPS lacks a telecommunications interface. Users and developers need to be able to send messages to one another and to other MUMPS computers. Though not a problem for isolated individual users, communication is vital for a large scale, geographically dispersed application like the DHCP. Despite all reasonable precautions, things will go wrong at the most critical moments; only real-time debugging from a remote site will suffice in these circumstances. With telecommunication, the national authority on the problem can be called automatically.

Lastly, advanced computation in MUMPS is awkward; its mathematical capability is quite like that of BASIC. MUMPS can do in. integer to 60 digits data typing or significant concerns for precision. However, aside from basic arithmetic operations, mathematical functions must be written in MUMPS rather than languages better suited to rapid calculation of large volumes of data. As users analyze their data to capture some of the medical and management potential of the DHCP, they wilt require software to tabulate and make statistical computations. This need is inhibited by the difficulty of moving from MUMPS to software that is designed for such work. Either MUMPS will evolve, or users will conduct mass migrations of data to independent systems for analysis by other software.

The DHCP development team is presently using computer-based conferencing systems to pool geographically dispersed talent. Such systems permit remote participants to discuss topics with one another over a telecommunications network, thereby avoiding the cost and inconvenience of travel. The system tracks what each participant has reviewed so far and prompts for unread additions by others to the topic. This sequential transcript of the conference can help document the contributions and progress of the effort. "Asynchronous" conferencing allows one to participate when it is convenient to do so without having to coordinate schedules with the others; one can log-on any time. "Real time" conferencing can cleat promptly with concerns to participants across the nation.

Several computer conferencing topics have been implemented for the DHCP. First is the relatively small group of systems developers and programmers who must arrive at a consensus on complex issues. Design methods and development protocols must be consistent for successful maintenance of the software. Second is the larger group of DHCP system administrators at each hospital. These individuals need to share problems and solutions to ensure sustained operation of systems essential to patient care. Hardware installation and maintenance must be coordinated centrally but implemented locally. New software and fixes to old software must be disseminated and explained quickly and uniformly across the nation. System administrators need to exchange notes and experiences TO provide one another technical and organizational support. Computer conferencing makes this possible.

Tom Munnecke and other VDC staff are developing MAILMAN. a MUMPS implementation of the ARPANET simple mail transfer protocol. a well documented public domain packet switching protocol developed by the Department of Defense. Fully integrated into the hospital electronic mail system, the VA software will interpret the address of the envelop" into network routing headers, control the modems. and perform the "handshaking" between sender and receiver. The MAILMAN uses 300/1200 asynchronous autodial and autoanswer over leased lines and a commercial nation-wide packet switching network. The design is ''store and forward" rather than "real time:" users drop off and pick up mail instead of communicating interactively with one another. This approach greatly simplifies security and management of transmissions.

Written in standard MUMPS with concern for hardware independence, MAILMAN will Basil; fit into the user s view of the DHCP software. Drawing directly from the DHCP data base, VA hospitals can send each other "filegrams" to update patient files. This could enable interconnection of VAMC files into an agency-wide distributed data base. Routine reports to VA Central Office, updating the National Tumor Registry, or running other programs can be done quickly with minimal manual intervention. Lastly, MAILMAN provides asynchronous computer conferencing as described above.

With improved telecommunications comes greater concern for security. MAILMAN employs the 20 character keys of Bazarie's Cylinder to encrypt the transmissions. Only internally generated patient numbers are used in data exchange; identifying information does not appear in cleartext. The software is strict for transmission but forgiving for reception. Use of MAILMAN requires "postage" to cover the cost of transmission. The issuance and expenditure of postage acts to control user access and inhibit probing by unauthorized outsiders such as the "414" hackers. A gatekeeper controls the dissemination of medical records. Furthermore, clinical (as opposed to administrative) messages can be read only by users with clinical privileges. These steps will provide even greater confidentiality than is possible with most manual methods.

Semantic control is essential to the success of a national network. All the participants and systems must have in common both data meanings and nomenclature. The DHCP data dictionary is the cornerstone to communications between the hospitals, the VDCs, and Central Office -- be those communications electronic or memorandum. Therefore, the integrity and maintenance of the data dictionary is high priority for DHCP management.

George Timson, the developer of the VA File Manager, is preparing a, word processing feature for the File Manager. This should be a major improvement over "free text," although the lack of a screen handling capability will be a significant performance limitation.

If the MDC decides to address screen handling in the MUMPS standards, they should consider a number of issues. Since portability and standards are vital, vendor independence could be achieved using device table like those that now describe the terminal characteristics. This would permit MUMPS software to use variable names instead of hardware specific codes and control characters. They should provide a feature to enable adjustment for the level of proficiency of the user, coaching novices while allowing experts to move more quickly.

V. STEPS FOR THE FUTURE

Link MUMPS and Other Language

As a closed system, MUMPS do" not help its users move to external systems. However' the interpretative language SPEAKEZ provides "linkules" which pass commands and data to programs in other languages. User written linkules function like other SPEAKEZ commands; actually, SPEAKEZ commands are usually themselves linkules to execute FORTRAN programs to process the data passed to them from SPEAKEZ workspace. In fact, the computational power of SPEAKEZ derives directly from its linkule capability. It supports complex algebraic and statistical routines for quantitative analysis and modeling. A similar feature in MUMPS would lessen its isolation while retaining the integrity of its environment. As the need arises. programmers could rite computational routines and report generators in other languages better suited for the desired process; these routines could be compiled and executed as MUMPS commands.

The purpose is not to make an invidious comparison between these languages. Each has its strengths and weaknesses; although SPEAKEZ has excellent computational capabilities, it has no counterpart to MUMPS globals. Instead it is the similarities that suggest a lesson for the DHCP. Llke MUMPS. SPEAKEZ partisans are principally economists and mathematicians; they often receive only grudging support from the data processing staff. Like MUMPS, SPEAKEZ gives non-DP profesionals quick but powerful access to computing resources. No longer vulnerable to the priorities, capabilities, and communication skills of the DP shop, program personnel have control over information, a resource essential to their professional success.

The identity of MUMPS is in the hands of the MUMPS Development Committee and the MUMPS Users' Group. Without these two organizations, MUMPS would quickly degenerate into a variety of vendor specific dialects. Aware of the importance of uniformity, the Department of Defense has gone so far as to obtain a trade mark for the name ADA; no vendor can call their compiler an ADA compiler without DOD validation and authorization.

As the largest institutional user of MUMPS and the VA File Manager, the VA should take its investment in MUMPS with equal seriousness. To assure consistency and integrity of the language, the VA should press for and commit funds to a language validation program. Such a program can administer "a validation suite" to test vendor MUMPS implementations and requests for incorporation of extensions, thus enabling the language to grow.

Already there is apprehension in some quarters about the magnitude of the VA involvement. MUMPS users are by nature more independent than not, so pronouncements from a large Federal bureaucracy probably will not be well received. If the VA puts significant funds and personnel into MUG and MDC, the agency will need to demonstrate disproportionate sensitivity to the concerns of smaller participants. VA policy should follow a MUG or MDC discussion; force will only drive away the talent that created MUMPS.

Most MUMPS users are quite enthusiastic about the language; they are eager to give as well as receive lessons on how to use the language and the software. Thus the most important task before the DHCP managers is to capitalize on this vigor by enlisting both trainers and students. The VA will need to continue and extend its efforts in training hospital personnel in the use of MUMPS and the VA File Manager. All users need to be proficient at their assigned responsibilities, as well as exposed to new capabilities and opportunities for personal growth.

In addition to MUG and RMEC classes, hot-line consultation by good MUMPS programmers must be implemented To economize on the staff time required this duty could be rotated among the VDCs, although constantly changing the phone numbers is not desirable. VDC personnel should view user training and support as a high priority; those involved in development work should rotate in and out of the consultation effort in order to reinforce the user's perspective in their minds.

Users also need guidance on applications design and implementation. They should get the basic planning and project management skills that are taught as software are engineering:

• problem definition
• functions to be performed
• operational and environmental considerations
• alternative approaches, and
• improvements and benefits realized.

The stages of software life cycle need to be covered, along with a checklist of things to remember (such as security, data integrity, privacy. records management, and organizational implications). Emphasis should be placed on understandability and reliability; clever methods should be taught but not at the expense of maintainability.

End users should receive a DHCP Programming Style Book with the more sophisticated courses. It should discuss the basics of software engineering and how to apply such techniques to MUMPS and the DHCP. In addition to the above mentioned issues, the Style Book should cover standards and the need for portability.

Much of the success of MUMPS is the result of dedicated medical and DP professionals who persisted in the face of considerable inertia and opposition. Whenever "the MUMPS Underground Railroad" gathers at a conference, superficially one se" a social group. However. just as language contributes to national culture, so have the MUMPS underground come to see themselves inextricably bound to their language. So the tales of the MUMPS rebellion serve to build cohesiveness and commitment to the success of the DHCP. Hence, DHCP managers need to nurture this spirit with periodic gatherings. oral and written folklore, and participatory decision-making.

Coaches of team sports know that outstanding performance is the result of know-how, dedication, and creativity. As the coach. the DHCP management must see that all these factors are present. Thus, it is critical that sufficient attention and resources be put into DHCP training and guidance.

The VA DHCP is an ambitious effort to place computer tools into the hands of hundreds of thousands of end users. These tools are quite powerful, so much attention needs to be paid to educating end users. Otherwise, they will repeat the errors of the data processing past, only on a profoundly larger scale.

In many respects the selection of MUMPS for the DHCP was as much a cultural and political issue as it was a technical issue. A language rises to prominence because its advocates understand it and its technical environment, they employ it with effectiveness and creativity, and they persist despite criticism. Frustrated by the difficulties of communicating and receiving suitable software, many medical professionals have become computer specialists and/or have quietly hired such specialists. From their viewpoint, MUMPS is the right language for the DHCP because:

1. the MUMPS supporters could do the job when others could not, and

2. they could transcend the immediate task and communicate their commitment and dedication to the mission of the VAMCs, thereby gaining the confidence of VA management.

Does the DHCP experience suggest that end users can engineer software? Yes. they can become competent and responsible participants if they and the DP professionals share common techniques and culture. The technical capabilities of MUMPs lent itself to the DHCP application. However. if MUMPS had been imposed on the DHCP users by the DP professionals, or lice-versa, then it would have faired no better than COBOL.

Is MUMPS a good language for large scale end user computing? Perhaps. Both users and DP staff need to consider the strengths and weaknesses of a language for their particular application, as well as assess the track record of each language for meeting the demands of users and the unfolding capabilities of DP technology. Although .MUMPS is a ANSI standard language, it may prove more resilient than other standard languages because of the skill, dedication, and creativity of the organize organizations that care for it. Otherwise, the needs of the users may outgrow the capabilities of the language to meet them with ease. If this occurs, then MUMPS will not survive.

1. Baird, George and Daniel Peterson, An Evaluation of MUMPS, GSA Office of Software Development Report No OSD/FSTC-83 '901, Washington, D.C., December 1982.

2. Bauer, F. L., "Software Engineer," Information Processing 71, North Holland Publishing Co., Amsterdam, 1972.

3. General Accounting Office, "Comments on the Suitability of MUMPS language for Government Agencies." Letter B-203143, Washington, D.C., July 8. 1983.

4. Ivers, Martin, et al. "Large Scale Implementation of Compatibles Hospital Computer Systems within the Veterans Administration," Proceedings of the Seventh Annual Symposium on Computer Applications to Medical Care. IEEE Computer Society, Silver Spring, MD., 1983.

5. Jensen, Randall W. and Charles C. Tonies. Software Engineering, Prentice-Hall. Englewood Cliffs, New Jersey, 1979.

6 Lushene, Robert. "Learning and Using ANS MUMPS -- A Programmer's Perspective," Proceedings of the Annual Conference of the Association for Computing Machinery, 1980.

7. Martin, James, Applications Development Without Programmers, Prentice-Hall. Englewood Cliffs, N.J., 1982.

8. McGuire, John and Roger M. Cooper, "The Veterans Administration's Approach to Hospital Automation," Proceedings of the Seventh Annual Symposium on Computer Applications to Medical Care, IEEE Computer Society, Silver Spring, MD., 1983.

9. Munnecke, Thomas, "A Linguistic Comparison of MUMPS and COBOL," Proceedings of the National Computer Conference, 1980.

10. Oberst, Robert J. and Janet A. Johnson, "Rapid Detection and Reporting of Programming Errors in Medical Information Systems," Proceedings of the Seventh Annual Symposium on Computer Applications to Medical Care,. IEEE Computer Soceity, Silver Spring, MD., 1983.

11. Timson, George and Martin Ivers,, "Supporting End User Development of Complex Information Systems Through a Language Applications Generator and a Library of Utilities," MUMPS Users Group Quarterly, Vol. XI, Special Issue, No. 2-3. College Park. MD., 1981.

12. Weinberg, Gerald M., Rethinking Systems Analysis and Design, Little, Brown and Company, Boston, 1982.

The observations and conclusions expressed in this paper are those of the aurhor, not the General Services Administration or the Veterans Administration. The author is grateful to the staff of troth agencies for their comments and patience. This paper is in the public domain 1: has previously appeared in the Conference Proceedings of the 1984 In International Con Conference in Computer Capacity Management, Washington, D C.. April 9-12, 1984 and is reprinted by permission of the Institute for Information Management 510 Oakmead Parkway, Sunnyvale. CA 94086 086 Revisions made by the author.

Chris Bonnici
If you have any other document we could include here, send an e-mail to chribonn@softhome.net.
An online form may be used if your browser supports it.

Last Updated: 24 October 1997

T^{he Index} or ^{Go U}P