The paper behind the program: a documentary history of FORTRAN Open Access

In this paper, we explore the role of documentation in the development and stabilization of a sociotechnical system, focusing on the early history of the FORTRAN (FORmula TRANslation) programming language ^[1]. This study takes the form of a historical case study, using the development of FORTRAN to examine how documents shape and are shaped by the development of a sociotechnical system. International Business Machines (IBM) began developing FORTRAN in 1954. The language made programming faster, easier, and less error-prone than writing directly in assembly language or machine code. In 1966, the American Standards Association formally standardized FORTRAN. During this period, FORTRAN became the first high-level programming language to achieve widespread adoption (Ceruzzi, 2003; Mahoney, 2011) ^[2]. Although this case study focuses on FORTRAN, its insights are intended to inform document theory more broadly, emphasizing the associativity of multiple documents within and beyond the domains of science and technology.

Since the release of FORTRAN nearly seventy years ago, it has remained a foundational component of high-performance computing infrastructure in science and engineering (Curcic, 2020; Kedward et al., 2022). Its continued relevance is evident in its consistent ranking among the top programming languages in the TIOBE index ^[3]. The continued use of FORTRAN underscores the importance of understanding how technical systems are constructed and maintained over time.

The central claim of this paper is that the emergence of FORTRAN as a sociotechnical system – a configuration of people, practices, and technologies – was shaped by the coordinated influence of documentation. Documentation refers to the range of textual artifacts, such as manuals, reports, standards, and textbooks, that were created to explain, justify, teach, and regulate the use of FORTRAN. Rather than focusing on any single document, this paper emphasizes how multiple forms of documentation worked together to support the language's development and adoption. This perspective is captured in the concept of collective documentality, defined here as the capacity of a group of related documents to influence technical and social outcomes through their combined effects.

To explore this claim, this paper draws on documentality, which examines how documents acquire meaning and exert influence within specific contexts, and actor-network theory, which conceptualizes agency as emerging from networks of human and non-human actors. Together, these frameworks support an analysis of how documentation contributed to the formation of FORTRAN as both a technical and a social system.

Two research objectives guide this study:

This paper continues by reviewing relevant literature and outlining the theoretical framework. This is followed by a discussion of the methodological approach. The case study is then presented, followed by a discussion of the findings. The paper concludes by reflecting on the broader implications of documentation in the construction of sociotechnical systems.

This section reviews relevant scholarship on documentation practices in engineering and software development, and follows with a discussion of two theoretical frameworks, documentality and actor-network theory, that inform the present study.

There is a substantial body of research on the document practices of engineers, which refers to how individuals engage with documents in their work, including the processes of creating them, searching for them, interpreting their content, and applying them in specific contexts (see Tenopir and King, 2004). This literature has characterized engineers as technically skilled professionals that are engaged in the design, building, and maintenance of complex systems, with an emphasis on creating solutions to real-world challenges (Hertzum and Pejtersen, 2000; Leckie et al., 1996). While the literature often treats engineering as a single professional domain with shared methods and epistemologies, this framing can overlook important differences among its subfields. Software development shares core features with other engineering disciplines, including problem-solving under constraints, the integration of diverse forms of knowledge, and the pursuit of functional design (cf. Bucciarelli, 1994; Ferguson, 1994; Vincenti, 1990). At the same time, software engineering differs in both the nature of what is designed and the methods by which that design is realized. Whereas most engineering fields focus on tangible, three-dimensional artifacts, from bridges in civil engineering to circuits in electrical engineering, software engineering is oriented toward the construction of abstract, symbolic systems composed of code. These systems are less physically manifest but no less complex. Importantly, software engineering also involves its own distinctive practices, including specialized ways of interacting with documentation. As such, software engineering warrants focused study as a distinct domain within engineering.

The literature has identified the types of documentation that software engineers interact with. In a study of IBM software engineers, Freund et al. (2006) identified sixteen distinct document genres, including manuals, presentations, and product documents. These genres supported a range of development activities, from debugging and implementation to communication and planning. Earle et al. (2015) similarly found that developers regularly consult a wide variety of documentation types, including how-to articles, product help, and technical notes. While usage frequency varied, most document types were accessed at least monthly, indicating the use of a broad range of types of documentation.

To conceptualize this diversity, Orlikowski and Yates (1994) introduced the notion of genre repertoires – recurring sets of document types that support collaborative work. In their study of Common LISP developers, they identified memos, proposals, dialogues, and voting messages as genres that collectively enabled the co-authorship of a programming manual. These genres were not isolated but functioned as part of a dynamic system that evolved in response to organizational needs.

