Digital Ruins and Critical Code Studies: Towards an Ethics of Historical Software Reconstruction
 |
| Pyramid B, Tula, Mexico, as restored by Jorge Acosta in 1941 |
1. Principles of Architectural and Software Reconstruction
Reconstruction has always been one of the most controversial issues for those with an interest in the material evidence of the past. The urge to make whole again a valued building or work of art that is incomplete is a very strong one, similar in some ways to the urge to improve or correct someone else’s text. Both involve a strong desire to see an object that is complete and integral to one’s own satisfaction, rather than tolerate a creative work that has been diminished in its intelligibility. The idea that the object may have a greater value in its incomplete state than if it is reconstructed runs counter to this strong compulsion. Yet that idea has been central to much of the theory of conservation and restoration that developed primarily in the Western world and has subsequently been diffused worldwide. The core of Western conservation theory is epitomized in the question as to how far restoration should be taken (Stanley-Price 2020:12)
I want to suggest that a key conceptual framework for approaching code reconstruction can be developed by drawing on architectural preservation, particularly principles around clearly demarcating contemporary interventions from historical remains. Just as architectural restorations aim to make modern additions visibly distinct while respecting the integrity of historical structures, I argue that code reconstruction should balance functional recovery with clear signposting of contemporary modifications. This suggests implementing specific coding patterns or meta-documentation schemes that flag reconstructed elements while maintaining overall system coherence. As Stanley-Price explains, "different attitudes towards this fundamental question have given rise to some of the most notorious controversies in conservation" (Stanley-Price 2020: 12). Indeed, major disputes in conservation have centred on the question of how much restoration is appropriate. For example, the National Gallery of London faced intense scrutiny over its painting cleaning methods, leading to formal investigations in the 1850s and renewed criticism a century later when scholars like Cesare Brandi objected to what they saw as overly aggressive cleaning practices. Secondly, in the nineteenth century, John Ruskin criticised architectural restoration that attempted to recreate earlier styles rather than preserve the natural aging and patina of historic buildings (Stanley-Price 2020: 12).
When removing or modifying existing code elements in service of reconstruction, researchers must thoroughly document these interventions and their rationale in relation to digital ruins. This documentation should address both technical and historical considerations, explaining how modifications serve broader reconstruction goals while acknowledging their impact on system authenticity. Version control systems offer one technical framework for preserving this record, but projects may need additional documentation or visualisation layers focused specifically on historical interpretation and modification justification. The notions of "reversibility (or, better, re-treatability) and minimum intervention" are often identified as key concepts for undertaking restoration of ruins, and applies equally to digital ruins. Indeed, "there are no textbook rules about when restoration should be carried out nor how far it should go. Instead, each case is deemed to be different and must be judged on its merits" (Stanley-Price 2020: 13).
The integrity of evolving source code presents another key consideration. Historical software systems often developed through multiple phases, accumulating functionality and adaptations over time. Reconstruction efforts must respect this evolutionary character rather than artificially isolating particular historical moments. This suggests implementing versioning or branching schemes that preserve evidence of different developmental phases while allowing exploration of specific historical configurations.
So the question that is posed here is: When should such excavated and incomplete digital ruins be reconstructed to a state similar to how they might once have appeared and how should that reconstruction be signposted to future readers and historians?
This raises a number of questions (see Stanley-Price, 2020). These include: What widely accepted principles are there concerning software reconstruction? How has the practice of software reconstruction been justified (whatever the accepted principles may be)? What are the arguments against it? And, finally, in the light of arguments for and against, what principles can be proposed to help guide issues of software reconstruction? I can only gesture here to some of the answers to these questions, and which would require a more substantive discussion, but by raising these issues I hope to encourage debate in the fields of software studies, critical code studies, computer science, digital media and the history of technology.
When trying to make an analogous case from the example of architectural reconstructions of buildings it is useful to recall that generally in international legislation and guidelines, "the answer to the question whether incomplete buildings should be reconstructed is clear. It is strongly discouraged" (Stanley-Price 2020: 13). Indeed,
At the highest level of international consensus, the obligations of UNESCO’s World Heritage Convention (1972) are legally binding on the states party to it; the number of states party is in fact the highest of any UNESCO Convention. The Operational Guidelines for the Implementation of the World Heritage Convention address the question of reconstruction of buildings as follows: In relation to authenticity, the reconstruction of archaeological remains or historic buildings or districts is justifiable only in exceptional circumstances. Reconstruction is acceptable only on the basis of complete and detailed documentation and to no extent on conjecture (Stanley-Price 2020: 14).
Similarly, the revised version (1999) of the Burra Charter of Australia ICOMOS clearly states,
Article 1.8. Reconstruction means returning a place to a known earlier state and is distinguished from restoration by the introduction of new material into the fabric.
Article 20. Reconstruction.
20.1. Reconstruction is appropriate only where a place is incomplete through damage or alteration, and only where there is sufficient evidence to reproduce an earlier state of the fabric. In rare cases, reconstruction may also be appropriate as part of a use or practice that retains the cultural significance of the place.
20.2. Reconstruction should be identifiable on close inspection or through additional interpretation.
 |
