Prompt: “It’s All in There” More than a decade ago, as a medical student in Michigan, I began researching the origins of modern hospital design. As a soon-to-be doctor, I was interested in how my university hospital unsettled me. Months and even years into my studies there, I kept coming across new wards, offices, and laboratories. It often seemed to me at the time that miracles of healing and scientific discovery—organs transplanted, inflammatory pathways defined—must be happening around every bend. Some days, though, the hospital’s beige walls depressed me, the monotonous stretch of high-ceilinged corridors gave me vertigo, and the ambient smell of disinfectant turned my stomach. I wanted to understand how much of this disorientation came from navigating an unfamiliar space and how much was intrinsic to the building itself.

Response: That megahospital, like the one in Philadelphia where I’ll soon work, had its formal origins at the turn of the twentieth century. Before that time, American hospitals were more modest buildings, staffed by familiar faces from the local community, decorated like middle-class homes, with sash windows and sloping roofs. But the growing acceptance of germ theory, in which common diseases were ascribed to the spread of pathogens, correlated with a shift in hospital design toward blank, unornamented surfaces made of visibly aseptic materials like linoleum and metal.  At roughly the same time, industrial capitalism’s obsession with efficiency was exported from the factory floor to other domains, including medicine. Interest in scientific management led hospital designers to attempt to streamline patient movement in the way a factory was designed to streamline production processes. This move was reinforced by the rise of artistic modernism, which championed the now famous adage that form should follow function.  The predecessor of the Michigan hospital where I started my training was one of the prime examples of medicine’s embrace of the ideals of industrial efficiency. It opened in Ann Arbor in 1925 and was designed by Albert Kahn, an architect better known for planning several of Henry Ford’s automobile factories in nearby Detroit. Kahn drew clear analogies between these two building types, once telling the American Hospital Association that “the same principles underlying the proper functioning of a manufacturing plant apply to the planning of a hospital building.” Hospitals became emblems of progress and were celebrated for their rational forms. “The main purpose of the building is to function as a medical instrument,” said the Finnish architect Alvar Aalto with reference to his Paimio Sanatorium, a 1933 exemplar of modernist hospital design. But the flipside of the hospital’s increasing ability to anatomize patients was its capacity to dehumanize them. At the extreme, an analogy between hospitals and factories suggested an equivalence between sick people and disassembled parts.


Prompt: Both the scientific power and the dehumanizing effects of the hospital have been amplified over the last several decades, as these buildings have increasingly been designed to accommodate new computing technologies. From wall-mounted monitors in every patient room to networked smartphones in the pockets of every white coat, digital interfaces have provided new avenues for clinicians to communicate with patients and each other, accelerating the pace of diagnosis and therapy. But these interfaces also risk further isolating patients, drawing clinicians’ eyes toward screens and away from the person in the bed. More than once, I’ve asked a patient to relate the story of their illness, only to have them point to the nearest computer and tell me wearily, “It’s all in there.” An Emerging Labyrinth I moved to a new state for each phase of my clinical training, spending a few years on one mammoth medical campus before graduating to the next. Though each had its spatial quirks, these tended to follow similar themes. Pavilions of various ages were connected by secret tunnels once used by hospital porters to transport equipment, now used by savvy employees to avoid walking outside in bad weather. Certain unmarked elevators skipped certain unmarked floors unless presented with a privileged ID badge. Wards were decorated with a hodgepodge of faded prints in dusty frames—geometric abstractions, a still life of flowers—apparently much easier to put up than to take down.

Response: Irrationality emerges alongside obsolescence in hospitals, patchily, with various temporizing efforts made along the way to restore order and relevance. Inpatient units are retrofitted to new infection control guidelines requiring sinks in the hallway; radiology suites are widened to accommodate additional MRI machines. The hospital’s original floor plan is carved up, each territory stewarded by a different lineage of managers, each poised for its own idiosyncratic process of redesign: the secret tunnels’ access doors stay unlocked but have their signs removed; the enlarged radiology suite displaces the radiologists’ workroom to another wing, estranging them still further from the patients whose scans they read. It's maturation of a sort, but also a kind of decay; slowly, monuments to rationality become labyrinths.  New hospitals are built when the obsolescence of old hospitals becomes difficult to ignore, but new hospitals can also become old hospitals rather quickly. In Medical Nemesis, his 1974 polemic against biomedicine, the social critic Ivan Illich describes hospitals as “concrete manifestations of those professional prejudices which were fashionable on the day their cornerstone was laid and which were often outdated when they came into use.” Those prejudices can be as nominal as the flooring selected for intensive care units (which, at the hospital where I completed my residency, were inexplicably carpeted) or as consequential as the total number of intensive care beds available in a given city for patients in simultaneous respiratory failure.


Prompt: All of which is to say that there’s a limit to how nimble hospitals can be in their readiness for the future, despite what their exteriors seem to promise—a point that our collective experience with COVID-19 makes plain. According to its promotional video, my university’s new building was “designed to be ready for technologies decades down the road.” This breathless rhetoric corresponds to fairly basic practices, less anticipatory than agnostic (involving, for example, multipurpose rooms designed with a lot of electrical outlets). And however flexible it may purport to be, much of the new hospital will lie dormant so long as our clinical attention is preoccupied with one particular virus and the comparatively basic technologies—masks, swabs, ventilators—needed to manage it.  Masks in Brown Paper Bags Once the pandemic recedes, where will we cast blame and seek reform? Politicians, wet markets, global supply chains—but probably not the megahospital. Most messaging from the medical-industrial complex, from drug advertisements to corporate hospital slogans, reinforces a belief in scientific progress, the reversibility of physical distress, and the usefulness of technology in both regards. These pre-pandemic ideals of biomedicine seem likely to persist in the post-COVID era, as does our tendency to celebrate them through the usual tropes of megahospital design. But these buildings’ failure to prevent a great deal of death has tinged their formidable architecture with irony, and I wonder whether there are subtler ways in which our movement through these spaces might change.

Response: Just before my stint in the emergency room tents, I finished a week-long rotation as a consultant gastroenterologist for patients admitted to the old hospital with various perennial complaints—trouble eating, painless jaundice, bloody stools. In order to keep protective equipment available for the clinical areas where they were needed most, including the tents and the ICU, respiratory masks were being carefully rationed from a central location—a control desk that oversees the building’s forty or so operating rooms. Rather than discarding our masks at the end of the day, we were asked to return them in brown paper bags, writing our names on the front, like schoolchildren, so that they could be disinfected for two hours with ultraviolet light and later reused.  It was a long walk to the control desk from my office—past plaques bearing the names of erstwhile benefactors, past stairwells going up twelve flights, past rows of sleeping computers, past empty recovery bays, past unplugged fluoroscopic imaging machines stacked against the walls. Because my practice is focused on outpatients, my hospital-based rotations are rare, and on each one I have to make an effort to remember my way around. But it’s pleasant to get reacquainted with the vastness of the enterprise; the complexity of these spaces can beguile clinicians too. There’s plenty to marvel at along the way to preserving a two-dollar bit of air-filtering fabric—such a ridiculously simple thing, in the grand scheme, to be holding onto so tightly.


Prompt: How did you end up reading this text? If you’re reading it online, you may have clicked a link in an algorithmically generated list of recommendations or search results. Or maybe a friend sent you the link—after finding it in an algorithmically generated list. Whatever the chain of events that brought you here, it likely involved a system of information retrieval.  Such systems select a handful of choices from billions of possibilities. Their existence is inevitable: at any given time, we can only comprehend a small portion of an immense world. The problem is that the systems that filter the world are not designed for your benefit but for corporate profit. No word captures the dominant form of information consumption on the internet more aptly than “feed”—a ubiquitous term derived from an agrarian metaphor. As in animal husbandry, your information diet is engineered to maximize the yield of a business operation.

Response: If Silicon Valley’s PR departments claim that their products simply “find the most relevant, useful results in a fraction of a second, and present them in a way that helps you find what you’re looking for”—this is how Google describes its search algorithms on its website—executives and shareholders know better. They know that the whole point of the business is to get paid to show you things that you’re not looking for: ads.


Prompt: The conflict of interest between advertisers and users has always been evident to the designers of commercial search engines. In 1998, a few months before the incorporation of Google, graduate students Sergey Brin and Lawrence Page presented their prototype of a web search engine at an academic conference. In an appendix to their paper, they commented, “We expect that advertising funded search engines will be inherently biased towards the advertisers and away from the needs of the consumers.” Indeed. More than two decades after this prophecy, all major search engines, Google first among them, now operate precisely on the business model of surveillance-fueled targeted advertising.

Response: These search engines’ algorithms are optimized for profit. The advertising industry governs the bulk of research and development in the field of information retrieval. Computer scientists and engineers often measure the “relevance” of potential results and test the “performance” of candidate algorithms according to evaluation benchmarks and validation data sets dictated by industry priorities. The predominant systems are designed to maximize ad revenues and “engagement” metrics such as “click-through rates.” Consequently, these systems tend to promote content that is already popular or similar to what users have seen or liked before. Whether the predictions of popularity and similarity are based on simple correlation and regression analysis or on complex machine learning models, the results tend to be predictable and like-minded.


