The well known Austrian information scientiest Gerhard Chroust wrote an article “Software-Archäologie: Eine interdisziplinäre Betrachtung” (“software-archaeology: an interdisciplinary view”) in which he compares the maintenance of software with archaeology. It is a kinda cool and funny article, really.
The article, published in 2005, is available at Springer, but as it is written in German, I thought I’d summarize the most important points here. I want to point out at the beginning that I couldn’t find any blatant misrepresentation of archaeology in this work. That’s great because I am so tired of people imagening only Indiana Jones moments in archaeology or not recognising the importance of context and always asking “what is your most important find?” or thinking we’re looking for gold or… I’m sure you guys know what I’m talking about. So, kudos, Prof. Chroust, kudos.
Never change a running system!
Software maintenance is an important topic to all those who work within the information sciences. In the 80’s (already!) some people reckoned that 80% of the industrial work on software was in maintenance. Also, a good system needs to be able to adapt to changes. If no changes are implemented anymore, a system is dead. This may mean, that “good old” software sometimes is a better alternative than newly developed solutions. If an old system still runs, it has lived through many changes, a lot of mistakes were eliminated, they incorporate “coded knowledge” and developing a new solution might be more cost-intensive than maintaining this old one.
Same, same, but different
All in all, so Chroust, there are some similarities between old software and archaeological finds. In both cases, they
- survived their planned time of use,
- are often not usable anymore,
- their developers are not available anymore,
- the documentation may be unreadable, incomprehensible or not available,
- the motivation and concepts behind them are forgotten,
- if seen in the context of their time, some aspects of them might be understandable,
- the analysis might be clouded by the analyst’s understanding of the technique,
- the knowledge that went into the development of the system / archaeological object might be hidden and forgotten,
- some parts of the system / archaeological object might have been changed often, might have been removed and are now missing,
- some parts might not even have been in use during the service life of the system and therefore cloud the analysis,
- the system / archaeological object has been developed within a technological framework which is unsafe and instable from today’s point of view.
Finds and Software: Not quite the same
Of course, some differences arise through the different point of views of the disciplines: Archaeologists are primarily interested in the old system in its own context and the knowledge generated from their analysis, whereas software maintenance tries to embed the old system into the new modern context. Archaeology is also mostly working with static objects, whereas software maintenance cares for the procedural and operative knowledge inside the code, which it needs to adapt to new challenges. I have to add here that archaeologists might work with static objects, but quite often we very much want to learn about the knowledge and the procedures behind them as well. Nonetheless I concur with seeing the difference here.
Nonetheless, in both cases the aim is the recovery of information. Chroust cites Philippow, Pashov, Riebisch (2003): “The available evidence in a legacy software system often is not sufficient for its understanding and recovery. In most cases the software documentation is outdated and poor…, the most reliable information is in the source code.” and adds that by erasing “software” and replacing “source code” through “archaeological objects” this sentence rings true for archaeology as well.
Similar Workflows
Also, the steps towards the aims of archaeology and software maintenance are similar:
- Recognising (finding archaeological sites / finding reusable software subsystems [not so important])
- Saving and Preserving (field work / saving the information and availability)
- (Re-)documenting and Understanding (field documentation / understanding principal coherences on the operational level)
- Re-allocating (archaeological objects to museums or storage / software to new platforms)
- Restoring (removing patina etc / restoring compatibility)
- Reconfigurating (e.g. chronological analysis / understanding which configuration is in use)
- Reverse Engineering (understanding function and use / finding semantic and pragmatic information)
- Re-Engineering (e. g. experimental archaeology / implementing the old system anew)
- Re-use (not so much in archaeology / very important in software maintenance)
- Presenting (very important in archaeology / not so important in software maintenance)
Similarity in the Sources
The last point contains again a similarity: In both cases the “source material” is unprepossessing. Archaeological sites by themselves are not easily understood by the laymen, if at all there is something to see. Same is true for old software. This makes it sometimes difficult to explain to outsiders (and sponsors) the importance and relevance of the field. Also in both fields Virtual Reality (VR) offers new possibilities of visualising the researched material.
In conclusion, even though the term “software-archaeology” is a bit of a sad joke, there are surprisingly many similarities!
The need for Archaeoinformatics
And one point Prof. Chroust did not think about at all is, that we archaeologists using computers (which, admittedly, is every archaeologist by now) have the need of software maintenance as well. Old databases, that need to be transferred to a newer system, old GIS-maps that are not easily opened in new programs, old statistical analyses done in outdated programs, old code in R, which may not run anymore in new package versions… I’m sure everyone can add to this list.
Which means, even archaeologists need software-archaeology.