Building on this systems-oriented view, Spinuzzi and Zachry (2000) have advanced an ecological approach to genre, emphasizing how documentation practices are embedded in social and material contexts. In this framework, they also distinguish between official and unofficial genres. Official genres refer to documents that are formally sanctioned and produced according to institutional standards. These genres, such as manuals, policies, and technical specifications, are typically designed to regulate, formalize, or coordinate work. In contrast, unofficial genres are informally created, locally adapted documents – such as handwritten notes, workaround instructions, or annotated printouts – that emerge from everyday practice. While official documentation tends to be top-down and prescriptive, unofficial documentation is more bottom-up and responsive, reflecting users' efforts to address immediate needs and context-specific challenges. Both types are essential to understanding how documentation operates in practice.

A historical study of a manufacturing firm's adoption of mainframe computing in the 1950s and 1960s illustrates this point. Drawing on archival work, Zachry (1999) examined how the uptake of new computing technologies was mediated through the company's existing documentation practices. Employees adapted familiar genres, such as checklists, administrative memos, and procedural documents, to support their use of the new systems. Zachry also found that unofficial documentation emerged across different teams, reflecting local adaptations and divergent understandings of how systems should be used. Even when the company attempted to formalize its document practices through official manuals, employees continued to produce and rely on ad hoc materials. Zachry concluded that official and unofficial documentation coexisted and interacted, shaping how new technologies were understood and used. This finding is supported by research on contemporary software development, which similarly highlights how engineers interact with official and unofficial documentation (Spinuzzi, 2003).

Subsequent research has further emphasized the contextual nature of documentation practices. Freund (2015), based on interviews with software engineers, proposed a model of four contextual spheres – person, project, work task, and information task. This model demonstrated how information needs shift depending on the nature of the task (e.g. implementation, performance tuning, etc.) and the phase of the project. Forward and Lethbridge (2002) similarly found that developers consult different types of documentation at different stages of a project. Early phases involve design specifications and architectural overviews, while later stages rely more on implementation notes, bug reports, and performance data. Orlikowski and Yates (1994) emphasize that documentation plays a key role in organizing collaborative work. It helps define responsibilities, structure workflows, and formalize decisions. This reflects how documentation supports not only individual tasks but also broader coordination across projects.

Developers' selection of documentation is shaped by several other factors, including perceived currency, relevance, availability, clarity, and the presence of examples (Forward and Lethbridge, 2002; Hertzum, 2002). Fidel and Green (2004) found that developers often prioritize sources that are familiar and time-efficient, even if they lack formal authority. Scholars studying engineers more broadly have suggested that this behavior may be explained by Zipf's principle of least effort, which argues that individuals tend to minimize the effort required to obtain information, even at the expense of completeness or accuracy (Allard et al., 2009; Anderson et al., 2001; Tenopir and King, 2004; Zipf, 1949). According to this principle, users are more likely to consult sources that are easily accessible, quickly understood, or previously used, rather than those that are more comprehensive but harder to navigate. Yitzhaki and Hammershlag (2004) similarly reported that software engineers rely more on textbooks and trade publications than on academic literature, reflecting a preference for practical utility.

Interpersonal communication is also a critical source of information for software engineers. Informal discussions with colleagues are often the most frequently used and accessible resource (Yitzhaki and Hammershlag, 2004). While documents provide technical detail, colleagues offer contextual understanding, particularly when navigating complex or unfamiliar problems (Hertzum and Pejtersen, 2000). This interplay between formal documentation and informal knowledge exchange highlights the multifaceted nature of information practices in software development.

The literature on software engineering has explained the diversity and contextual nature of documentation practices. The following subsections introduce two complementary perspectives – documentality and actor-network theory – that conceptualize documents as active agents within networks of practice.

Documentality refers to the capacity of documents to exert agency, which is their ability to shape actions, meanings, and relationships within specific social contexts. Documentality emphasizes that documents are not passive containers of information but active participants in life (Buckland, 1997; Day, 2000; Frohmann, 2007, 2013). Documentality focuses on how documents enable communication, coordinate activity, and support collaboration. Frohmann (2004) identifies four dimensions that help explain how documents exert agency: their material characteristics, their embeddedness in institutional routines, the disciplinary norms that govern their use, and their historical contingency. Documentality draws attention to the ways documents contribute to the formation of sociotechnical arrangements by doing work in the world.

Buckland (2014) illustrates this point through the example of a passport. A passport functions as proof of identity and citizenship, enabling or restricting mobility across national borders. Although a person may have the legal right to enter a country, that right is difficult to exercise without the document that activates it. The passport's agency lies not in its content alone but in its entanglement with a broader network of actors and systems, including border agents, biometric technologies, legal frameworks, and international agreements. Its influence emerges from its role within this network, where it mediates access, enforces rules, and coordinates interactions.

Buckland's example of the passport demonstrates how a single document can exert agency; however, his analysis remains centered on one document. In practice, international travel depends on a set of interrelated documents, such as visas and customs forms, that function together. To account for this complexity, it is necessary to move beyond single-document analyses. This study introduces the concept of collective documentality, which refers to the capacity of multiple documents, working in concert, to produce effects that no individual document could achieve alone.

