The (Harris) Matrix, Part I: Visualizing Software Stratigraphy

matrixrabbit copy

Prologue

Edward Harris’s 1979 landmark work, Principles of Archaeological Stratigraphy, from which sprouted the idea and practice of the Harris matrix, became my White Rabbit in 2017. I’ve long contended that video games are archaeological sites, that the external media (when present) and the internal content combine to create a digital built environment and a material cultural entry into the contemporary archaeological record. Software, like traditional archaeological sites, changes over time, which includes changes in use, features, and functionality. These changes leave their mark in the dirt and in the code, and can be recorded and ultimately visualized.

matrixstrata

What if I told you that software has strata, interfaces (as Harris defines them), and follows the Laws of Stratigraphy? This post will walk you through Harris’s original theory, ultimately waking you up to the fact that the same method used to visualize the stratigraphy of a site can be used—not allegorically, and not as an analogy—for real archaeology of media. It’s time we put some archaeology into “media archaeology” and illustrated something practical to go with the theory, a tool the video game archaeologist can actually use “in the field.” Welcome to The (Harris) Matrix.

Understanding Stratigraphy of Non-Digital Sites

In chapter 5 of Principles of Archaeological Stratigraphy, Harris defines four laws of archaeological stratigraphy (which stem from the 17th-century geological work of Nicolas Steno), which I will repeat here verbatim, and then I will draw parallels to software (including video games):

  1. Law of Superposition: In a series of layers and interfacial features, as originally created, the upper units of stratification are younger and the lower are older, for each must have been deposited on, or created by the removal of, a pre-existing mass of archaeological stratification.

He goes on to explain this fundamental law: “The determination of superpositional relationships is of first importance in archaeological stratigraphy, as they define the interfacial relationships between the features and deposits of a site. . . . By recording superpositional relationships, the archaeologist amasses a body of data which will be of assistance in determining the stratigraphic sequence of the site.”

For software then, we must think of strata as version numbers (I will discuss periodization and phasing a little later). Version 1.0 of a game marks the foundation of a site (although there will be traces of preliminary settlement in pre-release builds, which start with a version number of “0”). Later versions pile atop the original, forming not neat, standard layers of bug-fixes and added features, but instead creating a very organic map of change not unlike earth-locked strata.

With software, it is nearly impossible to drill down through new code to get to the old code, unless the developer has been religious about commenting the code for future reference (the concepts of code epigraphy and palaeography are outside the scope of this post, but are things I will address in the future). What the (media) archaeologist is left with are the patch notes, lists of changes accompanying each version of a given piece of software. These written notes can be translated for visual interpretation, as will be shown below.

  1. The Law of Original Horizontality: Any archaeological layer deposited in an unconsolidated form will tend towards a horizontal position. Strata which are found with tilted surfaces were originally deposited that way, or lie in conformity with the contours of a preexisting basin of deposition.

When applying this law to software, perhaps the best example is bad code. If good code can be considered as “horizontal,” any bad code can be thought of as having been deposited at an angle, off-center, part of the original deposition. Later code either repeats those bumps in an otherwise smooth topography, or will correct these via various interfaces as will be described in a moment.

  1. The Law of Original Continuity: Any archaeological deposit, as originally laid down, or any interfacial feature, as originally created, will be bounded by a basin of deposition, or may thin down to a feather-edge. Therefore, if any edge of a deposit or interfacial feature is exposed in a vertical view, a part of its original extent must have been removed by excavation or erosion, and its continuity must be sought, or its absence explained.

I apply this law to the media containing the executable code. A disk, therefore, is a “basin of deposition” into which the code is placed. The same could be said of a top-level directory, which exists only digitally and has no physical component. The software, the video game, is deposited within this media basin, something that contains the stratified site/code.

  1. The Law of Stratigraphical Succession: A unit of archaeological stratification takes its place in the stratigraphic sequence of a site from its position between the undermost (or earliest) of the units which lie above it and the uppermost (or latest) of all the units which lie below it and with which the unit has a physical contact, all other superpositional relationships being redundant.

The Harris matrix is based on this law, which describes how to begin to illustrate the stratigraphy of a site. He writes, “the primary object of the study of archaeological stratification is to place the units of stratification, the layers and the features, into their relative sequential order” (p. 36). With archaeological stratigraphy, we seek to illustrate the historical phenomena locked in the strata: what happened, where, and when.

Harris Matrix

Harris matrixes from the 1983 edition of his book, Fig. 22

Creating a Harris matrix for software is little (or no) different that creating one for a traditional site. The same rules are followed. Elements in software code change over time, and these changes can be mapped based on themes/series present in software development. This will become more clear in the practical example illustrated below.

On p. 52 of his book, Harris states the axiom that “all units of stratification have a time or date, measured in years, at which they were created.” Traditional archaeological sites deal with a more geologic sense of time, strata taking years to accumulate, punctuated by other events (e.g., earthquakes, fires, floods, etc.). As with most things digital, time is accelerated. Multiple versions of a software application can appear in the space of days, weeks, and months, creating complex stratigraphy.

