Emergency Software: Software Development Lessons from EMISARI

On August 15th, 1971, President Nixon declared a 90-day freeze on wages, rents, and prices. The next day, the Office of Emergency Preparedness (OEP) was charged with implementing the Freeze. OEP launched an administrative crash program, leveraging the expansive power of the federal government, and also took the risky step of developing novel software to facilitate coordination of hundreds of federal employees. Originally called the Emergency Partyline, the software was soon known as EMISARI. EMISARI aided the OEP with internal communications, reporting, and conduct of their mission. Leveraging early time-sharing technology and a dialect of the BASIC language, EMISARI supported communications in the styles of chat, forums, and email as well as providing a flexible data collection and reporting workflow system. We explore the design and implementation of EMISARI and PARTY-LINE, the adjunct synchronous chat program, how EMISARI compared to the other software systems used by the OEP during the Emergency, and what lessons may be applied to modern startups and crash programs.

Before the Emergency

The OEP, when not involved in managing a crisis, created emergency response plans and cultivated a list of subject matter experts who might be called upon to provide aid and advice. The OEP had an expansive remit of emergencies, including traditional emergencies like hurricanes and droughts, industrial actions (e.g. strikes, supply chain interruptions), and civil defense (e.g. telecommunication resilience in the event of a nuclear war).

One of the techniques used to explore disaster scenarios was a Delphi exercise or the Delphi method. Originally invented by RAND, Delphi is a structured group communication process intended to drive clarity on a complex issue. A standard exercise involved a small monitor team sending a questionnaire out to a respondent group. The monitor team would summarize the responses from the group and send out the summary along with a new questionnaire, diving deeper into the issue. The monitor group may also distribute background material. Through iteration, the disparate group would ideally standardize on terminology and find aspects of agreement as well as contention. The Delphi Method: Techniques and Applications (1975) by Linstone and Turoff contains a series of essays on the method and provides insight into how the process was understood at the time.

The Delphi method is a more structured process than a modern internet debate via social media, email, or a forum. Delphi have controls in place to prevent individuals from dominating the conversation or unfairly influencing the outcome. For instance, individuals may be capped in how frequently they can contribute to give others a chance to speak. Some Delphi conferences include anonymous or pseudonymous features to prevent rank or pre-existing prestige from influencing the results. These features often required extensive work by the monitor team, so many practitioners were interested in using computers to automate the method.

Within the OEP, the System Evaluation Division (SED) was formed in the late 1960s to seek technologies useful for emergency management. The division conducted Delphi studies, used network optimization to improve the resilience of gas pipelines and the telephone system, and developed early computer conferencing software (Hiltz Turoff 1978, pg 47). Murray Turoff, the later system designer for EMISARI, was hired by the SED in 1968 and studied various potential emergencies, often using the Delphi method.

While Turoff was training as a physicist (PhD 1965, Brandeis University), he had developed a strong interest in computing. His thesis was a computer simulation of a planetary nebula using FORTRAN on a IBM 704. Each case study of the model required about three hours of computer time. Restricted to only using the computer on Friday and Saturday evenings, he saw interactive computing as the path to greatly enhanced productivity (Subramanian 2012). He also grew interested in the social aspect of connecting computer users together which fueled his interest in computer conferencing and later computer-mediated social networks.

In the spring of 1970, Turoff surreptitiously launched a computer conferencing experiment with twenty participants distributed across the United States. Hall describes the technical design and implementation of this system, or something close to it, in (Hall 1971). The paper also contains representations of the user interface from Turoff. According to Turoff, the experiment had to be kept quiet at the time because:

  1. The organizational culture demanded that failures were to be punished,
  2. The official software development group wanted to maintain a monopoly on all development activity and Turoff was not a member of that group, and
  3. Twenty unauthorized individuals using the system was an embarrassing security violation (Hiltz Turoff 1978, pg 48).

After seven weeks, the computer operators discovered the unauthorized access and traced it to Turoff’s work. The head of the SED, Robert Kupperman, interceded and allowed the experiment to complete, but Turoff had to be punished. His terminal was taken away. However, since his accounts were not disabled, Turoff simply found a spare terminal the next day.

The experiment was successful — a distributed set of participants had asynchronously discussed a subject usefully over the computer. The OEP had a new capability to use for emergencies, although one without broad support.

The 1971 Wage Price Emergency