Focusing on collective documentality raises several questions. First, what kinds of documents typically comprise the documentation that supports the development of a system, and how are these documents produced and circulated? Second, how do documents exert agency both individually and collectively, and how do their interactions shape the formation of technical practices and social arrangements? Third, how does documentation contribute not only to the initial creation of a system but also to its ongoing maintenance, adaptation, and stability over time?

The concept of document agency is closely informed by insights from actor-network theory (ANT). Frohmann's work on documentality draws directly on ANT's attention to how agency emerges through associations among people, technologies, and practices. Rather than treating documents as isolated artifacts, both ANT and documentality emphasize the relational conditions under which documents act and acquire meaning.

ANT offers a vocabulary for tracing how documents participate in the formation of sociotechnical systems. It approaches agency not as a fixed property of human or nonhuman actors, but as something that arises through networks of interaction (Callon, 1984; Latour, 1987; Law, 1992). Within this view, documents are understood as actors whose influence depends on their ability to circulate, be interpreted, and coordinate action across different settings.

One way ANT conceptualizes document agency is through the notion of inscription. Inscriptions are representations that can move across time and space while maintaining a stable form. Latour (1990) describes them as immutable mobiles, meaning they are both durable and portable. These qualities allow documents to move while retaining their meaning. As they circulate, documents make it possible for actors to communicate with one another, to coordinate their activities, and to collaborate toward negotiated or shared objectives. In this capacity, documents help enroll actors into a network. To enroll an actor means to bring a human or nonhuman actor into provisional alignment with the goals, practices, or expectations of the network. This alignment is rarely complete or uncontested; it is negotiated and often reflects competing interests or partial agreements (Callon, 1986; Latour, 1987, 1991). At the same time, documents mediate the relationships among these actors. Mediation refers to the way documents shape how actors interact, define their roles, and organize their contributions. These associations are not fixed. As documents circulate, actors may enroll or withdraw, causing the network to change as the associations between actors are strengthened, reconfigured, or weakened (Latour, 1990; Latour and Woolgar, 1979; Law, 1986).

ANT also draws attention to the process of black boxing, in which knowledge claims become accepted as stable and self-evident (Latour, 1987). In scientific contexts, this process often begins in the laboratory, where researchers produce inscriptions, such as graphs, tables, or experimental results, that are eventually formalized into a scientific article. Once published, the article circulates the broader network of literature, where it may either gain authority or be challenged. If the article's claims are incorporated into subsequent research, it may become “black boxed.” That is, the underlying assumptions, methods, and negotiations that produced the findings are no longer visible or subject to scrutiny. The article is treated not as a situated claim but as a stable fact. When a black box is reopened – due to failed replication, new evidence, or shifts in disciplinary consensus – its claims are once again subject to negotiation, and its role in the network may change (Latour, 1987, 1999).

Together, documentality and ANT offer a conceptual foundation for analyzing how documents acquire and exercise agency. They also encourage the analyst to examine the kinds of work performed by the broader network of documents and associated actors. This includes investigating how documents enroll participants, mediate relationships, and coordinate negotiated activities and goals within sociotechnical systems. While much prior research has focused on the agency of individual documents, there is considerable room to explore how multiple documents function together. A promising direction for document studies lies in analyzing the collective labor of interconnected documents.

The reviewed literature and theoretical frameworks underscore the centrality of documentation in both the everyday work of software development and the historical and infrastructural processes that sustain technical systems. By combining empirical and conceptual insights that foreground the agency of documents, this study is positioned to analyze how documentation shaped the development and adoption of FORTRAN. The next section outlines the methodological approach used to investigate this historical case study.

As part of a historical case study, this study used a diachronic genre analysis to examine the development of documentation related to the FORTRAN programming language. A diachronic approach focuses on how types of documents emerge and evolve over time (Tardy and Swales, 2014). While such analyses often trace the transformation of a single genre across historical periods, this study adopts a broader perspective. Rather than following a single genre, it explores how FORTRAN documentation expanded and diversified, with new genres introduced and layered onto existing ones. This approach enables an understanding of how documentation practices matured in tandem with the programming language itself.

In this study, a genre is defined as a recurring form of documentation that serves a specific communicative purpose, follows recognizable structural and rhetorical conventions (form), conveys particular types of information (content), and is oriented toward a defined audience or use context (function). The analysis aimed to identify the earliest known instances of such genres within the FORTRAN documentation corpus and to examine their role(s) in supporting the language's development, dissemination, and standardization.

The analysis focused on documents produced between 1953, when FORTRAN was first proposed, and 1966, when it was formally standardized. Only text-based materials were included in the analysis. Other media formats, such as advertisements or instructional films, were excluded even though they were produced during the same period.