| Charter of Venice (1964) |
In fact, international documents have not prevented the continued practice of reconstruction of historical buildings, for example, the prehistoric Aztec Ruins and Mesa Verde in the USA are both sites that feature reconstructions. Indeed, there are a number of justifications for reconstruction that can be mobilised to legitimise it, such as,
1. National symbolic value. The building played (or plays) an important role in the country’s history, or was associated with an outstanding historical figure. Examples of which include in the US, the Governor’s Palace (1706-1791) was the first major building to be reconstructed after the project to ‘restore’ Colonial Williamsburg began in 1927 and the "eighth-century AD Heijô Palace site of Nara, a place of immense symbolic value in Japanese history, the insubstantial traces of the wooden buildings revealed by excavation have led to full-scale reconstructions of the Suzakmon Gate (1990-1997) and, since 2001, of the Daigokuden Hall of the Palace" (Stanley-Price 2020: 16).
2. Continuing function or re-use. The reconstructed building can continue to serve its previous function or makes possible new, different functions and usage. For example "the Stoa of Attalus in the Athenian Agora, reconstructed in 1953-1956 to serve as a museum, store and workspace for finds from the continuing excavations there" (Stanley-Price 2020: 16).
3. Education and research. The process of reconstruction can, in itself, be a rewarding research project, and the resulting building can be an important didactic tool for visitors. The "many reconstructions of timber buildings based upon archaeological evidence in the USA, northwest Europe and Japan exemplify the combined research and popular education roles of reconstructions" (Stanley-Price 2020: 16).
4. Tourism promotion. A reconstructed building can help to attract tourism and thus generate income for the public or private authorities that manage it. As Stanley-Price notes, "the massive reconstruction of pre-Hispanic sites in Mexico, Guatemala, Belize and Bolivia (Tiwanaku) in the 1950s and 1960s aimed to promote tourism while also demonstrating national pride in the pre-Colombian past. The motivation behind the proposed reconstruction of the Hwangnyongsa Temple in Gyeongju (Republic of Korea) is first and foremost the economic development of the city, especially through increased tourism, and not its potential re-use as a Buddhist temple" (Stanley-Price 2020: 16).
5. Site preservation. Reconstruction, by showing that the site is being actively used, thereby helps protect it from development pressures; alternatively, it may serve to stabilise precarious ruined structures and landscapes.
 |