In President Nixon’s “The Challenge of Peace” address, he outlined three policies intended to increase employment, reduce inflation, and mitigate international speculation on the dollar. To reduce inflation, his first step was ordering a 90 day freeze on all prices and wages throughout the United States. On the same day, Nixon issued EO 11615, which created a Cost of Living Council that was delegated the powers and responsibility to “stabilize prices, rents, wages, and salaries” via the Economic Stabilization Act of 1970. In turn, the Council delegated implementation of their policy decisions to the Office of Emergency Preparedness.

George A. Lincoln, director of the OEP, had been told the previous day (Saturday) to return to Washington D.C. in anticipation of an address by the President. On Tuesday, August 17th, the OEP was formally delegated powers. To manage the Wage-Price Freeze, it would (Yoshpe 1972, pg. 24-25):

  1. Provide overall management and direction
  2. Develop, in conjunction with other agencies, critical policy question and suggest answers to the Council
  3. Respond to national and local queries on the application and interpretation of policy
  4. Ensure and enforce compliance
  5. Receive and consider requests for exceptions and exemptions
  6. Keep the public informed
  7. Monitor the progress and maintain a full record
  8. Collaborate with other agencies in planning the post-freeze policy
Flow of Communication during the Emergency. Source Yoshpe 1972, pg 62

Flow of Communication during the Emergency. Source Yoshpe 1972, pg 62

Although the OEP was experienced managing and coordinating emergency responses, the office did not have any specific plans in place to manage an economic emergency of this nature. However, the OEP had an extensive list of subject matter experts and could pull personnel from other organizations. At the beginning of the Emergency, the national headquarters had 230 staff. By the end of the first week, staff increased to 381. By October, staff increased to 415. (ibid, pg 44). Staffing similarly increased within OEP’s regional offices by 300 by October (ibid, pg 45). In three months, the OEP had doubled in size.

Successful administration of the Emergency required rapid formulation of plans, clear and consistent communication, both internal and external, and coordination of a large, newly organized staff, many on temporary details. Director Lincoln was open to innovative approaches, particularly those which aligned with Nixon’s wish to keep the temporary bureaucracy lean. Seizing an opportunity to test their computer conferencing ideas during a real emergency, his System Evaluation Division head, Robert Kupperman, suggested adapting the recently developed software for the emergency’s needs. Lincoln approved.

EMISARI was rapidly developed, with a prototype available within a week, and used to handle many communication and reporting needs of the Emergency.

Ninety days later, on November 14, the Freeze was over and “Phase II” of the economic stabilization program began under the management of the Internal Revenue Service. The IRS adopted IRMIS, a slightly modified version of EMISARI, to administer their phase. EMISARI would continued to be used in later national emergencies handled by the OEP.

Within this article, we are not concerned with evaluating the government’s economic policies. Instead, we are concerned with computing’s contribution to the administration of the Freeze and how these lessons might be applied to modern situations where schedule and resources are particularly tight.

EMISARI Design and Development

Development History

With the Emergency to last 90 days, each week represented 8% of the duration. George Lincoln was told by Kupperman that software to aid in administering the Emergency could be available in two weeks. After Lincoln approved, Kupperman told the team that the software was needed in a week (Hiltz Turoff 1978, pg 52).

The first version of the software, dubbed the Emergency Party-Line, became operative during the second week of the Emergency (Renner 1973, pg 30). This version included “agencies, contacts, messages, estimates, programs, update choices, and a description and explanation section.” and required 2,500 lines of XBASIC (ibid). In classic start-up fashion, Turoff coded the prototype by taking a terminal home and working continuously for four days (Hiltz Turoff 1978, pg 52). Turoff did have the advantage of access to the previous computer conferencing software developed by Thomas Hall and designed by himself, which at least provided reusable “design principles and software techniques” (Renner 1973, pg 3) if not reusable code.

Two weeks after version one, the Emergency Party-Line was renamed EMISARI and the program gained Rulings, Exceptions/Exemptions, and the Bulletin Board. “In three weeks of intensive work, over 12,000 lines of XBASIC code, including revised and rewritten sections, were produced by the three programmers." (ibid, pg 32) These features included a form of free-form text search. The total lines of code rose from 2,500 to 6,000. (ibid, pg 32).