Prompt: No wonder the public sphere seems so impoverished in the digital age. The systems that manage the circulation of political speech were often originally designed to sell consumer products. This fact has momentous consequences. Recent scholarship has documented the disastrous effects of “surveillance capitalism,” and in particular how commercial search engines deploy “algorithms of oppression” that reinforce racist and sexist patterns of exposure, invisibility, and marginalization. These patterns of silencing the oppressed are so pervasive in the world that it may seem impossible to design a system that would not reproduce them.

Response: But alternatives are possible. In fact, from the very beginnings of informatics—the science of information—as an institutionalized field in the 1960s, anti-capitalists have tried to imagine less oppressive, perhaps even liberatory, ways of indexing and searching information. Two Latin American social movements in particular—Cuban socialism and liberation theology—inspired experiments with different approaches to informatics from the 1960s to the 1980s. Taken together, these two historical moments can help us imagine new ways to organize information that threaten the capitalist status quo—above all, by facilitating the wide circulation of the ideas of the oppressed.


Prompt: Struggle on the Library Front What happens the day after the revolution? One answer is the reorganization of the library. In 1919, Lenin signed a resolution demanding that the People’s Commissariat of Enlightenment “immediately undertake the most energetic measures, firstly to centralize the library affairs of Russia, secondly to introduce the Swiss-American system.” Lenin presumably referred to the organization of the European libraries he had observed during his exile from Russia in the early 1900s. By imitating the “Swiss-American system,” the Bolshevik leader hoped to create a single state system of centralized control over the distribution of books and the development of collections.

Response: Four decades later, Cuban revolutionaries also recognized the importance of what Soviet leaders like Nadezhda Krupskaya had once called the struggle “on the library front.” In the aftermath of the Cuban Revolution in 1959, Fidel Castro appointed librarian María Teresa Freyre de Andrade as the new director of the Jose Martí National Library in Havana. A lesbian and long-time dissident who had been exiled and jailed by the previous regimes, she had long been concerned with the politics of librarianship. In the 1940s, she had articulated her vision of a biblioteca popular, a “popular library,” distinct from a merely “public” one. Whereas the public library may be a “rather passive” one where “the book stands still on its shelf waiting for the reader to come searching for it,” the popular library is “eminently active” as it “makes extensive use of propaganda and uses different procedures to mobilize the book and make it go in search of the reader.”  After the revolution, Freyre de Andrade and her staff began to enact this vision. They brought books to the people by sending bibliobúses, buses that served as moving libraries, to rural areas where no libraries existed. They also began to develop a novel practice of revolutionary librarianship. Unlike with Lenin, the goal was not to imitate the organization of European libraries. In a 1964 speech, Freyre de Andrade argued that Cubans could not simply “copy what the English do in their libraries.” By doing so, “we would have a magnificent library, we would have it very well classified, we would provide a good service to many people, but we would not be taking an active part in what is the Revolution.”  How could librarians take an active part in the revolution? One answer was to gather and index materials that had been excluded or suppressed from library collections in the pre-revolutionary period, such as the publications of the clandestine revolutionary press of the 1950s. But librarians also became involved in a broader revolutionary project: Cuba’s effort to build its own computing industry and information infrastructure. This project ultimately led to a distinctive new field of information science, which inherited the revolutionary ideals of Cuban librarianship.


Prompt: The Redistributing of Informational Wealth Both the revolutionaries and their enemies recognized that information technology would be a strategic priority for the new Cuba. A former IBM executive recalls that “all of the foreign enterprises had been nationalized except for IBM Cuba,” since the “Castro government and most of the nationalized companies were users of IBM equipment and services.” But from 1961–62, IBM closed its Cuban branch, and the US government imposed a trade embargo that prevented Cuba from acquiring computer equipment. This meant that Cuba would be forced to develop its own computing industry, with help from other socialist countries in the Soviet-led Council for Mutual Economic Assistance (Comecon).

Response: Between 1969 and 1970, a team at the University of Havana created a prototype of a digital computer, the CID-201, as well as an assembly language named LEAL, short for “Lenguaje Algorítmico” (Algorithmic Language), an acronym that also means “loyal.” The design of the CID-201 was based on the schematics found in the manual of the PDP-1, a computer manufactured by the US-based Digital Equipment Corporation. Because of the US-imposed trade embargo, the team could not buy the necessary electronic components in Europe, but eventually succeeded—with the help of a Cuban man of Japanese descent who worked as a merchant in Tokyo—in bringing the components from Japan inside more than ten briefcases.  Cuban mathematicians also wrote a computer program in LEAL for playing chess; one of the CID-201’s engineers recounts that the computer even played—and lost—a game against Fidel Castro. Starting in the 1970s, Cuba manufactured thousands of digital computers, and even exported some computer parts to other Comecon countries.


Prompt: The rise of digital computing transformed Cuban librarianship. Freyre de Andrade welcomed the digital age, paraphrasing Marx and Engels to analogize computing to communism: “a specter is haunting the informational world, the specter of the computer; and let’s be pleased that this circumstance has come to move our field [of librarianship], giving us a challenge that makes [the field] even more interesting than it already was by itself.” Cubans studied the techniques of informatics mostly with Soviet textbooks translated into Spanish. They combined the computational methods they learned from these books with the revolutionary ideals of Cuban librarianship. This synthesis produced distinctive theories and practices that diverged substantially from those of both Western and Soviet informatics.

Response: Consider the concept of “information laws,” a staple of informatics textbooks. A classic example is “Lotka’s law,” formulated in 1926 by Alfred J. Lotka, a statistician at Metropolitan Life Insurance Company in New York, who sought to compute the “frequency distribution of scientific productivity” by plotting publication counts of authors included in an index of abstracts of chemistry publications. He claimed that the distribution followed an “inverse square law,” i.e., “the number of persons making 2 contributions is about one-fourth of those making one; the number making 3 contributions is about one-ninth, etc.; the number making n contributions is about 1/n² of those making one.” Like Western textbooks, the Soviet textbooks of informatics adopted in Cuba covered such “information laws” in depth. Their main authors, Russian information scientists and engineers A. I. Mikhailov and R. S. Gilyarevskii, quoted a peculiar passage by US information scientist and historian of science Derek de Solla Price on the distribution of publication counts: “They follow the same type of distribution as that of millionaires and peasants in a highly capitalistic society. A large share of wealth is in the hands of a very small number of extremely wealthy individuals, and a small residual share in the hands of the large number of minimal producers.” For Cuban information scientists, who had experienced a socialist revolution and an abrupt redistribution of material wealth, this unequal distribution of informational wealth also had to be radically transformed. Among these information scientists was Emilio Setién Quesada, who had studied and worked with Freyre de Andrade since the beginning of the post-revolutionary period. Setién Quesada contested the very idea of an “information law.” In an article co-authored with a Mexican colleague, he objected to the term “law,” which seemed to imply “the identification of a causal, constant, and objective relation in nature, society, or thought.” The mathematical equations represented mere “regularities,” without expressing “the causes of qualitative character of the behaviors they describe.” Those causes were historical, not natural.


Prompt: Therefore, Setién Quesada and his colleague argued, publication counts did not conclusively determine the “productivity” of authors, any more than declining citation counts indicated the “obsolescence” of publications. Cuban libraries shouldn’t rely on these metrics to make such consequential decisions as choosing which materials to discard. Traditional informatics was incompatible with revolutionary librarianship because, by treating historically contingent regularities as immutable laws, it tended to perpetuate existing social inequalities.

Response: Cuban information scientists didn’t just critique the limitations of traditional informatics, however. They also advanced a more critical approach to mathematical modeling, one that emphasized the social complexity and the historical contingency of informational regularities. In the 1980s, when Cuban libraries were beginning to adopt digital computers, Setién Quesada was tasked with developing a mathematical model of library activity, based on statistical data, for the purpose of economic planning. But he was dissatisfied with existing models of the “intensity” and “effectiveness” of library activity, devised by Soviet and US information scientists. (In the discussion below, I include mathematical explanations inside parentheses for interested readers, following Setién Quesada’s own terminology and notation.)  Soviet information scientists computed the “coefficient of intensity” of library activity by multiplying the “index of circulation” (the number of borrowings m divided by the number of potential readers N) by the “index of rotation” (the number of borrowings m divided by the total volume of holdings f). Meanwhile, US information scientists computed the “measure of effectiveness” of libraries, combining the index of circulation with an “index of capture” (the number of actual library readers n divided by the number of potential readers N). In contrast to these two approaches, Setién Quesada proposed an alternative “Cuban model,” which evaluated what he called the “behavior of Cuban public libraries”: “Coefficient of intensity” (Soviet authors)   “Measure of effectiveness” (US authors)  “Cuban model” Setién Quesada argued that “the Cuban model is more complete.” It included many more variables, all of which he considered important. For instance, the Cuban model included an “index of communication” (based on the number l of readers who use the archive), while the Soviet and US models “do not express the precise level of the author-reader social communication that happens in libraries.” Moreover, those other models “do not consider the role of the librarian in the development of the activity.” For Setién Quesada, the librarians, “together with the readers, constitute the main active agents involved in the development of this activity.” Hence in the Cuban model, every variable was adjusted relative to the number of librarians (incorporated into the adjusted variables denoted by a vinculum). Finally, the other models “do not offer an index that synthesizes the comparative behavior of places and periods.” By contrast, the Cuban model sought to facilitate comparisons of different libraries and time periods (each represented by the subscript i).