So what does that look like? Harris states another axiom that “archaeological stratification is a combination of strata and interfaces” (p. 54). The stratum has depth to it and contains the “stuff” of the deposit for a given period of time. The interface is the line separating different strata from each other. He continues, stating that “as a horizontal layer interface is equal to the extent of a deposit, the surface of which it forms, it is not usually necessary to distinguish it from the deposit when labeling the units of stratification. On occasion, it will be necessary to identify a part of this type of surface and record it as a separate unit of stratification” (p. 55).

For software, this translates to different large elements of a patch release: bug-fixes, improved functionality, and new features, for example. Each of these large-scale elements contains its own strata and interfaces between them. Mapping them together would muddle the stratigraphy, although a top-level Harris matrix can be created to bring everything together.

As with traditional sites, software also displays periodization and phasing. Traditional sites might contain levels from the Bronze Age, Iron Age, and later. You might consider these to be versions 1.0, 2.0, and so on of that site. These gross ages can then be broken down into smaller units of measure: periods. For example, the Late Helladic period was part of the Greek Bronze Age (1650–1060 BCE). The periods are then further subdivided (e.g., LHI, LHIIA, LHIIB, etc.). Periods can also be less formal, namely local periods in the history of a site including destruction, building, and additional construction on existing structures. These phases find an analogue in software versioning, being the “points” in between major releases, v1.1 on the way to v2.0. Just as in traditional site stratigraphy, the same periodization and phasing exist with software, and can be mapped based on data.

Remains of the Play

Understanding stratigraphy includes not only the strata and the interfaces connecting them, but also what each stratum contains: the stuff. Artifacts. More generally: remains. Harris notes three types of remains: indigenous, residual, and infiltrated. As with the rules listed above, I will repeat Harris’s definitions below, followed by the software analogue (pun intended):

  1. Indigenous remains: These objects were made at about the time the formation of the layer in which they were found was deposited. The layer and the objects are considered to be contemporary.

Code, like earthly strata, contains artifacts, which manifest during use/gameplay. Two major examples include bugs and glitches that manifest from the original code, the code-authoring and on-screen manifestation driven by player agency being the formation processes. The code and the bugs/glitches are contemporary; one begets the other. These get patched in later versions, these bug-fixes stacking atop each other.

  1. Residual remains: These objects were made at a much earlier time than the formation of the layer in which they were found. They may have been present in earlier deposits subsequently dug up to provide soil for the newer layer, or, they may have remained in circulation for a long period of time, as happens with heirlooms.

Perhaps the best example of residual remains in software is repurposed code. Code-snippets (or entire blocks of code) can be lifted from one program and used in another. That repurposed code (code spolia?) is in an of itself an artifact, and can contain bugs, etc., which are also remains. When placed into new code, these remains become residual.

  1. Infiltrated remains: These objects were made at a later time than the formation of the deposit in which they were found and were introduced into that layer by various means, which may or may not be detected by a study of the stratification.

Bugs and glitches also fit into this class of remains. Future versions can introduce errors into the original code, the new code and the old code creating emergent behavior not anticipated by the developers, and not caught through standard quality assurance (QA) and play-testing. This non-standard behavior “infiltrates” into the original software’s premise, becoming an artifact, an intrusive one.

Conclusion

In concluding Part I, I hope to have made the case successfully that it is possible to understand software development stratigraphically, using the archaeological method of Edward Harris. The formation processes at work in both analogue and digital sites are similar, and the resulting changes that occur over time can be recorded and then visualized. But why, or more specifically, why do it for software?

The Harris matrix is used to visualize the stratigraphy of a site, to see a graphical representation of its history, of how it changed over time. It enables the archaeologist to understand a site better, especially when considering a site’s chronology. The same can be said of software. The (media) archaeologist can translate the data garnered from patch notes into a visual mapping. The resulting Harris matrix of a software application can then be viewed in order to draw conclusions about development history, that program’s formation process over time. For archaeologists and developers alike, pattern recognition comes into play where one can see if bug-fixes/patches skew consistently to a specific aspect of development. What always needs fixing, or what software elements are most often patched (or enhanced) over time? Seeing this knowledge presented graphically might be able to assist developers in paying closer attention to those problem areas during initial development, saving time and money while producing a more stable, balanced product for the launch of v1.0. For archaeologists, the software Harris matrix does the same thing the Harris matrix does for traditional sites: it’s a complex, visual chronology based on excavation data.

In Part II, I will provide the rules needed to create a software Harris matrix. Part III will contain the completed software Harris matrix for No Man’s Sky, all 550+ stratigraphic units of it.

—Andrew Reinhard, Archaeogaming

Advertisements

6 thoughts on “The (Harris) Matrix, Part I: Visualizing Software Stratigraphy

  1. Pingback: The (Harris) Matrix, Part II: Making the Software Stratigraphy Leap | Archaeogaming

  2. Pingback: The (Harris) Matrix, Part III: Enter the Matrix | Archaeogaming

  3. Pingback: The (Harris) Matrix, Part IV: So What? | Archaeogaming

  4. Pingback: Relics or rubbish? | archaeogamingblog

  5. Pingback: (Im)material Culture: The Archaeology of Machine-Created Environments | Archaeogaming

  6. Pingback: The No Man’s Sky Archaeological Survey: One Year In | Archaeogaming

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s