Timeline-wise, the PARTY-LINE software, which was an adjunct to EMISARI but independent in execution, was used in Lincoln’s third weekly status meeting, so it must have been developed prior to the release of version 2 of EMISARI. Since PARTY-LINE lacks any dependencies on EMISARI data, it may have been developed as part of the 1970 computer conferencing experiment, although we have no evidence to support an earlier development.

The rapid development of EMISARI took a toll and the next version required six weeks before being released. This version became the baseline for the IRS’s IRMIS system and stood at 6,900 lines of code (ibid, pg 32).

Functionally, the first version provided necessary features for users to report required data items (estimates and programs), identify who they were and how to contact others (agencies and contacts), provide context on their estimates and communicate with others (messages), and had a basic section for questions and answers. Smartly, the features necessary to record rulings, exceptions, and exemptions waited until the second version when the OEP started actively administering the Emergency. The third version was focused on resolving technical debt.

Notably, the features list for the various versions do not include tables. Tables took estimates and programs and rendered them for print. We suspect tables were implemented in an “on demand” basis, rather than release-based, to align with emerging management needs.

Timeline (all dates 1971):

Operating Environment

The OEP operated a Univac 1108 mainframe running Exec 8, which was Univac’s first time-sharing, interactive operating system. The 1108 was a 36-bit system and used a 6-bit character encoding called Fieldata. Units could be equipped with 65,536 words to 262,144 words of memory. Based on comments about planned software improvements, the developers considered memory the most constrained resource.

Users connected to the machine via terminals, most likely Teletype Model 37s or Execuports (OEP-SED, General Correspondence & Directives, Coordination meeting with CLC Staff 1971-08-31). These terminals did not have a “glass” interface, so all interactions were printed to paper.

Teletype Model 37. Source MBlairMartin CC BY-SA 4.0

Teletype Model 37. Source MBlairMartin CC BY-SA 4.0

Design Philosophy

Although the development of EMISARI was obviously time and resource-constrained, the development team anticipated using the software for future emergencies and built the application without tying it specifically to Phase 1 requirements. To fulfill this broader vision, the team adopted these design philosophies as (Kupperman 1972) reports:

  1. An effective management information system requires communication upward, downward, and laterally. Without this, reporters will lack feedback on the quality and usefulness of their data.
  2. Requests of data must differentiate between different degrees of timeliness (from emergency, reply at once, to store data for later historical analysis) so reporters can effectively prioritize their work.
  3. Emergency responses must be flexible to changing user requirements and environmental changes.

The first statement was achieved through the flexible interface between reporting and messaging. A reporting requirement, or Estimate, is delegated to a single reporter. The reporter could respond to the request by linking the Estimate to a Message, which could then be read by anyone. Estimates also stored the “workflow” status, so a reviewer could see when the respondent expected to report the value. If an Estimate seemed incorrect, a reviewer could attach a Message to that Estimate with their questions, or a reviewer could send a Message to the reporter directly. Using the Agency and Contacts table, anyone could search for other users.

For the second philosophical statement, Estimates were tied to Programs. Programs could communicate expected deadlines and periodicity by the naming and design of the rows. Furthermore, Messages sent by the requester could alert reporters of the urgency or if a data value was no longer required.

The team’s choice of programming language and data model demonstrate how they planned to keep the application flexible. The team believed that XBASIC, as opposed to assembly, was more amenable to change. (Internally, there also seems to be a bias that XBASIC wasn’t a real programming language and thus normal users could be trusted with writing programs in it, expanding the development base.) Architecturally, they also divided the program into highly focused sub-programs with limited interfaces to other sub-programs. This simplified the effort required to understand a program to modify it.

Furthermore, the Text Files (searchable lists) were the mechanism to record news, policy decisions, frequently asked questions, and such. These could be easily tailored to the particular emergency or left out (as NEWS was dropped for IRMIS). All users could read and respond to items, although certain files permitted only certain users to edit their contents. Although files could contain structured data (e.g. People), most were relatively flat. Thus, the files were understood through their title and how users came to use them, rather than requiring development effort to impose a certain use.

Data Model

The EMISARI data model was intended to support future emergencies and thus be highly flexible. As shown in the figure below, there were four groupings of primary objects: users and groups (green), reporting (blue), commentary and messaging (purple), and searchable text (orange). Physically, the data was stored in 28 word long data blocks. Thomas Hall, who wrote the computer conferencing system Turoff used in 1970 and contributed during the Emergency, describes many of the software techniques necessary to work within the Univac 1108 in (Hall 1971).