Prompt: Whatever the merits and limitations of this particular mathematical model, the broader story of Cuban information science encourages us to be skeptical of the claims attached to models and algorithms of information retrieval in the present. If yesterday’s information scientists claimed that their models ranked authors by “productivity” and libraries by “effectiveness,” today’s “AI experts” claim that their algorithms rank “personalized” search results by “relevance.” These claims are never innocent descriptions of how things simply are. Rather, these are interpretive, normative, politically consequential prescriptions of what information should be considered relevant or irrelevant.  These prescriptions, disguised as descriptions, serve to reproduce an unjust status quo. Just as print publications should not be deemed obsolete and discarded from library collections on the basis of citation counts, online information should not be deemed irrelevant and ranked low in search results on the basis of “click-through rates” and ad revenues. The innovative experiments by Cuban information scientists remind us that we can design alternative models and algorithms in order to disrupt, rather than perpetuate, patterns of inequality and oppression.

Response: A Network Theory of Liberation Theology The Cuban experiments were supported by a socialist state. But experiments with anti-capitalist informatics are also possible in the absence of such a state. In fact, another major undertaking took place in countries that were controlled by US-backed right-wing military dictatorships.


Prompt: In many Latin American countries, including Brazil after the 1964 military coup, authoritarian regimes took violent measures to silence dissidents, such as censorship, imprisonment, torture, and exile. Some of the most vocal critics of these measures were Catholic priests who sought to reorient the Church toward the organizing of the oppressed and the overcoming of domination. A key event in the formation of their movement, which would become known as “liberation theology,” was a 1968 conference of Latin American bishops held in Medellín, Colombia. At the landmark conference, the attendees learned of the dynamics of oppression in different countries, and collectively declared, “A deafening cry pours from the throats of millions of men, asking their pastors for a liberation that reaches them from nowhere else.” How could this cry be heard? The Medellín experience inspired a group of liberation theologians, largely from Brazil, to try to envision new forms of communication among poor and oppressed peoples across the world. Their objective was conscientização, or “conscientization”: the development of a critical consciousness involving reflection and action to transform social structures—a term associated with their colleague Paulo Freire, who had developed a theory and practice of critical pedagogy. Towards that end, the theologians planned to organize a set of meetings called the “International Journeys for a Society Overcoming Domination.” But international meetings were prohibitively expensive, which meant many people were excluded. One of the project organizers, the Brazilian Catholic activist Chico Whitaker, explained that “international meetings rarely escape the practice of domination: in general they are reduced to meetings of ‘specialists’ who have available the means to meet.” To address this problem, the liberation theologians and allied activists envisioned a system of information diffusion and circulation that they called an “intercommunication network.” This network would make available “information that was not manipulated and without intermediaries,” break down “sectoral, geographic, and hierarchical barriers,” and make possible “the discovery of situations deliberately not made public by controlled information systems.”

Response: By “controlled information systems,” the organizers referred to the severe state censorship of print and broadcast media that had become prevalent across Latin America. Liberation theologians wanted the liberation of information, which would enable a new phase of Freirean pedagogy: from the era of “‘conscientization’ with the intermediaries” to that of direct “‘inter-conscientization’ between the oppressed,” in Whitaker’s words.


Prompt: Since the modern internet was not yet available in the 1970s, the operation of the “intercommunication network” relied on print media and the postal service. The organizers set up two offices, called “diffusion centers”: one in Rio de Janeiro, at the headquarters of the National Conference of Bishops of Brazil where Brazilian bishop Cândido Padin, an organizer of the Medellín conference, served as project coordinator; and another in Paris, where Whitaker lived in exile with his wife, Stella, another Brazilian activist, because of his role in land reform planning before the 1964 military coup.  The diffusion centers received and distributed, by mail, submissions of short texts (or five-page summaries of longer texts) analyzing situations of “domination” from a worldwide network of participant organizations, connected via regional episcopal conferences in Latin America, North America, Africa, Europe, Asia, and Oceania. Whitaker emphasized that the texts should ideally be written by “those who have the greatest interest in the overcoming of domination, namely, those who are subject to it,” and should include “analysis of their own situations and the struggles that they were developing to liberate themselves from domination.” The organizers published every text that matched the basic requirements, without any editorial modification; translated each text into four languages (Portuguese, Spanish, French, and English); and mailed all texts for free to participants in more than ninety countries.

Response: For Whitaker, the concept of intercommunication was rooted not only in “freedom of expression” but also in “liberty of information”: the ability for all participants to have access “to everything that the others wish to communicate to them and which serves the realization of the objectives which they share.” Intercommunication sought to produce radical equality: “All must be able to speak and be listened to regardless of the hierarchical position, level of education or experience, social function or position, moral, intellectual, or political authority of each.” The practice of intercommunication demanded the “acceptance to heterogeneity and of the ‘dynamic’ of conflicts that go with it,” Whitaker wrote.  Finally, intercommunication required an exercise of “mutual respect” and “openness towards the others” that reflected the Christian principle of fraternity: as Whitaker put it, “the respect for what the other thinks or does… the receptiveness to what is new and unexpected, to that which poses questions to us or challenges us, or to perspectives and preoccupations that we would have been able to leave aside because they are difficult to accept.” Despite the importance of Christian values, however, the intercommunication network was open to anyone. Some participants were non-Catholic, non-Christian, and even non-religious. Padin explained that as “children of God, we are in Christ all brothers, without any distinction.” The Freedom to be Heard Over the years, the intercommunication network circulated an extraordinary diversity of texts. Chadian participants examined the social consequences of cotton monoculture since its imposition under French colonial rule. Sri Lankan participants reviewed the labor conditions in the fishing industry, the profiteering tactics of seafood exporters, and the limitations of fishing cooperatives set up by the state. Panamanian participants narrated their struggle for housing and their formation of a neighborhood association. From Guinea-Bissau, a group of both local and foreign educators, including Paulo Freire, wrote about the challenges of organizing a literacy program and changing the education system in the aftermath of the war of independence. Between 1977 and 1978 alone, nearly a hundred texts circulated in the network. These were later compiled into a monumental volume, published in four languages and discussed at regional meetings of network participants across the world.


Prompt: This volume featured an unusually sophisticated system of indexing. Each text had a code composed of a letter and a number; for example, the aforementioned Chadian text had the code “e35.” The letters indicated the type of text—“e” for case studies, “d” for discussion texts, “r” for summaries—and the numbers were assigned chronologically. The volume was divided into sixteen numbered sections, each about a different theme of “domination.” Section III focused on “domination over rural workers,” section IV on “non-rural workers,” section VII on “domination in housing conditions,” section X on “health conditions.”  Each text was printed inside one of the thematic sections, but since the classifications were not mutually exclusive, the index of each section also listed texts that intersected with the theme despite being from different sections. For instance, the index of section IX, on education, listed some main texts—“e4” from Thailand, “e6” from Guinea-Bissau, “e38” from the Philippines—as well as other texts from different sections, like “r3” from section X, which discussed the intersection of health and education in structures of domination. The end of the volume featured an additional index that classified texts according to “some particular categories of victims of domination”: “women,” “youth,” “children,” “elderly people,” and “ethnic groups.” The astonishing diversity of texts circulated by the intercommunication network soon brought its organizers into conflict with conservative factions of the Catholic Church. In 1977, some readers were especially scandalized by text “e10,” submitted by a small, women-led, self-described “community of Christian love” in rural England. The text bothered conservatives not only for its explicit denunciation of “the Roman Catholic Church as an instrument of domination” engaged in “a kind of efficient and specialized ‘brain washing,’” but also for its feminist proposals, which included the refusal “to call anyone ‘father’ in a clerical context” and the commitment to “calling the Holy Spirit ‘She’ and not ‘He.’”

Response: After a long deliberation at the Rio de Janeiro diffusion center, the project organizers decided to publish the text along with a note restating their commitment to free expression and reminding readers of the minimal requirements for publication. Still, conservative bishops complained to Vatican authorities, who were increasingly concerned by the rise of liberation theology in Latin America and beyond. Pope Paul VI, who did not sympathize with the project, sent emissaries to Brazil to intervene. The Vatican demanded that the bishops stop, claiming that the conference in Rio de Janeiro “could not take an initiative of such breadth, and had surpassed its competence by inviting other episcopal conferences to join the project.” By building a distributed worldwide network via regional conferences, the liberation theologians had bypassed the central authority of the Vatican. Despite the Vatican’s order to stop the project, a group of Brazilian organizers continued in disobedience until 1981.


Prompt: Later on, former organizers reflected on the relationship between their intercommunication network and the modern internet. They did not know that in the original paper on the Transmission Control Protocol (TCP), which outlined the technology that serves as the basis of the internet, engineers Vinton G. Cerf and Robert E. Kahn had spoken of a protocol for packet “network intercommunication”—or simply an “internetwork” protocol, leading to the contraction “internet” a few months later. The paper had appeared in 1974, when the liberation theologians were planning their similarly named network.  In 1993, reflecting on the two internets, Chico Whitaker theorized that the “network” is an “alternative structure of organization,” much less common in “Western culture” than the “pyramidal structure”:  Information is power. In pyramids, power is concentrated, so also information, which is hidden or kept to be used at the right time, with a view to accumulating and concentrating more power. In networks, power is deconcentrated, and so is information, which is distributed and disseminated so that everyone has access to the power that their possession represents.  There is no doubt that Whitaker and his colleagues were prone to techno-utopianism. Their hope that technological progress would finally enable a “free” circulation of information was a fantasy, since various sorts of machine decisions and human labor, structured by political-economic conditions, always filter what information circulates and to whom. Techno-utopian conceptions of “information freedom,” whether in the Californian libertarian-capitalist version or in the Brazilian liberation-theological one, are never quite right.