Documents were located through searches in several archival and bibliographic sources. These included the catalog of the Computer History Museum, the digital libraries of the Association for Computing Machinery and the Institute of Electrical and Electronics Engineers, and the United States copyright registry. Secondary sources were also consulted, including historical accounts of IBM and FORTRAN. Among these, Lee (1984a) was especially useful for identifying early documentation. First-hand accounts, such as (Backus, 1978), provided additional context. Our previous training in computer science and technical communication also informed the interpretation of these materials, particularly in identifying technical references and understanding their relevance within the development process.

Through this process, the study identified the following genres as appearing for the first time in the FORTRAN documentation during the period under review (1953–1966):

1. Proposal;

2. Technical report (IBM, 1954);

3. Manual (IBM, 1956);

4. Scholarly article (Backus et al., 1957);

5. Primer (IBM, 1957);

6. Textbook (McCracken, 1961); and

7. Standard (American Standards Association, 1966).

Our analysis focused on the first appearance of each genre in order to map the breadth of the genre set and better understand how each genre initially emerged in response to specific exigencies. This approach emphasizes the diversity of document types rather than the longitudinal development of any single genre. We recognize that individual genres, such as manuals, changed in content, form, and function over time. Although this study does not track those changes, we see this as a promising direction for future research. A comparative analysis of a single genre across time would shift analytical attention away from the multiplicity of document types and toward the internal development of one genre, which is not the focus of this paper. Focusing on the initial emergence and variety of genres aligns more closely with the research questions guiding this case study.

Each document was analyzed using a coding framework based on the three core elements of genre: form, content, and function. These elements served as deductive codes to guide the analysis. Form refers to the document's structural and visual presentation; content refers to the information conveyed; and function refers to the document's intended use and audience, as inferred from the text itself or from related contextual sources.

Both authors participated in the analysis and independently applied the coding framework to all documents. Coding agreement was reached through collaborative discussion, with discrepancies resolved through iterative conversation and reference to the original materials.

In addition to analyzing the documents themselves, this study examined user accounts, retrospective narratives, and historical analyses that described how these materials were created, distributed, and used. These supplementary sources provided insight into the practical roles that documentation played in the institutionalization of FORTRAN. Most primary materials were accessed in digital format from publicly available repositories, including bitsavers.org, the Computer History Museum, and the Internet Archive.

In late 1953, John Backus submitted a proposal, now lost, to Cuthbert Hurd, his manager at IBM, proposing the development of a new programming language. The goal was to create a faster and more accessible alternative to assembly language for writing software (Backus, 1978). In the proposal, Backus argued that such a language could reduce the cost of software development and make IBM computers more appealing to customers. The proposed language, later named FORTRAN, would allow programmers to write code using mathematical expressions and human-readable terms rather than hardware-specific instructions. Hurd approved the proposal, and a team was formed to begin work in early 1954.

The team's first output was a technical report published by IBM in 1954. According to Lee (1984a, p. 49), this was “the first formal proposal for the language FORTRAN. It lists the elements of the language that are proposed to be included in the eventual implementation, together with some suggestions for future extensions.” The report itself emphasized its provisional status, stating that it “is intended only to indicate present plans” (IBM, 1954, p. 3). As Lorenzo (2019, p. 87) observes, “some of the ideas the team describes [in the report] hadn't been implemented on a live machine … So, unsurprisingly, a mix of quasi-mathematical notation and unformed pseudocode litters the thirty-page Report.” This provisional quality is not surprising considering the broader historical context that programming languages and operating systems were still emerging as conceptual and technical categories (Allen, 1981; Bullynck, 2019; Nofre et al., 2014). The team was designing a system that had few precedents and uncertain prospects. In this sense, the report reflects not only the speculative nature of the project but also the experimental conditions of early computing, in which both the tools and the language to describe them were still being invented. Many users of the IBM 704, the computer for which FORTRAN was being developed, remained skeptical that such a language could match the performance of assembly code (Pugh, 1995, pp. 194–195). Nonetheless, the team continued its work.

The next phase involved building the first FORTRAN compiler, a program that would translate FORTRAN code into machine-executable instructions. By 1956, the compiler was nearing completion. To support programmers, IBM published the Programmer's Reference Manual (IBM, 1956). The manual stated that its purpose was to “permit planning and FORTRAN coding” (p. 1). It included syntax descriptions, examples, and reference tables. For example, it explained that the statement “GO TO 3” transfers control to the statement with number three. Bright (1984, p. 29) described the manual as a “fat brochure that in retrospect was incredibly accurate in comparison with typical modern documentation.” Knuth (2003, p. 69) referred to it as “another ‘first’ in the history of programming languages, namely, the first language description that was carefully written and beautifully typeset, neatly bound with a glossy cover.” Bashe et al. (1986, p. 356) noted that it was “much admired at the time and after for its conciseness and clarity.”