EMISARI Conceptual Entity Relationship Diagram

EMISARI Conceptual Entity Relationship Diagram

(Renner 1973) is the primary source on the data model for EMISARI as it existed at the end of the Emergency, while (Hall 1971) provides insights into how it was likely physically implemented.

Users and Groups (Contacts and Agencies)

Contacts served as both a Rolodex to find individuals as well as representing users of the system. A contact was expected to be “responsible for gathering or acting on information” (Renner 1973, pg 9), so the entity was only necessary for adding or modifying data. Each contact had an access code, assigned by the monitor, which would permit the modification of data. Otherwise, users could view any data within the system.

An Agency is a grouping of contacts. We do not find any indications agencies were used for permissions or served more than an informational role within the system.

Reporting

The gathering and aggregation of data, based on shifting needs, was the core responsibility of EMISARI. Data collection was focused solely on numerical data.

The Estimate was the fundamental entity for reporting. “An estimate is a specific item of data that a particular contact is responsible for reporting.” (Renner 1973, pg 12) An example estimate would be the number of inquiries made in region 3 during the week of September 5th. Consisting of either a number or a code, Estimates also had an associated descriptive title, an internal label, designated owner, and a modification date. If a number was not available, respondents could use the following codes:

A Program was a collection of Estimates, semantically like a row or vector. In most cases, a Program would be a time series representing the value per week.

Tables consisted of one to five columns and one to 21 rows, along with associated titles for each. The data for a table would come from Programs, but could also consist of computed rows and columns, such as sums. Tables could also be derived from other Tables, for instance each OEP region could have a detailed table and then a national table could combine the regions. Tables could also be archived for historical data preservation.

Commentary and Messaging

Fulfilling the design philosophy that a management information system should provide effective upward, downward, and lateral communication, the commentary and messaging data entities provided flexible means to communicate requests and context.

A Message contained a title and approximately five lines of free-form text content. A Message could be sent from a Contact to another Contact, or from a Contact to everyone. (This feature was leveraged by the Monitor for administrative notifications.) Alternatively, a Message could be attached to an Estimate, Program, or Table. Similar to a comment in a spreadsheet, anyone looking at the reported data could examine the attached comments for additional context or explanation.

A Letter stored up to 100 lines of text and was sent from one Contact to a group of Contacts. Letters could reference or transclude other items within the system. For example, the link &TABLE 20,30 would insert tables 20 and 30 into the Letter. Similarly, &NEWS ITEMS 53,54 would insert news items into the Letter. The transclusion was performed at render-time so the viewer would always see the latest version (Renner 1973, pg 10-12).

Both Messages and Letters were asynchronous styles of communication. Contacts would see new messages and letters when they opened the “home” screen. There were no notifications to interrupt their flow. Synchronous communication was supported via the PARTY-LINE program, which is discussed later.

Searchable Text

EMISARI provided multiple “text files” to store content on various topics. The final list of topics were Bulletin Board, Policy and Guidance, Actions, News, Information, People, and Explanations (Renner 1973, pg 17-18). These files were used to report items, summarize relevant media reports, and document policies. The contents were widely used. For example, one of Lincoln’s secretaries was abstracting articles from five newspapers and adding the summaries into the News file. When she was out sick one day, twenty calls came in complaining about the delay in updates (Hiltz Turoff 1978).

Each file consisted of control blocks, which were small and could be contained in memory, and data blocks, which were separated into “line units”. Each line unit could contain up to six lines and a data block could contain one to five line units.

EMISARI maintained a small, adaptive index for each file. The index stored a limited number of search terms and a list of matching entries. The index was updated as users made searches, with older and longer keys replaced by newer and shorter keys. Search used a substring prefix matching approach. (Renner 1973, pg 34)

A typical use of this feature was to prepare for public meetings. A team member preparing to talk to an insurance consortium would search for “insurance” to pull the latest relevant policy decisions, inquiries, and news to that group (Kupperman 1972).

(Kupperman 1972) states that the index terms were also examined by the team to determine what the public was interested in. If a search term was not finding relevant documents, then the team might invest in creating documents for that term. The index’s ability to shrink queries to a common root helped identify the broadest query.

Architecture