Response: Yet there is a crucial difference between the two conceptions. The Californian version of information freedom is largely limited to a particular understanding of freedom of speech. The Silicon Valley firms that manage public discourse on the internet, such as Facebook, appeal insistently to “free speech” as an excuse for their business decisions to profit from posts and ads that spread right-wing misinformation.  The remarkable innovation of the Brazilian liberation theologians is that they moved beyond a narrow focus on free speech and toward a politics of audibility. The theologians understood that the problem is not just whether one is free to speak, but whose voices one can hear and which listeners one’s voice can reach. The intercommunication network was meant to produce more equitable conditions not just for speaking, but for listening and for being heard. Ultimately, the network’s purpose was to amplify the voices of the oppressed. Today, our task is to reformulate this more critical conception of information freedom for the digital age. Information will be “free” only when the oppressed can be heard as loudly as their oppressors.


Prompt: The Retrieval of History The history of technology is too often told as a linear progression, as a series of tales of triumphant inventors, emanating mainly from North America and Western Europe. Such tales are pervasive in part because they are easy to tell. After a certain technology prevails, the storyteller can simply follow the records and narratives given by the handful of people who are already credited for its invention.

Response: Such commonplace narratives serve important ideological functions. First, they legitimize capitalist accumulation by framing the inventor-entrepreneur’s fortune as the merited payoff for an ingenious idea. This requires erasing all other contributors to the given technological artifact; in the case of search engines, it means forgetting the librarians (whose feminized labor is never valued as creative) and the information scientists whose cumulative work over the course of decades laid the foundation for Google.


Prompt: More insidiously, such narratives also serve to sanction the dominant technologies by presenting them as the only ones ever conceivable. They overlook the many possible alternatives that did not prevail, thereby producing the impression that the existing technologies are just the inevitable outcome of technical ingenuity and good sense.

Response: If peripheral innovations like the Latin American experiments with informatics did not become mainstream, this is not because they were necessarily inferior to corporate, military, and metropolitan competitors. The reasons why some technologies live and others die are not strictly technical, but political. The Cuban model was arguably more technically sophisticated than its US counterparts. Yet some technologies are sponsored by the advertising industry, while others are constrained by a neocolonial trade embargo. Some are backed by the Pentagon, others crushed by the Vatican.


Prompt: It is crucial to recover those lost alternatives, for they show us how technologies could have been otherwise—and could still become so in the future. However, these histories are difficult to retrieve. Their protagonists may remain anonymous and their records unpreserved.  No search engine pointed me to the Latin American experiments. I could never have found them through traditional methods for searching the internet. Instead, I came across subtle clues through serendipitous conversations. I was chatting with Theresa Tobin, a retired librarian at the Massachusetts Institute of Technology who co-founded the Feminist Task Force at the American Library Association in 1970. She commented that after she fundraised to donate a digital computer to a Sandinista library in the 1980s, Nicaraguan librarians used it to implement a Cuban system for indexing materials.

Response: I set out to learn more about the Cuban system, a task that proved laborious. Even the most important sources on Cuban information science are hard to find using conventional search engines and databases. For instance, despite the prominence of María Teresa Freyre de Andrade, Google Scholar does not index her main books, and Wikipedia lacks an entry on her in any language. On the other hand, the Cuban online encyclopedia, EcuRed, features an extensive article on her. I also managed to find a few initial references on Cuban informatics in SciELO, a Latin American bibliographic database. I then contacted Cuban scholars directly to ask for help.  My discovery of the liberation theologians’ intercommunication network took a similar path. When I first met Stella and Chico Whitaker at the World Social Forum in Porto Alegre, which they co-founded in 2001, I had never heard of the intercommunication network. It was only years later, when I was helping the couple donate their personal papers to a public archive, that they mentioned in passing that one of the dusty boxes in their apartment contained documents from an old project involving informatics. They were surprised I showed interest. Sometimes the best method of information retrieval is talking to people.


Prompt: Many more vital ideas for alternative futures, technological and otherwise, remain forgotten in dusty boxes across the world. The repressed dreams of past struggles will not easily appear on our corporate algorithmic feeds. To recover these lost ideas, we must develop more critical methods of information retrieval, continuing the work that the Latin American experiments left unfinished. In short, we need critical search.

Response: The project of critical search would recognize that any quantification of “relevance” is an interpretive, normative, and politically consequential act. Critical search would actively strive to increase the visibility of counterhegemonic intellectual traditions and of historically marginalized perspectives. We must build systems of information diffusion and circulation that seek to amplify critical voices and to cut across linguistic, national, racial, gender, and class barriers. Let us draw inspiration from our predecessors, and try to follow in their footsteps. Let us experiment with algorithms, interfaces, and tactics for reindexing the world anew.


Prompt: In early 2014, I attended the demonstration of an experimental technology funded by DARPA, the US military’s advanced research and development agency. In a conference room at a Los Angeles office park, a young man sat on stage before a computer screen, with cameras trained on his face and body. On the screen, a rudimentary 3D model of a casually dressed young woman sat upright in a plush armchair of the type one might find in a psychotherapist’s office. The character said her name was Ellie and that she was not a therapist, but created “to talk to people in a safe and secure environment.” Another monitor, visible to the audience but not to the man, displayed real-time information from the cameras, tracking his posture, eye movement, and the changing shape of his mouth.

Response: “I’ll ask a few questions to get us started,” Ellie said, regarding the man with an unnervingly neutral gaze. “And please feel free to tell me anything. Your answers are totally confidential.” As the demonstration proceeded, Ellie asked if he could recall the last time he felt truly happy. He didn’t have a ready answer, and the system’s computer vision software detected that he was breaking eye contact more than he had earlier in the conversation. “I noticed you were hesitant on that one,” Ellie said.


Prompt: Ellie’s goal was to conduct conversations that would allow the software to pick up “distress indicators,” from evasive glances to “negatively valenced words,” that are “correlated with depression, anxiety, or post-traumatic stress disorder,” researchers from the Institute for Creative Technologies at the University of Southern California, where the system was designed, wrote in a subsequent paper. To that end, Ellie was made to seem highly empathetic. “A particular concern in the design … was whether users would feel comfortable enough in the interaction to speak openly about their mental health issues to a virtual agent,” the researchers wrote.

Response: Though Ellie was obviously virtual, there were potential advantages to this. DARPA was funding ICT’s research through a larger program called DCAPS, the Detection and Computational Analysis of Psychological Signals, which aimed to “develop novel analytical tools to assess psychological status of warfighters in the hopes of improving psychological health awareness and enabling them to seek timely help,” the agency said. After the demo finished, one of the researchers explained to the room that speaking to a virtual avatar about mental health issues could be ideal for military personnel who are taught to be and act tough, leaving them too ashamed to open up to another human being.


Prompt: Something like Ellie could be useful to the military in other ways, too. To identify and help all current and former personnel with PTSD would be a massive undertaking. Estimates from the US Department of Veterans Affairs suggest that between 11 and 20 percent of the 2.7 million service members who deployed to Iraq and Afghanistan—roughly 300,000 to 540,000 people—suffer from the disorder in any given year. Of those, DARPA says that only a small fraction seek help. It’s difficult to imagine recent administrations deploying the battalions of people—therapists, trainers, outreach personnel—needed to find and care for half a million or more people with PTSD. Automation, of the kind represented by Ellie, seems to hold out the possibility of treating mental health problems at scale, or even keeping soldiers on active duty for longer periods. If successful, computerized therapy could also be applied in other circumstances where human-to-human treatment is undesirable or impractical—such as in the midst of a pandemic.

Response: Behind this possibility lurks a larger vision, too. Though the Ellie program is in some ways crude, it seems to herald a future system that can continuously track, report, and support users’ mental health on an ongoing basis. At the time of the demo, consumer devices like the Fitbit and Apple Watch were being marketed on the basis of their round-the-clock monitoring and data-collection features for physical health—information which would yield life-improving insights and interventions, the companies behind these technologies implied. More recently, researchers affiliated with Amazon published a paper describing efforts to determine a user’s emotional state from their voice. If an Amazon Alexa divined you were upset, it could ask what was wrong—and maybe upsell you on some indulgent self-care items. Supporting mental health could be one more reason to justify the ambient collection and interpretation of vast streams of data from our bodies and behavior.


Prompt: After seeing the DARPA demo, I was unsettled by the idea of an emotionally-aware technology ecosystem constantly reporting back to companies or governments about our mental states, and then trying to intervene in them. But the thing I kept coming back to most often was the avatar of Ellie, sitting in her chair with her hands folded in her lap, calmly interviewing an actual human being with a potential mental illness. As a designer and writer of video games, I know that well-crafted interactive digital characters can elicit deep emotions from players, causing changes in their mood and outlook, just as powerful works in any medium can. Until I encountered Ellie, though, I hadn’t imagined what it would mean for people to share their most private thoughts and feelings with a machine. I wondered whether this artificial interaction could actually help people change, or even heal. So, in a spirit of curiosity, I set out to create a sort of Ellie of my own.