In the same year, Backus and his team presented a scholarly article at the Western Joint Computer Conference, later published in the proceedings (Backus et al., 1957). According to Lee (1984a, p. 50), the article included “an overview of [FORTRAN], a description of each stage of the [compiler's] processor … And conclusions regarding the success of the project.” The article helped generate interest in compiler design among researchers and practitioners.

As FORTRAN's popularity grew, IBM allowed other companies to develop their own compilers. The reasons for this decision are not fully clear, but several explanations have been proposed. According to Bashe et al. (1986), IBM's actions may have been influenced by a 1956 antitrust settlement with the United States Department of Justice, which encouraged the company to avoid further regulatory scrutiny (p. 357). Others, including Campbell-Kelly and Garcia-Swartz (2009) and Lorenzo (2019), argue that IBM had little interest in patenting its software. Instead, the company recognized that releasing technical descriptions and software specifications into the public domain stimulated demand for its hardware. Regardless of the underlying rationale, this strategy ultimately facilitated the uptake of FORTRAN and reinforced IBM's position in the computing market.

As more systems adopted FORTRAN, IBM produced additional documentation for less experienced users. The Programmer's Primer (IBM, 1957) stated that its function “is to introduce the reader to the FORTRAN language” (p. 1). The primer was intended as an instructional guide rather than a technical reference. Lorenzo (2019, p. 150) described it as “a much more detailed Manual stocked full of example programs.” Backus (1978) later noted that the primer played an important role in expanding the use of FORTRAN, especially since no textbooks on the language had yet been published.

The first textbook was published in 1961. McCracken's A Guide to FORTRAN Programming was “written for the person who wants to get a rapid grasp of the use of a computer in the solution of problems in science and engineering” (McCracken, 1961, p. 5). It included nine chapters and two appendices that “investigate each of the FORTRAN statements” and “determine how to go about combining them to solve representative problems in science and engineering” (p. 4). The textbook also included practice problems and answers to selected exercises. It was widely adopted in university courses and for self-study. Over time, it became one of the most widely used programming textbooks of its era (Campbell-Kelly, August 29, 2011; McDowell, May 6, 1983).

By the early 1960s, FORTRAN had become the first widely adopted high-level programming language, with growing use across universities, government laboratories, and industrial research centers (Pugh, 1995). This expansion brought new participants into the FORTRAN network, each with distinct needs and expectations. In academic settings where instructors processed large volumes of student programs, compiler performance was often evaluated in terms of throughput (see Campbell, 2012). Compilers were optimized to handle many short programs efficiently. In contrast, industrial and research environments prioritized the reliable execution of fewer, longer-running programs. In these contexts, system stability was critical, as a crash could require a full recompilation and rerun, resulting in delays and increased costs.

These divergent requirements led to the development of specialized compilers, each adapted to the needs of its user community (cf. Lee, 1984b). Over time, these adaptations produced a growing number of FORTRAN “dialects.” Lorenzo (2019, p. 192) refers to this situation as “a FORTRAN Tower of Babel,” highlighting the difficulty of maintaining compatibility across systems. Even IBM contributed to this fragmentation. After the release of FORTRAN I in 1957, IBM introduced FORTRAN II in 1958 and FORTRAN IV in 1961 ^[4]. Each version had multiple implementations, and the diversity of computer architectures further complicated matters. As Pugh et al. (1991, pp. 39–40) explain, “By 1960, IBM was making six kinds of solid-state computers, none of which could interchange programs. … The systems were incompatible at several levels: instruction set, programming language, and operating system conventions.” This meant that software written for one IBM computer would not run on another. As Blatt (1960, p. 502) observed, “Re-writing an entire major program for a new machine is almost as big a job as writing the original program. The re-writing job is usually not even attempted.”

In response to these challenges, efforts to standardize the language began. In 1962, the American Standards Association formed a committee composed of representatives from computer manufacturers, user groups, universities, and software companies. The committee's goal was to define a common version of FORTRAN that could be implemented across systems. The resulting standard, published in 1966, was the first official programming language standard (Metcalf, 2011).

The standard was “intended as a guide to aid the manufacturer, the consumer, and the general public” (American Standards Association, 1966, p. 2). It was especially directed at those implementing FORTRAN compilers (Heising, 1964). The standard stated: “This standard establishes the form for and the interpretation of programs expressed in the FORTRAN language for the purpose of promoting a high degree of interchangeability of such programs for use on a variety of automatic data processing systems. A processor shall conform to this standard provided it accepts, and interprets as specified, at least those forms and relationships described herein” (American Standards Association, 1966, p. 7).

The standard did not eliminate variation but instead established a shared foundation. As Metcalf and Reid (1991, p. 18) explain, “Essentially, it was a common subset of the dialects, so that each dialect could be regarded as an extension of the standard. Users wishing to write portable code had to be careful to avoid extensions.” In this way, the standard functioned as a negotiated compromise, balancing the need for consistency with the realities of diverse implementations.

The publication of the 1966 standard marked a turning point not only in the technical consolidation of FORTRAN but also in its elevation as the common language of scientific and engineering computing. As Metcalf (2011, p. 2) observed, the standard “was made available on almost every computer made at that time,” reflecting its widespread uptake. Greenfield (1984) similarly noted that “standardization provided a stamp of approval and a level of acceptance and stability. … All systems large enough to support a FORTRAN system were expected to have one. FORTRAN had graduated from being an important higher-level language to being a common programming language” (p. 33). These developments signaled not just technical compatibility but cultural legitimacy. As Pugh (1995, p. 195) summarized, “Thus FORTRAN became the common computer language by which scientists and engineers shared programs and computational processes. So pervasive was the use of the language that most college courses on computing during the 1960s caused students to believe that learning FORTRAN was synonymous with learning to program computers.”

This case study has traced the first thirteen years of FORTRAN's development by examining the creation, circulation, and use of key forms of documentation. In addressing the first research objective (RO1) – identify the types of documentation created during FORTRAN's initial development and adoption – this study traced the emergence of seven distinct genres that contributed to the formation of the FORTRAN sociotechnical system: the proposal, technical report, manual, scholarly article, primer, textbook, and standard. Each genre appeared in response to specific technical, organizational, or pedagogical needs and played a distinct role in supporting the language's development, dissemination, and stabilization:

1. The proposal initiated the project by articulating a rationale for a high-level language and securing institutional support.

2. The technical report translated this vision into a preliminary design, serving as a working specification for the development team.

3. The manual provided a technical reference for experienced users, detailing the language's syntax and semantics.

4. The scholarly article presented the language and its compiler to the research community, helping to establish its legitimacy.

5. The primer introduced the language to novice users through annotated examples and instructional guidance.

6. The textbook extended this instructional function, offering a comprehensive pedagogical resource for students and self-learners.

7. The standard responded to the proliferation of dialects by defining a common version of the language, promoting interoperability and stability.

Together, these documents contributed to the construction of FORTRAN as a sociotechnical system. The following section considers how these findings inform our understanding of documentation's role in shaping technical systems, with particular attention to the concept of collective documentality.

The development of FORTRAN was not only a technical achievement but also a documentary one. The language emerged within a sociotechnical system in which documents played a central role. These documents did not merely record progress; they actively shaped how the system functioned, expanded, and stabilized over time.

To address the second research objective (RO2) – analyze the influence of documentation on the development and adoption of FORTRAN – this section applies a heuristic proposed by Latour (1992), which assesses agency by considering the amount of work that would be required in the absence of a given entity.

Each genre of documentation performed specific types of work. Their absence would have necessitated compensatory labor. Without the technical report, the design and implementation of the compiler would have depended on informal communication among team members, increasing the likelihood of misalignment or delay. Without the manual, primer, and textbook, the burden of instruction would have shifted entirely to interpersonal transmission, limiting the scalability of training and slowing adoption. The scholarly article played a distinct role by legitimizing FORTRAN within research communities, presenting it as both a technical innovation and a subject of theoretical interest.

These examples illustrate that documents exercised agency; however, their influence was not isolated. Rather, documents operated in association with one another, participating in the network of FORTRAN documentation. Within this network, documents were produced, circulated, and interpreted in relation to each other. This shared context gave rise to two key dynamics: intertextuality and negotiation. These are not intrinsic properties of individual documents but emerge from their mutual association within the documentation network.

Intertextuality refers to the ways in which documents referenced, extended, and recontextualized one another. For example, the technical report built upon the initial proposal and informed the structure of the manual. The primer and textbook adapted the manual's content for different audiences. These intertextual relationships were made possible by the documents' co-presence in the network, where they were read, interpreted, and used in relation to one another.

Negotiation similarly arose from the dynamic interactions among documents and the actors who produced and used them. As documents circulated, they reflected and responded to technological developments. The standard provides a clear example of this process. It was developed in response to the increasing diversity of FORTRAN dialects and the need for a common version. Rather than enforcing uniformity, the standard mediated between competing pressures. On one side were efforts to promote convergence around a shared foundation, and on the other were demands for local adaptation and innovation. The standard aimed to promote a high degree of interchangeability, while still permitting extensions beyond the defined subset. This flexibility allowed vendors to innovate while maintaining a degree of compatibility. The standard functioned as a negotiated foundation that structured the possibilities for how FORTRAN could evolve. Its influence was shaped by its position within a broader documentary network that included manuals, textbooks, and articles. These documents were both shaped by the standard and contributed to its uptake and interpretation.

The intertextual and negotiated relationships described above underscore a broader point that documents within the FORTRAN system did not act in isolation but instead in association. This perspective is captured in the concept of collective documentality, defined in this paper as the capacity of multiple, interrelated documents to influence technical and social outcomes through their combined presence and interaction. This concept shifts the analytical focus from isolated texts to the patterns of agency that emerge when documents operate in concert. At least three such patterns are evident in the case study: recruitment, control, and articulation.

Recruitment refers to the role of documentation in enrolling new actors into the FORTRAN network. Individual documents targeted specific audiences. The manual supported experienced programmers; the primer and textbook introduced the language to students and newcomers; and the scholarly article engaged researchers. Together, these documents enabled a wide range of people to write FORTRAN code.

The process of recruitment also illustrates how users of FORTRAN moved between the roles of information consumers and producers. Heising, reflecting on his tenure at IBM during the transition from FORTRAN II to FORTRAN IV, described how user engagement directly influenced the language's evolution. As he noted, “usage was like a snowball going downhill. Soon there were hundreds of customers making hundreds of suggestions for improvements. They would find bugs and send them in—not only error reports, but in many cases the fixes would come in along with the reports. … The suggestions just poured in, and we put them in as fast as we could” (Heising, 1984, p. 32). This account highlights how recruitment can initiate a self-reinforcing cycle. As users contributed suggestions and code, they enhanced the language. These improvements, in turn, facilitated further recruitment.

Control refers to the stabilizing influence of documentation, particularly the standard. The increasing number of FORTRAN dialects threatened the compatibility of code across different systems. The standard partly addressed this issue by providing a common foundation. Rather than eliminating variation, the standard reconfigured associations among the actors within the FORTRAN network through negotiated constraints. For example, vendors were permitted to introduce proprietary extensions to their compilers, but these additions had to be layered on top of the standard in order to remain compliant. As Metcalf and Reid (1991) explain, “Users wishing to write portable code had to be careful to avoid extensions” (p. 18). The influence of the standard extended beyond compilers. It also reshaped the documentary infrastructure. Manuals, textbooks, and other materials were revised to reflect the standard's specifications, reinforcing its authority. Unlike historical cases in which official documentation failed to gain widespread adoption (e.g. Zachry, 1999), the FORTRAN standard succeeded not because it was imposed, but because it became embedded within the network of actors and artifacts that constituted FORTRAN's technical and documentary infrastructure.

Articulation refers to the role of documentation in defining and expressing the structure and logic of FORTRAN as a working technology. The technical report specified the design of the language and compiler. The manual and standard defined the syntax and semantics. The scholarly article described compilation techniques. These documents were integral to the design and operation of FORTRAN's technical infrastructure.

These patterns are not mutually exclusive as many documents participated in more than one pattern. For example, the textbook introduced programming concepts to novices, contributing to recruitment. At the same time, it shaped users' understanding of how FORTRAN should be applied in scientific and engineering contexts, contributing to control. This overlap illustrates the multi-faceted nature of collective documentality.

Hacking (2016) uses the phrase “avalanche of printed numbers” to describe the transformation in nineteenth-century Europe when governments began producing large amounts of statistical data to monitor and manage populations. A similar proliferation of paper accompanied the development of FORTRAN. As a system of documentation, the technical report, manual, scholarly article, primer, textbook, and standard collectively shaped the development and adoption of FORTRAN. As the range of documentation associated with FORTRAN expanded, it enabled the system to accommodate a growing diversity of users while concealing the complexity of FORTRAN's internal organization. This dynamic reflects what Latour (1987) describes as black boxing, where the internal mechanisms of a system become less visible as its outputs become stable and widely accepted.

Within this documentation network, users typically engaged with only a portion of the available materials. For example, a programmer might use a manual without consulting the scholarly literature or standard that informed the programming language's design. This selective engagement was not a limitation but a feature of the documentation system. By distributing knowledge across different genres and tailoring content to specific audiences, the documentation enabled users to participate in the system without requiring full visibility into its workings. In doing so, it supported the continued growth and coherence of FORTRAN across institutional and technical contexts. The agency of documentation, therefore, resided not only in the content of individual documents but in the ways they collectively structured access, mediated expertise, and sustained the language's development over time.

By tracing how multiple genres emerged, interacted, and evolved during the early development of FORTRAN, we show that documentation was not simply reflective of the technology but played an active role in shaping and sustaining it. This perspective aligns with rhetorical genre theory, which emphasizes that genres are situated, systemic, and adaptable. Scholars such as Bazerman (1994), Devitt (1991), Orlikowski and Yates (1994), and Spinuzzi and Zachry (2000) have shown that genres operate together, often across institutional, spatial, and temporal boundaries. In the case of FORTRAN, the differentiated work performed by the proposal, technical report, manual, scholarly article, primer, textbook, and standard illustrates how genres collectively supported the recruitment of actors, the coordination of practices, and the articulation of technical operations.

This study also contributes to research on software engineering by offering a historical perspective on documentation practices. While studies have examined how developers navigate Web-based documentary environments through new and emerging genres and platforms (see Chopra et al., 2021; Crowston and Williams, 2000; Earle et al., 2015; Freund, 2015; Montesi and Navarrete, 2008), our analysis shows that such complexity has long been a feature of software development. The FORTRAN case reveals that even in its earliest stages, programming was embedded in a documentary infrastructure composed of interrelated genres.

There are also similarities between the findings and empirical work on the document practices of contemporary software professionals. Research by Freund (2013), Freund et al. (2005), Spinuzzi (2003), and others, has shown that developers select and use documentation based on the demands of specific tasks and contexts. Our findings reinforce this view by demonstrating how early FORTRAN documentation was shaped by audience needs and project phases. The report supported implementation, the manual, primer, and textbook supported learning, while the standard supported coordination across systems.

It is also important to consider how the nature of computing has changed since the period examined in this study (1953–1966). As Hicks (2017) has shown, early programming was often framed as clerical or support work, frequently performed by women and situated within hierarchical institutional structures. Over time, programming became increasingly professionalized, leading to the emergence of formal disciplines such as computer science and occupational identities such as software engineers. These shifts brought with them new documentation practices, shaped by evolving norms, tools, and organizational forms. Today, programming is distributed and collaborative, often conducted across global teams using version control systems, online repositories, and asynchronous communication platforms.

The genres examined in this study were not fixed forms but, as Schryer (1993) describes, “stable-enough-for-now” (p. 229) – i.e. durable yet responsive to changing conditions. These genres were not static artifacts but dynamic tools that mediated relationships among users, technologies, and institutions. By situating the FORTRAN documentation network within this broader historical context, this study highlights both continuity and change in the role of documentation. It shows that challenges such as interoperability, onboarding, and knowledge transfer – often seen as contemporary concerns – have long been addressed through evolving genre systems. The FORTRAN case provides a historical precedent for understanding how documentation can function as infrastructure, enabling participation, enforcing standards, and supporting the long-term maintenance of technical systems.

This diachronic perspective opens several directions for future research. One possibility is to trace the evolution of a single genre, such as the programming manual. Since the release of the first FORTRAN manual in 1956, numerous others have been published, offering a corpus through which to examine changes in form, content, and function over time. Another opportunity lies in comparative analysis. By examining the genre system associated with FORTRAN alongside those used in contemporary software development environments, researchers could better understand how documentation practices have changed or persisted.

This study limits its scope to official documents. Unofficial documents, while often ephemeral and responsive to immediate needs, can nonetheless exert lasting influence. As Zachry (1999) has shown, some unofficial materials endure and can be studied retrospectively through archival methods. Alternatively, as demonstrated by observational research (see Spinuzzi, 2003), these documents can be examined as they are created and used within everyday work settings, offering insight into how they function in practice. By attending to both the historical development of specific genres and collective documentality, future research can continue to explore how documentation mediates technical work.

This paper has examined the role of documentation in the early development and widespread adoption of the FORTRAN programming language. It has argued that documents were constitutive elements in the formation of a sociotechnical system. Through a diachronic genre analysis, the study traced the influence of seven key genres – the proposal, technical report, manual, scholarly article, primer, textbook, and standard – demonstrating how these documents collectively enabled FORTRAN to recruit actors, coordinate practices, and articulate technical operations.

The analysis builds on the concept of documentality, which understands documents as active participants in shaping knowledge, organizing activity, and sustaining arrangements between actors. Rather than treating documents as passive records, this study has shown how they functioned as instruments of coordination, instruction, and standardization. The agency of these documents was not limited to their individual effects. It emerged through their interaction, circulation, and accumulation across contexts. This perspective foregrounds what we have described as collective documentality – the capacity of multiple documents, operating in concert, to shape the development and maintenance of a sociotechnical system.

By identifying broader thematic functions that are evident when documents are viewed relationally, this study offers a framework for understanding documentation as a constitutive force. It contributes to document studies by extending the scope of documentality from individual documents to document sets. It also provides a historical perspective on how documentation co-evolves with the technologies it supports, shaping not only their usability but their very possibility.

Methodologically, this study demonstrates the value of combining documentality with diachronic genre analysis to examine how documentation participates across multiple contexts. Empirically, it contributes a case study of how documentation shaped the emergence and stabilization of the first widely adopted high-level programming language. While this study focused on the first instance of each genre, future research could examine how these genres evolved over time. For example, a comparative analysis of the 1957 FORTRAN manual and a contemporary programming language manual could reveal continuities and changes in genre conventions and documentary expectations.

This case study underscores that documentation is not peripheral to technological innovation but central to it. Documents brought together the people, knowledge, and practices necessary to build and sustain FORTRAN. This study offers a framework for analyzing how documentation shapes and is shaped by sociotechnical systems, shifting attention from the influence of individual documents to the collective role of multiple, interacting genres.