Architecturally, EMISARI was composed of multiple XBASIC programs. Programs read and wrote to files using locks for synchronization. Each program was focused on a specific set of functionality and could invoke another program via XBASIC’s chain command. (This technique was not unique to XBASIC.) Scalar variables could be passed between programs to retain user context. (Renner 1973, pg 32) claims this design “eases the coordination of the programming effort and limits the amount of computer resources […]”. Page 33 provides a breakdown of the lines of code for each section (below) which closely follows EMISARI’s functional boundaries.

Section Lines of Code
INITIAL 266
Agency-Contact 312
Program-Estimate 334
Message-Letter 309
Table 239
File Retrieval and Explanation 491
People 539
Description 292
Update (Messages and Estimates) 536
Table Update 259
File Update 427
SUBTOTAL 4004
Monitor Programs 2290
Special IRMIS Programs 606
TOTAL 6900

Notably, the programs with “read-write” capabilities are separate from the programs that merely “read” (e.g. Table vs. Table Update). Although we might see this separation as a security feature, similar to programs dropping suid privileges, (Hall 1971) presents the advantage as “saving some amount of memory space” by not having to load the file editing code.

Given the limited source control tools available at the time, another advantage would have been to allow the developers to work on independent files concurrently, similar to microservices being independently deployable. Renner’s claim that the design “eases the coordination of the programming effort” may have been referencing this aspect.

Role of the Monitor

Delphi-style conferences appointed staff members, sometimes named monitors, to help guide and administer the proceedings. For instance, monitors were responsible for summarizing written responses and identifying conflicts within the responses and turning them into new questions.

Within a computerized conference, the computer ideally took over many of the monitor tasks. Prior to the Emergency, the vision for the monitor’s role was seemingly focused on system administration. The monitor had four roles (Hall 1971):

  1. Setting up a conference - establishing list of respondents (with their access codes), providing an abstract of the conference’s purpose, and possibly initializing some of the data items
  2. Modifying the conference - cleaning and codifying data items, changing respondents as necessary, and broadcasting necessary messages to the participants
  3. Analyzing the conference - summarizing voting results
  4. Deleting the conference - cleaning up resources after the conference is complete

The monitor’s role broadened during the Emergency. Although the monitor was still involved in creating accounts and assigning access codes, they were also involved in training, community management, and influencing the product roadmap. (Renner 1973, pg 25-27) has a similar list of core responsibilities for the monitor as Hall but lists as additional monitor roles:

  1. Public relations - meeting with people about the system, generate interest in joining
  2. Anticipatory trouble shooter (e.g. conflict in data requirements)
  3. Participate in improving system design
  4. Improve / tailor training for specific user groups (e.g. new users vs. advanced users)

This list of responsibilities presages later roles such as community relations manager or customer success. Perhaps due to the professional setting, the monitor is not ascribed any moderation responsibilities such as we see in a forum moderation role. The monitor was expected to edit posts made by others, but this is usually cast in terms of eliminating duplicate posts or reducing disk space by trimming obsolete information, not defusing flame wars. Murray Turoff was explicitly interested in the sociological impact of computer use and computer conferences, but EMISARI does not seem to have generated a community like the later PLATO system.

Comparison to the Census System

As supplied in a list to the Cost of Living Council, the OEP used four management information systems during the emergency (OEP-SED, Weekly Report, 09-15):

  1. EMISARI
  2. Census
  3. Record of incoming mail to the national office and action taken
  4. Record of inquiries to the national office requiring further guidance

Within the weekly reports, EMISARI produced Appendix A (“Summary of Inquiries”), while the Census system produced Appendix B (“Census Bureau Alleged Violations”) and Appendix C (“Census Bureau Exceptions and Exemptions”).

In the Director’s After Action Report (OEP-SED, After Action Reports: Wage-Price Freeze (Director’s Memo 10/27/71), dated November 8, 1971), he praises EMISARI, stating that it “achieved a level of reliability and completeness such that by mid-October it was accepted as the sole vehicle for statistical reporting within OEP”. In contrast, he criticizes that the Census system “could not be modified rapidly enough to accommodate changes such as the shift in compliance emphasis from complainant orientation to violator orientation.” He attributes this rigidity to its programming in assembly language and “complex and widely-distributed data input network”.