Response: An Algorithm for Thoughts When I began researching computerized therapy, virtual mental health care was already a booming category—and that was before the world was struck by the coronavirus. Following the outbreak of COVID-19, the possibility of inexpensive, scalable virtual mental health tools may very well become a necessity. Social isolation, unemployment, pervasive uncertainty, death—the pandemic and society’s response to it have created a wave of emotional distress while at the same time stripping millions of people of their jobs, healthcare, and access to therapy. “With the coronavirus pandemic causing unprecedented levels of stress and grief, companies offering virtual mental health care say they’re seeing a massive surge in interest,” the medical news site STAT recently reported.


Prompt: There’s currently a bewildering array of mental health apps to download, with names such as Calm, Happify, and MindShift. Some of these programs are simply collections of user-directed exercises (“write down how you felt today”). Some seek to connect clients with human therapists over video or text chat. Others contain characters like Ellie. But most of them claim to implement elements of cognitive behavioral therapy, or CBT, a kind of therapy that emerged in the 1960s to become one of today’s most heavily used and studied methods of treating depression, anxiety, and PTSD. For many years, CBT has been considered the most effective treatment for such disorders. One recent meta-analysis of mental health app trials found that over 80 percent of them used CBT in one form or another.

Response: CBT is a heavily “manualized” form of therapy, meaning that it expects providers to stick closely to highly specific, almost scripted interactions with clients. Providers teach clients to recognize negative thoughts and “dispute” them in order to reduce their effect and replace them with positive ones. If the recurrent thought “I’m destined for failure” runs through a patient’s head, for example, CBT prompts them to systematically dispute the thought with alternative interpretations: Is this, perhaps, an exaggeration? Is there really any evidence that this is true? It’s akin to running an algorithm on a thought until its power diminishes and eventually disappears.  As a result, a common complaint from those on the receiving end of CBT is that it is cold, mechanical, and lacks empathy. Writing for Vice about the game I eventually made about a virtual CBT therapist, the critic Rob Zacny said he recognized in it “that sense of emotional whiplash that comes from finally starting to confide something serious and scary, only to be met with weirdly programmatic responses from well-meaning counselors.” But the mechanistic quality of CBT also makes it especially well-suited to be supplemented by, or turned entirely into, a computer program. If your human therapist already acts and sounds like an automaton, what would be lost by replacing him with one?  But virtual characters can only be effective if on some level we believe or buy into them. In a 2016 article for the Guardian about new questions surrounding CBT’s efficacy, the journalist Oliver Burkeman spoke with a woman who had experienced postnatal depression. “I don’t think anything has ever made me feel as lonely and isolated as having a computer program ask me how I felt on a scale of one to five, and—after I’d clicked the sad emoticon on the screen—telling me it was ‘sorry to hear that’ in a prerecorded voice,” she told him. What she realized she needed, Burkeman writes, was “real connection: that fundamental if hard-to-express sense of being held in the mind of another person, even if only for a short period each week.”


Prompt: Patients aren’t the only ones who have recognized this need. In 1976, a computer scientist at MIT named Joseph Weizenbaum declared the notion that “a computer can be programmed to become an effective psychotherapist” was nothing but “perverse.” This was a renegade position for the MIT of the era, where a powerful belief in the capabilities of artificial intelligence reigned. Weizenbaum was well aware that he was committing apostasy, but his assault on the idea of computerized therapy was all the more forceful because he had created the first virtual therapist himself.

Response: Alien Worlds The ELIZA program that Weizenbaum created, which he released in 1966, is often called the world’s first chatbot. Cleverly, Weizenbaum designed ELIZA around the stereotype of a psychotherapist’s propensity to turn a client’s statement into a question. (People don’t like me. Why do you think people don’t like you?) This was an elegant way to create the effect of a computer holding its own in a conversation with the user.  Of course, ELIZA, which Weizenbam named after Eliza Doolittle, the character in the George Bernard Shaw play Pygmalion, possessed no real understanding of what its human partner was saying. As the information technologist Ted Nelson wrote of the program in his classic 1974 book about hacker culture, Computer Lib / Dream Machines: “Now, do not be fooled. There is no Ghost in the Machine. The program does not ‘understand’ the user. THE PROGRAM IS MERELY ACTING OUT THE BAG OF TRICKS THAT JOE WEIZENBAUM THOUGHT UP.” The explanation (and emphasis) was necessary because ELIZA’s noncommittal responses were surprisingly good at convincing users either that it did understand them, or that there was actually another human being on the other side of the teletype.  Indeed, ELIZA sometimes seemed to perform flawlessly, as in this example from Weizenbaum’s original 1966 paper describing his creation: Men are all alike.IN WHAT WAYThey’re always bugging us about something or other.CAN YOU THINK OF A SPECIFIC EXAMPLEWell, my boyfriend made me come here.YOUR BOYFRIEND MADE YOU COME HEREHe says I’m depressed much of the time.I AM SORRY TO HEAR YOU ARE DEPRESSEDIt’s true. I am unhappy.DO YOU THINK COMING HERE WILL HELP YOU NOT TO BE UNHAPPYI need some help, that much seems certain.


Prompt: But it is also easy to have a conversation with ELIZA that goes nowhere: HOW DO YOU DO. PLEASE TELL ME YOUR PROBLEMI have so much work to do.THAT’S QUITE INTERESTINGNot really.THAT IS INTERESTING. PLEASE CONTINUEIt’s not.DO YOU FEEL STRONGLY ABOUT DISCUSSING SUCH THINGS It usually becomes clear to modern users within minutes how fragile ELIZA’s illusion of real conversation is. In the late 1960s, however, the program left a lasting impression. The astrophysicist and science popularizer Carl Sagan, in a 1975 essay for Natural History magazine, predicted a time in which such therapy would be commonplace, delivered through “a network of computer psychotherapeutic terminals, something like arrays of large telephone booths.” Even established mental health professionals began to seriously consider the idea of computerized therapy. Perhaps most notable was the psychiatrist Kenneth Colby, who later developed his own mental health chatbots and once told a reporter, “after all, the computer doesn’t burn out, look down on you, or try to have sex with you.”  Weizenbaum himself believed that ELIZA only demonstrated that computers did not have to actually understand anything in order to mimic everyday conversations. The year after ELIZA was released, his more famous colleague at MIT, Marvin Minsky, declared that “within a generation, the problem of creating ‘artificial intelligence’ will substantially be solved.” But ELIZA helped Weizenbaum to develop a more skeptical view of computer science, and of the relationship between computer and human intelligence.

Response: Weizenbaum argued that even if a future computer were powerful enough to perform automated therapy, it would still be wrong. Human intelligence and computer logic are fundamentally different processes and wholly “alien” to one another, he wrote in his 1976 book Computer Power and Human Reason. As Zachary Loeb explains in the introduction to Islands in the Cyberstream, a posthumously published interview with Weizenbaum, “Computers excelled at tasks involving quantification, but for Weizenbaum there was much about human beings that simply could not be quantified.” As tempting as it was for computer scientists to believe that computers could model the world around them or human thought, in truth they could only create their own separate reality. “If Weizenbaum called for renunciation of the computer, in certain contexts,” Loeb continues later, “it was because the embrace of the computer in all contexts had led to a renunciation of the human.” In her paper “Authenticity in the age of digital companions,” Sherry Turkle, a fellow MIT professor who taught classes with Weizenbaum, recounted how ELIZA’s reception informed his stance: Weizenbaum found it disturbing that the program was being treated as more than a parlor game. If the software elicited trust, it was only by tricking those who used it. From this viewpoint, if Eliza was a benchmark, it was because the software marked a crisis in authenticity: people did not care if their life narratives were really understood. The act of telling them created enough meaning on its own.


Prompt: Perhaps this is the most salient question when it comes to automated therapy: can the act of telling be separated from the act of listening? Does simply speaking create enough meaning on its own? If being listened to, recognized and understood by another human being is the source of therapy’s power, then there is no way bundles of code—such as ELIZA, Ellie, or the fictional app in the game I eventually created—could work. Automated mental health care would be built on a faulty premise about what therapy should be and what computers can ultimately do.

Response: Talking to the Dog Almost all of today’s mental health apps are built on that potentially flawed premise. Many take the form of an instant message–like interface with a friendly character, making comparisons to ELIZA difficult to avoid. One prominent example is Woebot, which boasts Stanford-linked founders and closed an $8 million funding round in 2018. As with its distant ancestor, Woebot’s lack of genuine human understanding is easily revealed. Telling the program I was feeling anxious about the fact that “I have so much work to do” resulted in this stilted interrogation, which reads as if it comes straight out of a CBT manual: Are you perhaps catastrophizing in your statement?NoAre you Future Predicting with your thought, “I have so much work to do”?NoYou’re doing awesome thinking through this by the way… we’re nearly thereAre you ‘Mind-reading’ in your thought, “I have so much work to do”?NoHow about black-or-white thinking in this thought: “I have so much work to do”?NopeGot itAnd is there a chance that you may be mistaking your feelings as evidence of the truth?NoOK Matthew, you did a great job there…Now for the most important bit… rewrite “I have so much work to do” without those distortions.I have so much work to doSo how did your rewrite go? The smarmy attitude and rigid dialogue of apps like Woebot makes one sympathetic to Weizenbam’s view that computerized therapy is inhumane. At the same time, I couldn’t help but notice again the similarity to my own work as a game developer. Using a bag of tricks not unlike the ones Weizenbaum used to create ELIZA, many games invite players to believe that digital characters are friends who can perceive and understand them in some way. Combinations of animations, sounds, and contextually appropriate behaviors create illusions not only of life, but of genuine communication between the alien worlds of humans and computers.