| Firmiano Castle (945) – Bolzano, Italy. New footbridges and stairs create a new layer, clearly visible against the stone walls of the complex. |
Similarly arguments against reconstruction of buildings also have a salience to the discussion of the reconstruction of digital ruins.
1. The evocative value of ruined buildings. A ruined building left as it is can be more evocative of the past than that same building reconstructed or restored. For example, "the preservation as a ruin of the A-Bomb Dome at Hiroshima is one example from outside Europe" (Stanley-Price 2020: 17).
2. The difficulty (impossibility?) of achieving authenticity. Reconstructed buildings are de facto new buildings, often tending to reflect the culture and times of their creators, rather than being faithful reproductions of the original. Indeed, "because reconstructions do involve conjecture to a greater or less degree, the tendency will be for their architects to be unconsciously prone to other influences. Thus the influence of Beaux-Art ideals has been noted in the reconstructed Capitol building at Colonial Williamsburg and as a possible inspiration for Evans’ use of colour in the Knossos reconstructions" (Stanley-Price 2020: 17).
3. The ethical issue of conveying erroneous information. Inaccurate reconstructions can very easily mislead the professional and lay publics unless clearly identified as such. For example, "the use of comparative evidence from other pre-Colombian sites for reconstructing Pyramid B at Tula in Mexico (see above) led astray future scholars who were unaware of what had been reconstructed and how" (Stanley-Price 2020: 18).
4. The destruction of original evidence. Many reconstructions have, sadly, either destroyed or rendered inaccessible the evidence on which they are based, to the detriment of future scientific research. It is interesting to note "the practice in Japan of leaving a layer of earth or concrete to separate the original subsurface remains from the foundations of the reconstruction" (Stanley-Price 2020: 19).
5. The disruption of landscape values. A reconstructed building in an otherwise "ruined" landscape may distort visual and spatial relationships. For example, "the monumental scale of the reconstructed Stoa of Attalus in the Athens Agora,... the Gymnasium of the Baths at Sardis...and the Temple of Hatshepsut at Luxor exemplify this phenomenon" (Stanley-Price 2020: 20).
6. Distorted site interpretation. The complexities of sites with a long history can be obscured if they are reconstructed to feature, or over-emphasise, a particular historical period. Indeed, "At Knossos ‘the casual visitor – and often even the specialist – can forget that Knossos is the largest Neolithic site on Crete […] and […] is one of the two largest Greek and Roman sites on the island’. On the Acropolis of Athens, almost all evidence of post-Classical building had already been demolished in the 19th century as part of the post-Independence glorification of the remains of Classical Greece" (Stanley-Price 2020: 20-21).
7. Cost. Reconstruction projects tend to be very expensive and often can only be financed by the political authorities who insist they be undertaken. This can cause political decisions to over-rule expert decisions on the validity of restoration or reconstruction.
While these architectural preservation principles emerged from decades of debate over physical structures, they offer valuable insights for the nascent field of historical software reconstruction. The parallels are very interesting and just as architects must decide how to mark modern interventions in historical buildings, software preservationists face decisions about how to distinguish original code from contemporary additions. The challenges of incomplete evidence, the tension between functionality and historical accuracy, and the need for clear documentation of interventions manifest similarly in both domains. However, software reconstruction also presents unique challenges. Unlike buildings, where physical traces often remain visible, software can be completely lost, leaving only documentation or partial code fragments. The intangible nature of software, existing simultaneously as human-readable text and machine-executable instructions, complicates straightforward application of preservation frameworks. Moreover, software's dependence on specific technical environments, from operating systems to hardware architectures, also creates additional layers of complexity in reconstruction efforts. Despite these differences, I argue that the core ethical principles developed in architectural preservation can provide valuable guidance for approaching software reconstruction.
While these theoretical principles provide a framework for approaching software reconstruction, their practical application becomes clearer when examining specific cases. The reconstruction of ELIZA, one of the earliest and most influential chatbot programs, offers particularly useful insights into both the technical and philosophical challenges of digital preservation.
2. The ELIZA Project: A Case Study in Software Reconstruction
The ideas behind applying this problematic to digital ruins arose from attempting to revive the ELIZA source code, from 1965, that was discovered in the MIT archives in 2021 (see Berry and Marino 2024). As a member of a project involving a number of technical experts and programmers, I was very much struck by the difficulties of not only returning historical software objects to functioning and executable programs in their own right, but also the need for "hacks" and creative solutions in order to help provide the scaffolding for the software to run correctly (Lane et al 2025).[3] Indeed, to reconstruct the ELIZA system "required numerous steps of code cleaning and completion, emulator stack installation and debugging, non-trivial debugging of the found code itself, and even writing some entirely new functions that were not found in the archives or in the available MAD and SLIP implementations" (Lane et al 2025: 6).[4] This included modifications or reconstructions to both the ELIZA source code and the SLIP source code – this is crucial because ELIZA uses SLIP functionality to operate (see Weizenbaum 1966, 1967). For example, in attempting to compile the recovered ELIZA and SLIP source code the following functions and problems were reported by the compiler:
- BCDIT, used in function FRBCD, appears to be converting a binary number (the rightmost 18 bits according to the multiplication of K) to a string of BCD. We replaced this with the CTSS library routine DELBC.
- INLST is used in XMATCH and ASSMBL, two of the most critical ELIZA functions. It appears in the Fortran implementations of SLIP, and seems to take the cells of the first parameter and add them to the left of the list cells of the second parameter, so we wrote our own in MAD.
- The LETTER function was not in either the MAD or SLIP documentation, was not in the archive code, and google was not helpful. Inference from the calling code suggested that it classified characters in a word into one of 14 categories (An equal sign (*=') returns 1, a comma (*,) return 13, the digits '0'-'9' return 12, etc.) We wrote this function ourselves, in MAD.
- We had FAP code for KGETBL that returned the desired entry in the right hand 6 bits but padded the remaining positions with spaces, so we masked these off.
- The MAD compiler on CTSS seems not to support $$ in string constants to mean emit a single $. The 1963 MAD manual confirms this, saying there is no clean way to put a $ in a string (8, p. 20], but suggests this somewhat bizarre workaround: TEST=-$=$ will set TEST to "$ "
- Some initialization of common data areas appeared to be missing, causing the loader to fail. We added code to ELIZA.MAD to initialize the public list W(1): LIST. (W(1))11
- The CTSS loader then failed due to too many object files CTSS did have a 'huge loader' where these limits are relaxed, but this component was not present in the emulated system. Luckily the source code for the loader was available in the operating system source tape dumps, so we compiled and added this.
The challenges of software preservation have already prompted several institutional frameworks and initiatives that inform reconstruction practices (Cosmo and Zacchiroli 2017). UNESCO's PERSIST Project (Platform to Enhance the Sustainability of the Information Society Transglobally) has developed guidelines for selecting digital heritage for long-term preservation, while emphasising the importance of preserving both software artifacts and their contextual documentation (Choy et al 2016). The Software Heritage Initiative, launched in 2016 by INRIA, represents perhaps the most ambitious attempt to create a comprehensive archive of software source code and development history. By 2025, it claimed to have archived over 22 billion unique source files from more than 344 million software projects. These frameworks highlight the tension between preservation at scale and detailed reconstruction of individual artefacts. For example, while Software Heritage excels at capturing source code snapshots, it cannot preserve the full technological stack which would include hardware dependencies, build environments, and runtime contexts, and that is required to enable complete functional reconstruction. The Internet Archive's Software Library takes a different approach, focusing on emulation-based access to historical software, though this too faces challenges in accurately reproducing original computing environments. These institutional efforts provide important infrastructure and best practices for software preservation, but as this article argues, they must be complemented by more granular approaches to reconstruction that maintain historical fidelity while acknowledging interpretative interventions.
The case of ELIZA's NEWKEY and PRE function offers another instructive example of this archaeological reconstruction process. While the original 1965 ELIZA MAD-SLIP implementation recovered from the MIT Archives lacked these functions, Weizenbaum's 1966 CACM paper describes their crucial role in managing keyword processing and conversation flow (see Weizenbaum 1966, 1967). From the paper, we knew that NEWKEY served to abandon the current keyword match attempt and restart processing with the next keyword in the stack. As Weizenbaum explains, "Whenever this rule is invoked, the top of the keystack is 'popped up' once, i.e., the new regnant keyword recovered and removed from the keystack, and the entire process reinitiated as if the initial text scan had just terminated." The preliminary transformation PRE was a reassembly pattern that was also not implemented in the code that was recovered from the archive. Although these were not implemented in this first reconstruction of this 1965 version of the ELIZA code, and hence it does not accurately reproduce the algorithm described in the CACM paper, if this were to be implemented as new code then the 1966 version of ELIZA might be more closely replicated (see Lane et al 2025: 9-10). In this case, I would argue that the key ethical obligation in reconstructing these functions would be to clearly document which aspects derive from historical evidence versus contemporary implementation choices, much as in a reconstructed building one might use pigmented concrete to signify part of the reconstructed elements.[5]
This also raises questions about the distinction between emulation (reproducing their internal logic and architecture) and simulation (replicating observable outputs or behaviours without necessarily maintaining fidelity to internal processes) in relation to the reconstruction of software artefacts.[6]
 |
More lines of code were removed than added in the ELIZA/SLIP reconstruction. The removals came from duplicate or unused functionality. The additions created missing functions that were used by ELIZA (see Lane et al 2025). |
The experiences gained from the ELIZA reconstruction project, combined with lessons from architectural preservation, point toward the need for a more comprehensive ethical framework for software reconstruction. While the ELIZA case demonstrates the technical challenges of reconstructing historical software – from missing functions to infrastructure dependencies – it also reveals deeper questions about authenticity, interpretation, and historical accuracy that parallel longstanding debates in architectural preservation. Building on both these practical insights and theoretical foundations, we can begin to articulate a set of principles that address the unique challenges of preserving digital artefacts while maintaining historical accuracy.
3. Towards an Ethics of Software Reconstruction
The ELIZA project's specific challenges – from adding missing functionality, managing technical dependencies, and balancing historical accuracy with emulator compatibility – suggest several key principles that can guide future software reconstruction efforts. Drawing from both the practical experiences of code reconstruction and established frameworks in architectural preservation, I propose the following ethical guidelines for approaching digital ruins:[7]
1. Form of Reconstruction. A reconstructed digital ruin – if based primarily on recovered evidence – must be considered a new implementation (that is, reconstruction as a creative act). Here the numerous reimplementations of ELIZA come to mind as good examples of this. The notion of "volumetric reconstruction" from architectural preservation offers a particularly useful analogy. In architecture, this involves recreating the spatial volumes and relationships of historical structures without necessarily reproducing their exact material form. Applied to code reconstruction, this could mean implementing the broad functional architecture and data flows of historical systems while using contemporary methods that make the reconstructive nature of the implementation explicit. This maintains historical fidelity at a structural level while acknowledging the interpretative nature of the recovery process.
2. Processuality of Reconstruction. Reconstruction of one or more digital ruins is to be considered only if the values (including the computer history value) of a software artefact will be better appreciated than if the digital ruin are left in a ruined state (the ruin as a source of inspiration or as a memorial). For example, the reconstruction of Geocities by the Internet Archive, GeoCities Special Collection 2009, is a good example of this as it allows the site to be explored dynamically, capturing some of the original practices associated with Geocities.
3. Formal Documentation. The surviving evidence for the former digital ruin must be fully documented in such a way that this record is always available in the future (a scientific and ethical obligation to record for posterity).[8] This is something we have been striving to do in the Finding ELIZA project by blogging and publishing the processes involved in our work.[9]
4. Preservation of the Digital Ruin. The surviving evidence for the former digital ruin, or for different historical phases of it, must not be destroyed or made inaccessible by the very act of reconstructing it (a scientific obligation to allow (built) hypotheses to be verified or rejected). For example, in creating emulators of legacy computer systems there is sometimes a tendency to "fix" the problems in an original system. For example, the implementation of accelerated loading of computer games on ZX Spectrum emulators often does not reflect the slow loading times, of many minutes, and evocative sounds of the real systems (see Fuse - the Free Unix Spectrum Emulator).
5. Public Explanation and Justification. The evidence – its strengths and limitations – for the reconstructed form of a digital ruin must be interpreted clearly to all users (an ethical obligation not to mislead or misinform the public). Documentation frameworks for code reconstruction must operate at multiple levels: inline source documentation, architectural overviews, historical analysis, and public presentation. Each layer serves different audiences while contributing to a comprehensive record of the reconstruction process.
6. The History of Reconstructions. Digital ruins that have been wrongly reconstructed in the past could, on a case-by-case basis, be preserved as they are (reconstructions as part of the history of ideas). Many reconstructions of digital artefacts have been made quickly and for the benefit of seeing and using the original system, without much concern for its historical accuracy. Many of these reimplementations may now become historical items of interest in themselves as they trace the development of ideas in code, but also the code environment and assumptions of the programmers that made them (see ELIZAGEN - The Genealogy of ELIZA for an example of this).
,%20also%20known%20as%20kintsukuroi%20(%E9%87%91%E7%B9%95%E3%81%84,%20%E2%80%9Cgolden%20repair%E2%80%9D)%20emphasizes%20the%20breaks%20and%20cracks%20in%20a%20piece,%20rather%20than%20hiding%20them..png) |
| Kintsugi (金継ぎ, “golden joinery”), also known as kintsukuroi (金繕い, “golden repair”) emphasises the breaks and cracks in a piece, rather than hiding them. |
These considerations point toward specific technical approaches for implementing reconstructed code. Source annotations, specialised comment formats, or colour could flag reconstructed elements while preserving readability. Modular architectures might cleanly separate historical and contemporary components. Build systems could generate different versions emphasising either historical fidelity or modern functionality. The key is establishing consistent conventions that future researchers and historians can readily interpret.
The archaeological approach to code reconstruction developed in this article highlights the importance of treating software as a historical artefact worthy of careful preservation and study. The process of reconstruction itself becomes a form of critical engagement with computing history, revealing both the technical innovations and the social contexts that shaped early software development.
The aim should be to preserve both the historical computational logic and make visible our interpretative moves in bringing these early programs back to life.
I argue that, beyond technical implementation, projects must also consider how to present reconstructed code to different audiences. Public-facing user interfaces should clearly communicate the nature and limitations of reconstructions without requiring deep technical knowledge. Scholarly interfaces might provide more detailed access to underlying evidence and interpretation, but both serve the broader goal of ethical historical presentation of digital ruins.
By drawing from the standards developed in relation to architectural and building reconstructions, I hope to have shown that for the case of software, code and algorithms, the integrity of historical evidence should remain paramount throughout a reconstruction process. While creative interpretation may be necessary to recover lost functionality, projects must resist the temptation to exceed available evidence without explicit acknowledgment. This will require developing clear standards for evaluating evidence and making interpretative decisions around digital ruins, software and other forms of digital artefacts.[10]
Indeed, I argue that the field of critical code studies needs to develop shared frameworks and best practices for code reconstruction projects. These might include:
1. Standard documentation formats for reconstruction evidence
2. Common patterns for marking reconstructed code
3. Guidelines for evaluating historical evidence
4. Frameworks for presenting reconstructions to different audiences
While architectural preservation principles offer valuable insights for software reconstruction, we must also acknowledge potential limitations of the analogy I introduce here. Unlike buildings, software exists in a fundamentally different ontological state, as simultaneously human-readable source code and machine-executable instructions. This dual nature creates unique challenges that architectural preservation frameworks may not fully address.
For example, software's inherent mutability and its dependence on complex technical ecosystems distinguish it from physical structures. While a restored building can stand independently, reconstructed software requires a compatible computational environment to function. This technical dependency chain may necessitate preservation approaches that go beyond traditional architectural principles and require more intensive reconstruction and interpretative efforts, for example of the underlying operating system such as CTSS in the ELIZA case study.
Additionally, the concept of "authenticity" can be said to operate differently in software. While architectural preservation can often work with physical remains, software reconstruction frequently deals with complete absences, such as missing functions, lost documentation, or obsolete technical contexts. The binary nature of software functionality (it either runs or it doesn't) may sometimes force choices between historical accuracy and operational viability in ways that don't precisely parallel architectural restoration decisions.
Finally, software's reproducibility and potential for perfect copying introduces questions about originality and authenticity that do not generally arise in architectural preservation. When we can create exact duplicates of source code, what constitutes an "original" becomes less clear than with physical structures. This also means that when editing the code, there can be a mistaken assumption that another "original" will remain in existence elsewhere, when that may not always be true. For example, contemporary ways of thinking about software often make the assumption that software like git, or repositories like github, will always exist, which to look at historical change in software environments, almost certainly will not be the case.
These limitations suggest that while architectural preservation principles provide a useful starting point, we must remain open to developing new theoretical frameworks specifically tailored to software's unique characteristics. The field of software reconstruction may ultimately need to synthesise insights from multiple preservation traditions, not just architectural ones, while developing its own distinct approaches.
Conclusion
Through careful attention to documentation, clear marking of contemporary interventions, and ethical presentation of evidence, code reconstruction projects and critical code studies can make important contributions to software history while maintaining scholarly rigour. The field faces ongoing challenges in balancing functional recovery with historical accuracy, but I argue that established principles from architectural preservation and public history offer useful guidance.
A critical code studies ethical obligation in code reconstruction involves conveying to users the evidential basis and degree of certainty behind reconstructed elements. This parallels requirements in other forms of public historical presentation where knowingly conveying inaccurate information without disclosure would constitute serious ethical breaches. Software reconstruction projects should therefore develop clear frameworks for communicating the status of different system components, perhaps through layered documentation or interactive exploration tools that reveal the historical foundations of various features.
This article has sought to demonstrate how code reconstruction requires both technical expertise and the humanistic contributions of fields like critical code studies. Success of a project of digital reconstruction depends not just on implementing missing technical functionality but also on creating transparent, well-documented systems that clearly communicate their historical foundations and contemporary modifications. Only through demonstrating such attention and care for its object of analysis, documentation and transparent presentation can projects that attempt to reconstruct digital ruins serve their dual role to create both functional software and useful contributions to the historical record.
Blogpost by David M. Berry
Notes
[1] The reconstruction of historical computer code raises interesting philosophical questions related to the paradox of the Ship of Theseus. Wasserman explains, "the ancient historian Plutarch recounts the story of the famous ship of Theseus, whose parts were all gradually replaced as they wore down. The resulting ship was eventually displayed in Athens, where philosophers debated whether it was still the original ship of Theseus, despite having none of the original parts. In the modern era, Thomas Hobbes added a further twist to the story. Suppose that a custodian collected the original planks as they were removed from the ship and later put them back together in the original arrangement. In this version of the story, we are left with two seafaring vessels, one on display in Athens and one in the possession of the custodian. But where is the original Ship of Theseus?" (Wasserman 2021). If we gradually remove, replace or rewrite aspects of historical source code to make it executable on emulated or contemporary systems, at what point does it cease to be the original program? This connects to deeper questions about the authenticity and materiality of software. Unlike physical artefacts, source code exists simultaneously as text to be read and as executable instructions, complicating straightforward application of preservation frameworks. The processual nature of software, which must be compiled and executed to fulfil its function, suggests that perhaps code reconstruction requires new philosophical frameworks beyond traditional conservation approaches.
[2] Team ELIZA include David M. Berry, Sarah Ciston, Anthony Hay, Mark C. Marino, Peter Millican, Jeff Shrager, Arthur Schwarz, and Peggy Weil. See https://findingeliza.org/
[3] The project team involved in reconstructing and executing the original ELIZA source code was Rupert Lane, Anthony Hay, Arthur Schwarz, David M. Berry, Jeff Shrager (see Lane et al 2025).
[4] Technical dependencies present a complex challenge for software reconstruction that extends beyond mere technical constraints. The archaeological metaphor is particularly apt here, as reconstructing historical software requires understanding not just the code itself but of sometimes extinct computational ecosystems. These include operating systems, programming languages, hardware architectures, and library functions that formed the technical substrate for historical programs. The MAD programming language used in ELIZA, for instance, depended upon specific IBM 7094 hardware features and the CTSS operating system environment that are difficult to faithfully reproduce. For example, CTSS uses "6 bit BCD character encoding, packing six characters into a 36 bit word. (This was before bytes or ASCII were invented!)" (Lane et al 2025: 7). Contemporary infrastructure also imposes its own constraints and affordances that shape reconstruction choices, often invisibly. This creates infrastructural translation problems where decisions must be made about how to map historical technical dependencies onto modern computational systems. These choices are not merely technical but involve critical interpretation of how different layers of historical computing infrastructure related to one another. For example, reconstructing a function that relied on specific hardware memory layouts requires decisions about whether to emulate those memory structures or reimplement the functionality in modern terms, something that the reimplementation of the SLIP functionality used in ELIZA raised repeatedly. The available documentation often proves insufficient for fully understanding these technical dependencies, forcing reconstructions to make interpretative leaps that should be explicitly acknowledged. This suggests that technical dependencies function not just as practical constraints but as crucial sites for critical analysis of historical software systems.
[5] The discontinuities and absences in historical software documentation create particular epistemological challenges for reconstruction. Unlike architectural ruins where physical traces remain visible, gaps in software documentation often represent complete erasures of technical knowledge. There may also be functions and comments in source code that do not appear to have any use or application to the software and the temptation to "clean" the code by removing extraneous code, that is, deleting duplicate or unused functionality, should be discouraged. When encountering missing functions like ELIZA's LETTER routine, which categorises all six characters in its input, or KGETIN, which returns one of those six 6-bit values, those undertaking reconstruction face inferential boundaries where they must reason about lost computational processes from their surrounding context. This archaeological process involves careful analysis of function calls, variable usage patterns, and remnant comments to deduce the probable behaviour of missing components. However, these reconstructive acts necessarily involve creative interpretation that must be distinguished from verified historical knowledge. The challenge is complicated by what we might call documentation asymmetries where detailed information exists about some system components while others remain completely undocumented. This creates particular difficulties for understanding how different parts of historical systems interacted. The computational nature of software adds additional complexity, as missing documentation about seemingly minor technical details can render entire systems inoperable. See, for example the reconstructed LETTER example at https://github.com/rupertl/eliza-ctss/blob/main/eliza/src/SLIP/SLIP-reconstructed/letter.mad
[6] The distinction between emulation and simulation is crucial for understanding different approaches to reconstructing historical software systems. Emulation attempts to recreate the exact behaviour of historical systems by reproducing their internal logic and architecture, often at the level of hardware operations. Simulation, in contrast, aims to replicate observable outputs or behaviours without necessarily maintaining fidelity to internal processes.
[7] These are based on the precedent of architectural and building reconstructions described by Stanley-Price (2020: 21-22).
[8] The widespread adoption of version control systems offers intriguing possibilities for documenting software reconstruction processes. Git, for example, creates what is effectively a computational audit trail through its commit history, recording not just changes to code but also the temporal sequence and rationale behind modifications. This suggests an infrastructural approach to preservation where the archaeology of reconstruction becomes encoded within the version control system itself. However, this raises important questions about the relationship between Git's technical implementation of history (through directed acyclic graphs of commits) and historiographic approaches to software reconstruction. Version control systems risk imposing their own logics onto historical narratives, potentially obscuring alternative temporalities and developmental trajectories. Additionally, while commit messages can capture technical rationales, they may inadequately document the interpretative and creative decisions inherent in reconstruction work. There is also a deeper question about preserving the version control system itself as a historical artefact, since Git repositories depend on specific technical infrastructures that may not persist. This points to a need for critical approaches that can leverage version control's systematic documentation capabilities while remaining attentive to its limitations as a historical record.
[9] Documentation hierarchies in historical software reconstruction present a complex layering of technical knowledge that requires careful critical analysis. We can identify distinct documentary strata: published academic papers, technical reports, user manuals, source code comments, and the code itself. Each layer exhibits differential persistence, where certain types of documentation prove more likely to survive than others. Academic papers, positioned at the highest level of abstraction, often provide system overviews but lack crucial implementation details, for example in the Weizenbaum 1966 CACM article (see Weizenbaum 1966, 1967). Technical reports occupy an intermediate position, offering more specific details but frequently omitting practical considerations evident only in source code, this can be seen in the numerous PROJECT MAC reports from the 1960s. The code itself, when available, represents the most concrete documentation but paradoxically may prove the most difficult to interpret without supporting materials – certainly the case in the ELIZA project. This creates interpretative challenges when documentation layers contradict each other or when crucial connecting information is lost. For instance, ELIZA's source code relies on technical assumptions documented only in often poorly scanned MAD language manuals. These hierarchical relationships between documentation types suggest the need for reconstruction methodologies that can triangulate between different documentary levels while acknowledging their varying degrees of authority and completeness. A methodological challenge is understanding how these different forms of technical knowledge related to and informed each other in their historical context.
[10] Legal and licensing considerations add another critical layer of complexity to software reconstruction efforts. Historical software often exists in a legal grey area where original licenses may be unclear, missing, or incompatible with modern usage. The reconstruction of UNIX serves as an instructive example, as Computer Research and Development (CSRG) at Berkeley released their UNIX contributions under the permissive BSD license, other components remained under AT&T's proprietary license, leading to the complex legal battles of the 1990s USL v. BSDi case. Modern reconstruction efforts must navigate similar challenges for determining the copyright status of abandoned software, handling code with multiple or conflicting licenses, and deciding how to license reconstructed components. The Software Freedom Conservancy's efforts to preserve GPL compliance in historical software provides useful guidelines. indeed, projects should carefully document the license status of both original and reconstructed components, while considering whether certain reconstruction approaches (like clean-room reimplementation) might help navigate legal problems.
Comments
Post a Comment