Additional evidence for EMISARI’s reliability and the OEP’s struggles with the Census system can be seen in the successive weekly reports. None of the weekly reports (there are nine from September 15th through November 13th) include any corrections to EMISARI’s Appendix A outputs. The Census’s Appendix B are similarly unmarked, but the introduction of Appendix C on October 9 notes that the current week totals are actually cumulative totals. While this error was apparently corrected by the next week, from October 16th to and including November 13th, Appendix C is marred with a note that weekly sums are actually two week sums.

While the Census system was criticized, it was apparently necessary. In a October 26, 1971 memo to the IRS, who were to administer “Phase 2” of the Emergency, Kupperman describes the Census system as a necessary source for certain analytical data. Although necessary, the Census system was not sufficient as Kupperman also pushed the IRS to adopt an EMISARI-like system, termed IRMIS (Internal Revenue Management Information System), rather than developing a new system from scratch. (The IRS adopted IRMIS.)

PARTY-LINE Design and Development

Termed an “adjunct” program to EMISARI, PARTY-LINE is a group-oriented chat program. At a designated time, all participants would login to the Univac 1108 and invoke the program. Within the user interface during a chat, participants would either be writing a message or reading and retrieving the latest messages. Internally, the program appended messages to a sequential list stored in common storage (using locks for synchronization) which would be discarded at the end of the conference. While seemingly ephemeral, given the nature of the terminals, all participants would have a hard-copy.

PARTY-LINE supported 15 concurrent participants, although Turoff claimed this limit was arbitrary and the program could support 30 to 50 individuals. (The number of phone lines connected to the mainframe would have been a constraint.) During the Emergency, 15 participants were sufficient for meetings with the ten regional offices and the national headquarters staff. The (Turoff 1972) paper, which includes an example post-Emergency conversation using the program, implies that the program supported multiple numbered groups at the same time. Participants could join an existing group or create a new group. In contrast, PLATO’s Talk-o-matic, CompuServe’s CB Simulator, and BITNET Relay all had a fixed number of channels. Additionally, at least by 1972, the program supported confidential participant-to-participant messages.

Notably, participants could be pseudonymous within the chat, choosing a name separate from their login name. This feature was used early in the Emergency. As reported by Turoff (Hiltz Turoff 1978, pg 63), there was a regular meeting of the 10 regional offices and the national office. During the first two weeks, the regional offices repeatedly communicated that all was well. For the third week, they were ordered to use PARTY-LINE but connect to the chat using a fake name. This time, over the next three hours, the regional offices communicated many of the challenges and issues they were facing, finally providing transparency to management.

This anecdote aligns with Turoff’s theories that features computer conferencing can shape and improve human communication, rather than merely providing another channel.

In a memo dated October 5th to Turoff, Richard H. Wilcox suggested some conventions for using PARTY-LINE such that conferences “do not degenerate into chaotic collections of uncoordinated input”. His suggestions:

Turoff claims PARTY-LINE was coded in a single day by Thomas Hall for the Freeze (Turoff 1972), but by the 1972 paper an additional two man months of development had been applied to OEP’s computer conferencing systems (which includes PARTY-LINE and DISCUSSION, a forum-system). PARTY-LINE, like EMISARI, was developed in XBASIC. The paper states that the “program” is about 350 lines in length, but we are unclear if the author was referencing PARTY-LINE, DISCUSSION, or both.

Organization

(Hiltz Turoff 1978, pg 47) lists the principal contributors to EMISARI and their roles and affiliations:

Programming Consultants:

Programmers (OEP Mathematics and Computation Laboratory):

(Affiliations are with OEP unless noted otherwise)

After Emergency Phase 1

When the IRS took over “Phase 2” of the Emergency, they adopted IRMIS, a slightly modified version of EMISARI, to fulfill a similar role. Since the IRS’s computers were IBM models and thus could not run EMISARI directly, the IRS team continued to use OEP’s 1108. Kupperman pushed for the IRS to take this route, arguing that rewriting the system would take six to eight months (OEP-SED, Post-freeze Information and Reporting System for IRS, October 26, 1971). During (at least) the first week of Phase 2, the IRS had operational issues with IRMIS, which necessitated Kupperman to defend the software and the (unplanned and unreimbursed) support from OEP’s Mathematics and Computation Laboratory (OEP-SED, MCL Support to IRS, 1971-11-30).

The OEP was dissolved in 1973 and re-organized under the General Services Administration. Kupperman, who had long been a champion of EMISARI, left the organization. Murray Turoff, Richard Wilcox, and Nancy Goldstein soon followed.