Prompt: Taking advantage of “the human propensity to suspend disbelief in the presence of a persuasive dramatic presence” was the “true source of Eliza’s power,” the digital media pioneer Janet Murray wrote in her groundbreaking 1997 book Hamlet on the Holodeck. In the world of games, these persuasive dramatic presences are (usually) clear about what they really are—characters. Game developers still rely on audiences to voluntarily buy into them at some level, in a parallel to the way the live theater becomes reality, though only temporarily. The actor who was stabbed to death during the play returns to the stage at the curtain call; the gamer eventually takes off their VR headset. What happened inside the magic circle was certainly not “true,” but was also, in a way, real, and exerted a powerful effect on those who experienced it.

Response: Might this be all that it is needed for automated psychotherapy to work? In the nearly fifty-five years since ELIZA first appeared, very few digital characters have made an attempt to understand their users in any real way. The reason might be that they simply don’t have to in order to be compelling. And in that case, does it really matter if a therapy program understands its user or not? One of the principal investigators on the project that created Ellie, the computer science professor Louis-Pilippe Morency, compared the experience to talking to a pet. “Some people talk to their dogs,” he said, speaking to a journalist for the Atlantic. “Even though the dogs don’t understand it ... I think there's a little bit of that effect—just talking with someone makes you feel better.”  Aside from the fact that dogs aren’t, so far as we know, uploading their data anywhere, this is an important consideration. If the feeling of connection is all that’s needed for successful therapy, then human-to-human interaction may be superfluous. As Turkle asks, “If a person feels understood by an object lacking sentience, whether that object be an imitative computer program or a robot that makes eye contact and responds to touch, can that illusion of understanding be therapeutic? What is the status—therapeutic, moral, and relational—of the simulation of understanding?” Between a Novel and a Game Perhaps because of the shifting priorities of a new administration, DARPA’s interest in mental health has waned since 2014, and it isn’t currently funding research into goals like treating PTSD. But witnessing Ellie at work caused me, over the course of the next several years, to design and draft a video game about the experience of computerized psychotherapy. By early 2019, the world I had slowly been building took its final shape: a present-day Seattle not so different from the real one, where gig workers called “proxies” read prompts given to them by “Eliza,” a cloud-based, AI-powered virtual therapist program developed by a fictional tech giant. The company names the product after Weizenbaum’s program in an attempt to ride its notoriety while, in true tech giant fashion, ignoring its creator’s misgivings.


Prompt: Players guide the game’s main character, Evelyn Ishino-Aubrey, as she takes a job as one of these proxies, performing therapy sessions for a wide variety of people. As a proxy, all she can do is read what the Eliza algorithm has told her to read. Evelyn is warned multiple times not to deviate from the script, priming savvy gamers to believe they will immediately be able to do just that. But Evelyn performs session after session without deviating. For most of the game, I lock the character into being a “good” proxy, even at the expense of upsetting players’ expectations. If Evelyn expresses doubts, she does so privately.

Response: I deny players choice for such a long time because I couldn’t accept the idea of a game where different phrases uttered by a therapist would be considered better or worse for a patient. It’s easy to imagine a game in which a client comes in with certain combinations of conditions, and the challenge for the player is to pick the right things to say to match those conditions. But that would be to accept in advance the notion that a certain type of person needs to hear a certain type of thing in order to be guided to the best possible outcome—an assumption encoded in materials like the CBT manuals I had studied. I wanted to create therapy clients who were irreducible individuals, real fictional human beings. So in opposition to prevailing game design wisdom, I ended up with something in between a novel and a game, something that requires players to be patient and to give up control.


Prompt: Between sessions, Evelyn has lengthy conversations with people who work, or used to work, on Eliza. Some believe the product is working well; others very much don’t. Some see it only as a ladder for their own ambitions in the tech world and beyond. Evelyn must also confront her own past and struggle with depression. As the story of the game concludes, it allows players to decide the best way for Evelyn to move forward in life. Each choice includes some compromise. She could continue to contribute to Eliza. She could take her newfound interest in therapy to pursue a career as a traditional human-to-human therapist. She could turn her back on all of it. This is the first and last major choice the game asks players to make.

Response: A human player playing a virtual human (Evelyn) whose choices are circumscribed by a computer program (Eliza) which is at once both real and a fiction created by me, its human developer: my hope is that these layers of human-computer interaction help to challenge the simple binary between warm and empathetic human-to-human therapy and the encroachment of cold, computerized systems. The reality, of course, is more complicated. Under the manualized framework of CBT and similar modes of treatment, even human therapists act robotically, whereas in ELIZA, a rudimentary but surprisingly expressive computer program emulated a much more humanistic, open-ended style of psychotherapy. It is not about a “computer” approach versus a “human” approach—it is about an indifferent versus a compassionate one.


Prompt: At the time of this writing, in July 2020, the COVID-19 pandemic has killed over 133,000 people in the United States. The dead are disproportionately Black and Latinx people and those who were unable, or not allowed by their employers, to work remotely. During the pandemic, we’ve seen our technological infrastructures assume ever more importance—from the communications technology that allows people with the means and privilege to telecommute, to the platforms that amplify public health information or deadly, politicized misinformation. We’ve also seen some of the infrastructure that runs the social safety net break down under an increasing load. This includes state unemployment systems that pay workers the benefits they’ve contributed to for decades through taxes. In a global pandemic, being able to work from home, to quit and live on savings, or to be laid off and draw unemployment benefits has literally become a matter of life and death.  The cracks in our technological infrastructure became painfully evident in the spring, as US corporations responded to the pandemic by laying off more and more workers. So many people had to file for unemployment at once that computerized unemployment claim systems started to malfunction. Around the country, phone lines jammed, websites crashed, and millions of people faced the possibility of not being able to pay for rent, medicine, or food.  As the catastrophe unfolded, several state governments blamed it on aged, supposedly obsolete computer systems written in COBOL, a programming language that originated in the late 1950s. At least a dozen state unemployment systems still run on this sixty-one-year-old language, including ones that help administer funds of a billion dollars or more in California, Colorado, and New Jersey. When the deluge of unemployment claims hit, the havoc it seemed to wreak on COBOL systems was so widespread that many states apparently didn’t have enough programmers to repair the damage; the governor of New Jersey even publicly pleaded for the help of volunteers who knew the language.

Response: But then something strange happened. When scores of COBOL programmers rushed to offer their services, the state governments blaming COBOL didn’t accept the help. In fact, it turned out the states didn’t really need it to begin with. For many reasons, COBOL was an easy scapegoat in this crisis—but in reality what failed wasn’t the technology at all.


Prompt: A “Dead” Language is Born One of the most remarkable things about the unemployment claims malfunction wasn’t that things might suddenly go terribly wrong with COBOL systems, but that they never had before. Many computerized government and business processes around the world still run on and are actively written in COBOL—from the programs that reconcile almost every credit card transaction around the globe to the ones that administer a disability benefits system serving roughly ten million US veterans. The language remains so important that IBM’s latest, fastest “Z” series of mainframes have COBOL support as a key feature.  For six decades, systems written in COBOL have proven highly robust—which is exactly what they were designed to be. COBOL was conceived in 1959, when a computer scientist named Mary Hawes, who worked in the electronics division of the business equipment manufacturer Burroughs, called for a meeting of computer professionals at the University of Pennsylvania. Hawes wanted to bring industry, government, and academic experts together to design a programming language for basic business functions, especially finance and accounting, that was easily adaptable to the needs of different organizations and portable between mainframes manufactured by different computer companies.  The group that Hawes convened evolved into a body called CODASYL, the Conference on Data Systems Languages, which included computer scientists from the major computing hardware manufacturers of the time, as well as the government and the military. CODASYL set out to design a programming language that would be easier to use, easier to read, and easier to maintain than any other programming language then in existence.  The committee’s central insight was to design the language using terms from plain English, in a way that was more self-explanatory than other languages. With COBOL, which stands for “Common Business-Oriented Language,” the goal was to make the code so readable that the program itself would document how it worked, allowing programmers to understand and maintain the code more easily.

Response: COBOL is a “problem-oriented” language, whose structure was designed around the goals of business and administrative users, instead of being maximally flexible for the kind of complex mathematical problems that scientific users would need to solve. The main architect of COBOL, Jean Sammet, then a researcher at Sylvania Electric and later a manager at IBM, wrote, “It was certainly intended (and expected) that the language could be used by novice programmers and read by management.” (Although the pioneering computer scientist Grace Hopper has often been referred to as the “mother of COBOL,” her involvement in developing the specification for the language was minimal; Sammet is the one who really deserves the title.) Other early high-level programming languages, such as FORTRAN, a language for performing complex mathematical functions, used idiosyncratic abbreviations and mathematical symbols that could be difficult to understand if you weren’t a seasoned user of the language. For example, while a FORTRAN program would require programmers to know mathematical formula notation, and write commands like: TOTAL = REAL(NINT(EARN * TAX * 100.0))/100.0 users of COBOL could write the same command as:  MULTIPLY EARNINGS BY TAXRATE GIVING SOCIAL-SECUR ROUNDED.


Prompt: As you can tell from the COBOL version, but probably not from the FORTRAN version, this line of code is a (simplified) example of how both languages could compute a social security payment and round the total to the penny. Because it was designed not just to be written but also to be read, COBOL would make computerized business processes more legible, both for the original programmers and managers and for those who maintained these systems long afterwards.  Image of COBOL tombstone, copyright Mark Richards. Courtesy of the Computer History Museum in Mountain View, CA.

Response: A portable, easier-to-use programming language was a revolutionary idea for its time, and prefigured many of the programming languages that came after. Yet COBOL was almost pronounced dead even before it was born. In 1960, the year that the language’s specification was published, a member of the CODASYL committee named Howard Bromberg commissioned a little “COBOL tombstone” as a practical joke. Bromberg, a manager at the electronics company RCA who had earlier worked with Grace Hopper on her FLOW-MATIC language, was concerned that by the time everybody finally got done designing COBOL, competitors working on proprietary languages would have swept the market, locking users into programming languages that might only run well on one manufacturer’s line of machines.


Prompt: But when COBOL came out in 1960, less than a year after Mary Hawes’s initial call to action, it was by no means dead on arrival. The earliest demonstrations of COBOL showed the language could be universal across hardware. “The significance of this,” Sammet wrote, with characteristic understatement, was that it meant “compatibility could really be achieved.” Suddenly, computer users had a full-featured cross-platform programming language of far greater power than anything that came before. COBOL was a runaway success. By 1970, it was the most widely used programming language in the world.

Response: Scapegoats and Gatekeepers Over the subsequent decades, billions and billions of lines of COBOL code were written, many of which are still running within financial institutions and government agencies today. The language has been continually improved and given new features. And yet, COBOL has been derided by many within the computer science field as a weak or simplistic language. Though couched in technical terms, these criticisms have drawn on a deeper source: the culture and gender dynamics of early computer programming.


Prompt: During the 1960s, as computer programming increasingly came to be regarded as a science, more and more men flooded into what had previously been a field dominated by women. Many of these men fancied themselves to be a cut above the programmers who came before, and they often perceived COBOL as inferior and unattractive, in part because it did not require abstruse knowledge of underlying computer hardware or a computer science qualification. Arguments about which languages and programming techniques were “best” were part of the field’s growing pains as new practitioners tried to prove their worth and professionalize what had been seen until the 1960s as rote, unintellectual, feminized work. Consciously or not, the last thing many male computer scientists entering the field wanted was to make the field easier to enter or code easier to read, which might undermine their claims to professional and “scientific” expertise.  At first, however, the men needed help. Looking back, we see many examples of women teaching men how to program, before women gradually receded from positions of prominence in the field. Juliet Muro Oeffinger, one of about a dozen programmers I interviewed for this piece, began programming in assembly language in 1964 after graduating college with a BA in math. “When COBOL became the next hot thing,” she said, “I learned COBOL and taught it for Honeywell Computer Systems as a Customer Education Rep.” In the images below, Oeffinger teaches a room full of men at the Southern Indiana Gas and Electric Company how to program in the language. Within a short time, these trainees—who had no prior experience with computer work of any kind—would have been programming in COBOL.

Response: Programmer Juliet Muro Oeffinger teaching students Gerald Griepenstroh, Ron Holander, Von Hale, and Ed Tombaugh how to program in COBOL c. 1967. Photos from the personal collection of Juliet Muro Oeffinger. Another retired programmer I spoke to named Pam Foltz noted that good COBOL was great long-term infrastructure, because it was so transparent. Almost anyone with a decent grasp of programming could come into a COBOL system built by someone else decades earlier and understand how the code worked. Foltz had a long career as a programmer for financial institutions, retraining in COBOL soon after getting her BA in American studies from the University of North Carolina at Chapel Hill in the 1960s. Perhaps this dual background is one reason why her code was so readable; as one of her supervisors admiringly told her, “You write COBOL like a novel! Anyone could follow your code.”  Ironically, this accessibility is one of the reasons that COBOL was denigrated. It is not simply that the language is old; so are many infrastructural programming languages. Take the C programming language: it was created in 1972, but as one of the current COBOL programmers I interviewed pointed out, nobody makes fun of it or calls it an “old dead language” the way people do with COBOL. Many interviewees noted that knowing COBOL is in fact a useful present-day skill that’s still taught in many community college computer science courses in the US, and many colleges around the world.  But despite this, there’s a cottage industry devoted to making fun of COBOL precisely for its strengths. COBOL’s qualities of being relatively self-documenting, having a short onboarding period (though a long path to becoming an expert), and having been originally designed by committee for big, unglamorous, infrastructural business systems all count against it. So does the fact that it did not come out of a research-oriented context, like languages such as C, ALGOL, or FORTRAN.


Prompt: In a broader sense, hating COBOL was—and is—part of a struggle between consolidating and protecting computer programmers’ professional prestige on the one hand, and making programming less opaque and more accessible on the other. There’s an old joke among programmers: “If it was hard to write, it should be hard to read.” In other words, if your code is easy to understand, maybe you and your skills aren’t all that unique or valuable. If management thinks the tools you use and the code you write could be easily learned by anyone, you are eminently replaceable.  The fear of this existential threat to computing expertise has become so ingrained in the field that many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers. As one contemporary programmer, who works mainly in C++ and Java at IBM, told me, “Every new programming language that comes out that makes things simpler in some way is usually made fun of by some contingent of existing programmers as making programming too easy—or they say it’s not a ‘real language.’” Because Java, for example, included automatic memory management, it was seen as a less robust language, and the people who programmed in it were sometimes considered inferior programmers. “It's been going on forever,” said this programmer, who has been working in the field for close to thirty years. “It's about gatekeeping, and keeping one’s prestige and importance in the face of technological advancements that make it easier to be replaced by new people with easier to use tools.” Gatekeeping is not only done by people and institutions; it’s written into programming languages themselves.

Response: In a field that has elevated boy geniuses and rockstar coders, obscure hacks and complex black-boxed algorithms, it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use—and which was created by a team that included multiple women in positions of authority—would be held in low esteem. But modern computing has started to become undone, and to undo other parts of our societies, through the field’s high opinion of itself, and through the way that it concentrates power into the hands of programmers who mistake social, political, and economic problems for technical ones, often with disastrous results.


Prompt: The Labor of Care A global pandemic in which more people than ever before are applying for unemployment is a situation that COBOL systems were never designed to handle, because a global catastrophe on this scale was never supposed to happen. And yet, even in the midst of this crisis, COBOL systems didn’t actually break down. Although New Jersey’s governor issued his desperate plea for COBOL programmers, later investigations revealed that it was the website through which people filed claims, written in the comparatively much newer programming language Java, that was responsible for the errors, breakdowns, and slowdowns. The backend system that processed those claims—the one written in COBOL—hadn’t been to blame at all.

Response: So why was COBOL framed as the culprit? It’s a common fiction that computing technologies tend to become obsolete in a matter of years or even months, because this sells more units of consumer electronics. But this has never been true when it comes to large-scale computing infrastructure. This misapprehension, and the language’s history of being disdained by an increasingly toxic programming culture, made COBOL an easy scapegoat. But the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.  That said, even the most robust systems need proper maintenance in order to fix bugs, add features, and interface with new computing technologies. Despite the essential functions they perform, many COBOL systems have not been well cared for. If they had come close to faltering in the current crisis, it wouldn’t have been because of the technology itself. Instead, it would have been due to the austerity logic to which so many state and local governments have succumbed.


Prompt: In order to care for technological infrastructure, we need maintenance engineers, not just systems designers—and that means paying for people, not just for products. COBOL was never meant to cut programmers out of the equation. But as state governments have moved to slash their budgets, they’ve been less and less inclined to pay for the labor needed to maintain critical systems. Many of the people who should have been on payroll to maintain and update the COBOL unemployment systems in states such as New Jersey have instead been laid off due to state budget cuts. As a result, those systems can become fragile, and in a crisis, they’re liable to collapse due to lack of maintenance.  It was this austerity-driven lack of investment in people—rather than the handy fiction, peddled by state governments, that programmers with obsolete skills retired—that removed COBOL programmers years before this recent crisis. The reality is that there are plenty of new COBOL programmers out there who could do the job. In fact, the majority of people in the COBOL programmers’ Facebook group are twenty-five to thirty-five-years-old, and the number of people being trained to program and maintain COBOL systems globally is only growing. Many people who work with COBOL graduated in the 1990s or 2000s and have spent most of their twenty-first century careers maintaining and programming COBOL systems.   If the government programmers who were supposed to be around were still on payroll to maintain unemployment systems, there’s a very good chance that the failure of unemployment insurance systems to meet the life-or-death needs of people across the country wouldn't have happened. It’s likely those programmers would have needed to break out their Java skills to fix the issue, though. Because, despite the age of COBOL systems, when the crisis hit, COBOL trundled along, remarkably stable.

Response: Indeed, present-day tech could use more of the sort of resilience and accessibility that COBOL brought to computing—especially for systems that have broad impacts, will be widely used, and will be long-term infrastructure that needs to be maintained by many hands in the future. In this sense, COBOL and its scapegoating show us an important aspect of high tech that few in Silicon Valley, or in government, seem to understand. Older systems have value, and constantly building new technological systems for short-term profit at the expense of existing infrastructure is not progress. In fact, it is among the most regressive paths a society can take.