EMISARI continued to be used in national emergencies (e.g. 1973’s Voluntary Petroleum Allocation Program and 1974’s National Trucker’s Strike) but saw little investment and was dead by 1975 (Subramanian 2012). The adjunct portions of EMISARI, as well as the pre-EMISARI computer conferencing system, saw continued use in some university computer services departments (ibid).

Language Systems and Development made an effort to sell PARTY-LINE and FORUM commercially as part of their XBASIC language (Leavitt 1972). They continued to support XBASIC for Univac 1100 machines until at least 1980 when they released an ASCII compatible version.

Was EMISARI effective? Impactful?

Did EMISARI contribute to Phase 1’s success?

While the official history of the Emergency is generally positive about EMISARI’s role, their summary of the impact is underwhelming: “EMISARI was used extensively by those who availed themselves of its special capabilities, but was not widely adopted as a person-to-person communication system.” (Yoshpe 1972, pg. 65). The criticism may be unfair in that, although additional terminals were installed to support the Emergency and the Council Staff were allocated a portable Execuport terminal (OEP-SRD, Coordination meeting with CLC Staff (08-31)), most line workers would have shared a terminal rather than having a personal machine to themselves. Furthermore, there was cultural resistance to using a computer directly as typing was seen as a secretarial job.

During the Emergency, there was concern that EMISARI would be considered as unused. (Hiltz Turoff 1978, pg 59) quotes Richard Wilcox: “Fortunately, Murray and his troops, about a third of the way through the freeze, had put in a monitor, which showed how many times different parts of the system had been used. This helped to refute the charges that nobody had used the system, and helped in its continued life…".

These metrics are reprinted in (Kupperman 1972, Table 1). The table shows user accesses to various program sections over two periods. We are cautious about interpreting the data, as the table’s title states that the timeline is from September 2, 1971 to November 8, 1971, while the column headers say the timeline starts on September 27th. Overall, the table shows 29,090 items retrieved during the time period, with the Bulletin Board file being the most active with 9,672 items retrieved. Since printouts could be shared, the usage data may understate consumption because a team might have a single user perform all the searches and share the printouts with the group. The usage data is somewhat corroborated by a billing report on use of the 1108 which shows a dramatic increase in CPU seconds consumed starting with the Emergency (OEP-SED).

To the broader government, though, success was not measured by the usage of some internal software tool, but OEP’s administration of the Emergency. (The Freeze itself was considered successful due to improving measures of inflation.) Lincoln said consistency in policy application was a necessary and important factor in their success, as fulfilled by an efficient communication network and close knit operations between the headquarters and field staff (Yoshpe 1972, pg 203). Although the first week of the Freeze was characterized as chaotic with the field offices complaining that headquarters was failing to provide guidance, conditions quickly improved. The timeline, at least, correlates with the introduction of EMISARI and its functionality for reporting and aligning policy. However, management used more tools than just EMISARI.

OEP’s continued use of EMISARI for the next few years suggests it was useful and flexible for various types of emergencies, although management may have mandated its use over user feedback. Design decisions, like the use of the XBASIC language, which was proprietary to a vendor, as well as implementation decisions that made it likely difficult to port to non-36-bit systems, worked against a longer life. Furthermore, although there were attempts to regularize use of EMISARI, it was only expected to be used in emergencies, so it lacked a “stickiness” that software used daily possess. Given repeated bureaucratic reorganizations and changes to how emergency management was envisioned, we would not expect any asset to last long.

Citation-wise, the academic community largely ignored the small web of EMISARI-related papers. As an “application,” we think this is expected as “theory” is easier to build upon. Turoff’s later book, Network Nation: Human communication via Computer, co-authored with his wife, Starr Hiltz, was far more influential.

Like many pioneering software systems, EMISARI might have been too early to be well-remembered. Economically, terminals were too expensive to be common-place and, at 30 characters per second, remote interfaces were slow and awkward. Within the next decade, many of the features would be implemented and scaled within academic and commercial networks.

Conclusion

The OEP used the PARTY-LINE and EMISARI software to effectively administer the 90-day Phase 1 Wage Price Freeze Emergency. Functionally, the software performed similar roles as a modern knowledge base, forum, online chat, and multi-user spreadsheets. Development was rapid (a minimally viable version within one calendar week) and used a small, motivated team. The user base was distributed across eleven sites and there were about a thousand potential users, although actual concurrent users were far less.