Prompt: As we stand in the middle of this pandemic, it is time for us to collectively rethink and recalculate the value that many so-called tech innovations, and innovators, bring to democracy. When these contributions are designed around monetizing flaws or gaps in existing economic, social, or political systems, rather than doing the mundane, plodding work of caring for and fixing the systems we all rely on, we end up with more problems than solutions, more scapegoats instead of insights into where we truly went wrong.

Response: There are analogies between the failure of state unemployment systems  and the failure of all sorts of public infrastructure: Hurricane Sandy hit the New York City subway system so hard because it, too, had been weakened by decades of disinvestment. Hurricane Katrina destroyed Black lives and neighborhoods in New Orleans because the levee maintenance work that was the responsibility of the federal government was far past due, a result of racist resource allocation. COVID-19 continues to ravage the United States more than any other nation because the federal infrastructure needed to confront public health crises has been hollowed for decades, and held in particular contempt by an Administration that puts profits over people, and cares little, if at all, about the predominantly Black and Latinx people in the US who are disproportionately dying.  If we want to care for people in a pandemic, we also have to be willing to pay for the labor of care. This means the nurses and doctors who treat COVID patients; the students and teachers who require smaller, online classes to return to school; and the grocery workers who risk their lives every day. It also means making long-term investments in the engineers who care for the digital infrastructures that care for us in a crisis.


Prompt: When systems are built to last for decades, we often don’t see the disaster unfolding until the people who cared for those systems have been gone for quite some time. The blessing and the curse of good infrastructure is that when it works, it is invisible: which means that too often, we don’t devote much care to it until it collapses.

Response: Cubicles as far as the eye can see, each one containing a government worker clacking keys in front of an ancient, humming green screen. On the other side of those screens are millions of people trying to file for unemployment, apply for food stamps, or access any other number of government services. The website keeps crashing when they try to submit their online form, or they wait in line for hours only to reach the end and find that the piece of mail they brought to verify their identity is invalid. Try again tomorrow.


Prompt: This is a familiar trope about dysfunctional government, one that emerged to serve the political goals of the right during the crisis that was, in the words of Ruth Wilson Gilmore, “the close of the golden age of US capitalism.” The stereotype—mindlessly bureaucratic, hopelessly outdated—was used to justify attacks on organized labor, tax cuts for capital, and the hollowing out of what little safety net the US established after the Great Depression and World War II. Historian Mar Hicks writes in their piece for this series that the implications of that hollowing out for government technology were that “as state governments have moved to slash their budgets, they’ve been less and less inclined to pay for the labor needed to maintain critical systems.” We asked a few of the people who were tasked with making those systems work anyway about their decades-long careers in government technology.

Response: Beginning in the mid-1980s, Jed Wagner began architecting the federal system that handles veterans’ benefits appeals—a system that he alone was responsible for for three decades. Around the same time, Mike Schwab was a unionized employee of Illinois’ Central Management Services, developing and maintaining mainframe applications that other state agencies used in their day-to-day work. A few decades later, Adam Grandt-Nesher was typing Hebrew blindly into dumb terminals, the start of a winding career through taming legacy systems across private and public sectors that landed him in the middle of mainframe modernization efforts for the US federal government today. We sat down with the three of them to get a kaleidoscopic picture of how the government technology systems we have today came to be, and what they will look like in the future.


Prompt: The interviews included in this series were edited by Jen Kagan, and conducted by Christa Hartsock and Julie Sutherland, who work together at Code for America, a technology nonprofit that works with governments to better deliver services like SNAP, Medicaid, and criminal record clearance. Christa is a software engineer and Julie is a designer and qualitative researcher. The interview team would like to thank Mike Schwab, Adam Grandt-Nesher, Jed Wagner, Marianne Bellotti, Philip Young, Teresa Curtis, Jason Anton, Joe Klemmer, Mike Cowden, John O’Duinn, Genevieve Gaudet, Zoe Blumenfeld, Jen Pahlka, and the many others who fielded questions, chased mainframe leads, and shaped the series.

Response: The story does not stop here—we would like to continue chronicling stories from mainframe developers and need your help. If you have an experience to share, please reach out at mainframes@logicmag.io. The series: Built to Last, by Mar Hicks Mike Schwab on Mainframe Programming for the State of Illinois Adam Grandt-Nesher on Modernizing Infrastructure Jed Wagner on Being the Sole Maintainer of the Veterans Appeals System Tell us a bit about your work.


Prompt: For twenty-six years, I was with Central Management Services (CMS) for the State of Illinois. CMS is like a super agency that provides services to other state agencies. They run the payroll system and do the health insurance and other benefits for most everybody that’s employed by the state, including universities. There are some large agencies that do their own payroll.  I used to work on the application side developing for mainframes before I moved over to storage. On the storage side, I worked with state agencies to make sure they had enough space on the mainframe to hold their files.  What did the storage side entail? We managed equipment for state agencies and billed for CPU, disk space, and all that. If equipment was shared among a few of our agencies, we only billed each agency for what they were actually using. But there were some storage areas that were limited to one agency—since they were the only ones that used it, they got billed for all the storage, whether or not it was being used.

Response: We set a notification level of 10 percent. So if you had less than 10 percent storage capacity remaining, you got notified to add more. But, you know, the agencies didn’t want to pay for another storage volume. We’d call them up and tell them they needed more, but they’d say, “Let it drop to 9 percent, 8 percent,  7 percent—we’re still working!—5 percent! Four percent!” Eventually, they’d say ”We’re not working any more. We need more space.” Why do you think they cut it so close?  They didn’t want to pay for it. If we added a volume, which was eight gigabytes, they’d have to pay for that space even if they didn’t actually need it for a file. They didn’t want to drive up the computer budgets.  But when you’re operating like that, any tiny little bump can stop your work from happening. And it did from time to time. One time, this agency had a log get up to the maximum number of extents. The log itself wasn’t too big; it was just using too many little chunks of memory. They called me and said, “We can’t do this transaction!” Everything came to a screeching halt and their system shut down until they had defragmented that log so that they could gather more space for it.  That sounds like what’s happening to these government systems that are crashing as millions of people file unemployment claims. What’s your perspective on all the recent news about that, and particularly the criticisms of COBOL? Do you feel the criticisms are warranted?  Totally unwarranted. COBOL is the backbone behind the businesses on the web. Your credit cards would not work without COBOL. American Express, Visa, MasterCard—they’re all running COBOL. Airline tickets? The backbone behind that is all on mainframes. The airline industry developed software in the 50s on specifically designed computers. The software they run on mainframes today is directly descended from COBOL code they wrote for the IBM 360, which came out in the mid-1960s.  COBOL was designed for accounting. It’s designed to be exact to the penny. The IBM 360 came out with instructions that fit into that kind of paradigm. When you go to any other language, they don’t often have decimal math instructions for that kind of accounting work. So any time you port COBOL over to another language, you can get your basic logic over and then you’ve got to test your accounting and make sure you come up to the penny again. There are often rounding errors that creep in after a while: you start losing your least significant digits and, eventually, you’re no longer accurate to the penny. That does not happen with mainframes running COBOL.


Prompt: COBOL’s strengths aside, these systems are struggling. Do you have any thoughts based on your experience about why they’re struggling? None of the other recessions we’ve had since 1918 have come all at once like this. You start to have a recession and your unemployment systems are handling 0.1 percent more, 0.2 percent more. Your systems have time to grow and scale. You’ve got more workload handling the new people coming in while paying everybody else out from their last week’s records.  Today, you’ve got 10 percent of the US population laid off and filing for unemployment within months. That’s one hundred times your normal recession workload. The employees who process those claims are completely overwhelmed. The CPU processing speed is overwhelmed. Your disk storage for all these new people is completely overwhelmed. If you’re going to 15 percent unemployment and you were at 5 percent, you need three times as much storage space. And the people who work in the unemployment office are trying to handle fifty to a hundred times their normal workload. You can’t just enter your information and automatically get unemployment. A person has to sit there and approve or disapprove every request.  Yeah, we work a lot with government caseworkers and there’s always a human that has to do some sort of thing on the other side of the screen. When I talk with friends who work at Facebook or wherever, they think it’s this perfectly oiled mechanical system. But there are humans all over it, and they do really complex things. And humans are hard to scale.

Response: That’s right. At CMS, we worked with the agency in charge of unemployment. The only person we ever saw from that office was a shop steward who would come down for meetings. She had a guy transfer from the Department of Corrections who had trained to work on the unemployment system. Of course, it had lots of complex rules and you have to have them all memorized. It takes weeks, if not months of training to learn all the rules you have to follow before you can say yes or no. So this guy spent months in training, but in the end, he found it so stressful to be handling the unemployment claims that he went back to corrections.  How do you actually sustain that when the software is so complicated? And we’ve seen several times in our government work that one or two people maintain ten systems. What happens when they leave? The complexity of these systems is a big issue. On the technical side, if there’s only one person who knows a system and that last person goes to retire, there’s nobody left to train new people on the software. And the mainframe software is so much more complex to use. With Linux or Windows applications, you get trained up in a week. But for mainframe applications, every installation is custom. There are tricks of the trade that new hires have to learn by osmosis, by working with the prior person. A new guy comes in, you tell him what to do, and you sit there and hold his hand while he goes through and does it. And you are still learning new tricks even after a couple of years.