We believe there are four lessons generalizable to other teams facing similar challenges:

Schedule matters more than performance

The team used XBASIC because it provided a means to create interactive programs in less time than in assembly. Although Turoff was experienced in multiple programming languages and could have programmed the tool in assembly, programming in XBASIC was faster and operations were “fast enough” on the 1108. He also could reuse code from the earlier Delphi experiment which was also written in XBASIC. Although the team mention a desire to port the program into assembly to reduce memory usage, memory constraints never seem to have blocked operations.

Broaden Value Generation

The reporting philosophy of encouraging upwards, downwards, and lateral communication created a community effect where all users saw value out of the system. Individuals were not siloed, but could view any post, see what others were reporting and how information was aggregated, and communicate to anyone. If EMISARI was solely the reporting functions without the forums and messaging, the low-level staff would have seen EMISARI as a data entry chore. Everyone benefited from aligning the distributed team.

Management Has Levers

Management made a few decisions to promote success. First, Turoff was given the job to write the first version. Turoff was heavily invested in making the software a success and had the necessary skills and background. The official development team in the company might have more skillful developers, but they were unlikely to volunteer to spend four days manically writing code to meet the schedule.

Secondly, management chose to “eat their own dog food.” Director Lincoln could have chosen to continue to receive news updates directly from his secretary, but by having the secretary type the updates into EMISARI, others could see value from that work and it demonstrated he was willing to login and do work within EMISARI. Further, using PARTY-LINE for the staff meeting showed commitment to trying new things rather than continue to use the telephone. The fact that the experiment also broke down a wall was pure bonus.

Track Usage

The OEP staff did not all agree that using and investing in EMISARI was worthwhile. Opponents charged that nobody was using it, but the inclusion of usage metrics gave the team the necessary ammunition to refute these charges. Novel programs should, at least, provide a way to track usage if not value generated.

Acknowledgments

I’d like to thank the archivists at the National Archives in College Park, Maryland for their assistance in researching OEP records.

References

(Hall 1971) Hall, Thomas W. 1971. “Implementation of an Interactive Conference System.” Proceedings of the May 18-20, 1971, Spring Joint Computer Conference, 217–29. https://doi.org/10.1145/1478786.1478818.

(Hiltz Turoff 1978) Hiltz, Starr Roxanne, and Murray Turoff. 1978. The Network Nation: Human Communication via Computer. Addison-Wesley Publishing Company, Inc. https://archive.org/details/networknationhum00hiltrich.

(Kupperman 1972) Kupperman, Robert H, and Richard H Wilcox. 1972. “EMISARI - An On-Line Management System in a Dynamic Environment.” The First International Conference on Computer Communication, 117–20. https://www.computerhistory.org/collections/catalog/102714088.

(Leavitt 1972) Leavitt, Dan. 1972. “‘XBASIC’ Backs Delphi Conferencing.” Computerworld, January 26, 17.

(OEP-SED) Record Group 396, Subject Files Relating to Science and Technology [Office Of Science And Technology Subject Files, 1967-73]

(Renner 1973) Renner, Rod L, Robert M. Bechtold, Charles W. Clark, David O. Marbray, Ronald L. Wynn, and Nancy H. Goldstein. 1973. “EMISARI: A Management Information System Designed to Aid and Involve People.” Paper presented at Fourth International Symposium on Computers and Information Science (COINS-72). February. https://archives.njit.edu/vhlib/cccc-materials/njit-cccc-tm-230/njit-cccc-tm-230.pdf.

(Subramanian 2012) Subramanian, Ramesh. 2012. “Murray Turoff: Father of Computer Conferencing.” IEEE Annals of the History of Computing 34 (1): 92–98. https://doi.org/10.1109/MAHC.2012.12.

(Turoff 1972) Turoff, Murray. 1972. “‘Party-Line’ and ‘Discussion’ Computerized Conference Systems.” The First International Conference on Computer Communication, 161–71. https://www.computerhistory.org/collections/catalog/102714088.

(Yoshpe 1972) Yoshpe, Harry B., John F. Allums, Joseph E. Russell, and Barbara A. Atkin. 1972. Stemming Inflation : The Office of Emergency Preparedness and the 90-Day Freeze. U.S. Government Printing Office. https://fraser.stlouisfed.org/title/198.