Engineering obsolescence

Marisa Cohn

Editor’s Note: Marisa Leavitt Cohn writes to us from Stockholm, where she is a postdoctoral scholar studying the politics of software systems and computing work practices.

In this contribution to the series on Hackers, Makers, and Engineers, she tells us about her research on relationships to technological change in a long-lived NASA-ESA software infrastructure project. Her research considers how people live alongside technological change, inhabit the temporal rhythms of computing work, and approach concerns of legacy, inheritance, and survival of computational practices as they contemplate the end of life of the mission.

Marisa has a BA in anthropology from Barnard College and a PhD in informatics from UC Irvine, and she’s joining ITU Copenhagen as a professor in the fall. She’s a member of the ISTC-Social. 

---

Ethnographers have often been positioned in the technology field as translators between the worlds of technology use and design. When I first began my fieldwork with an engineering team at a NASA space science mission, I thought I might be able to trouble this dyadic concept of translation work between design and use by examining a case in which a complex set of translations took place between a diverse set of organizational actors, from scientists to engineers to managers. Indeed, I observed the engineers on the team working on a weekly basis to turn hundreds of observation requests from scientists all across the globe into commands that can be executed on a spacecraft over a billion kilometers away. This complex translation work was supported in turn by hundreds of software tools that had been developed over the years to, as one engineer described it, “turn scientists’ dreams into vectors.”

Yet when I presented early versions of this work to the social computing research community, I found that the relevance of my work was often challenged. The engineering project I was examining was deemed a “one-off,” a bespoke system that served a single purpose, and which was ultimately “disposable” since the spacecraft would be destroyed in space once it had run out of fuel and completed its mission. Not only that, the software tools that I was studying in organizational contexts were now decades old. They were written in FORTRAN and some of the earliest graphical interface programming languages, tools which have largely been abandoned by the engineering community – reaching end of support, dying out, or even being actively petitioned into retirement.

These make great bookmarks now. Image courtesy of http://en.wikipedia.org/wiki/File:FortranCardPROJ039.agr.jpg

These challenges begged the question – what is to be gained by studying the work of engineers maintaining a space robot from the 90s? What is the role of the ethnographer in studying the so-called technological “dinosaurs” – the old-timers who are stuck in engineering methods and tools of the past? What relevance do these obsolete software tools and engineering practices that go along with them have for understanding technology today? Even to many of the engineers at the mission, my interest in their software tools seemed a bit odd. As one responded to my research,

You think our software is interesting?! It’s not Google or anything.

Legacies of a 90s space robot

These questions put me on the defensive about my contribution to the study of sociotechnical systems and my role as an ethnographer in the field. What was my role, as a translator or participant or otherwise? One of the roles I was enlisted into at the mission organization showed that this defensiveness was a part of my informants’ reality as well. I was asked to help with their work towards a final mission report, to help preserve some of the stories of their engineering accomplishments for the historical archive. The archive of scientific data was already assured, but what about the engineering knowledge gathered over the course of the mission? Might the work they have done over the past two decades be of any use for future outer planets missions? What if there is not another mission of this kind for another 50 or 100 years?

As Charlotte Linde has pointed out in her work considering the question of whether we still remember how to go to the moon, obsolescence of storage formats and engineering architectures means that we may find most technical specifications and infrastructures useless in the future. Yet the struggles and pains that the engineers I studied went through in figuring out how to sustain cutting-edge science with the limited computational resources of an outdated vision (from a time when 2 gigabits was considered forward-thinking) might yet have some value. Their questions about the translatability of engineering practices across generational gaps and changing engineering paradigms became my own, as I too had found myself in the position of having to justify the relevance of understanding their social-computational work practices, and ask what role the ethnographer plays in translating across engineering cultures past and present.

This caused me to reflect on the ways that ethnographers of technology are often called upon to understand what is technologically au courant. As recent critiques have pointed out, studies of technology have tended to focus on novel systems and their introduction and adoption and adaptation to various contexts, presenting a bias towards the early phases of technological life cycles. This is a time, perhaps, when technologies are still open-ended and malleable, when ethnographic work might provide value through design implications or critique, or when cultural values are embedded into systems with consequences for how these technologies in turn shape current practices. This is not to say that such work is not critical of the privilege placed on novelty and innovation, but there is still a tendency not to make visible the stories of when and how technologies become old or outdated.

This same tendency plays out in the world of planetary science. By the time the spacecraft was on its way to its destination, the history of the mission as an engineering accomplishment was in many ways already written. The long term maintenance and operations of a spacecraft is engineering work that is marginalized and largely invisible within the public outreach about science, or in celebrations of the historical significance of the work being done at NASA. It is devalued by a “done at launch” perspective that treats infrastructures as static resources – management thinks that “it does the job, and the job can’t change,” one engineer told me, so why should the software? At the same time, engineers are under increasing pressure to bring their infrastructure up-to-date in ways that stretch an already quite lean and fragile set of resources that maintain communication with the distant spacecraft.

In studying such legacy computational systems and obsolescent forms of engineering work, I found myself going against the implicit norm and pressure to study technologies that are current, not least of which seemed to stem from a concern that my work might be deemed obsolescent and irrelevant. Yet there was something intriguing, if a bit foreboding, about the role of ethnographer as a preservationist of dying (engineering) cultures and (programming) languages that hearkened back to the problematic colonial origins of anthropology’s study of the dying cultures and languages that such colonialist enterprises were participating in killing off.

As a result, I gave a lot of thought about what it even means to be technologically current or to be technological contemporaries. Early ethnographic work has been critiqued for constructing narratives of progress and a great chain of being in which so-called savage practices were considered backwards and taken as a window into the past. What does it mean, then, to claim that current engineering practices are backwards and stuck in the past? Is nothing to be learned from a bespoke system that has evolved over many years, even if in many ways it has evolved itself into oblivion? What is at stake in claiming a technology as irrelevant because it is obsolete, or a “one-off” or “disposable” piece of technology? Are we constructing a great chain of engineering cultures and how then is the ethnographer implicated within that?

What can be learned from legacy systems? Image courtesy the Computer History Museum.

One implication of this evolutionary framework might be a claim that some forms of engineering work have remained static while others have moved on. In actuality the engineers I studied with have continued to work with and further develop a continually dynamic and changing system. They have been exploring what might reasonably be considered a alternate set of engineering frontiers, doing things with obsolete programming languages that have never been done before, finding out what happens as an infrastructure gets old and becomes new again and again through loss, aging and decay. Another implicit claim might be to acknowledge that their work practices have co-evolved over time but that their “one-off” is a system without a legacy. It is an evolutionary dead end.

If we examine such technological systems within the context of the lab, we can see the co-evolution of practices and technologies is still afoot. There is always work to be done to keep older systems working with newer ones, and the idiosyncrasies of practice can continue to reveal novel challenges. Even “bugs” in software that is over 40 years old can surface for the first time after years of routinized work. However, when we place such systems alongside their technological contemporaries, within the context of the larger ecology of the technology industry, we realize that there is more at stake than perhaps an evolutionary framework can capture or describe.

Understanding obsolescence as a process

While it can sometimes come as a shock, the sheer abundance of legacy systems in the world means that the work of maintaining such systems is worthy of empirical investigation. Recent work on repair and database graveyards has called for precisely such an understanding of this tail end of the technological life cycle as something not well understood. What work is involved in maintaining the ability to translate between new and old systems to keep them (backwards) compatible? How do engineers working on this mission stay current in their careers and skills? How does obsolescence happen in practice?

As one of my colleagues put it,

If we were all at the bleeding edge, we would be bleeding all the time.

It turns out that the majority of systems are legacy in some way, and if we are not studying these, we are missing a big piece of technology and engineering practice. But what this also calls attention to is the fact that while we may be critical of novelty and notions of technological progress, our participation in studies of the contemporary can participate in this very privileging of the new if we do not attend to the forms of loss and decay that are concomitant with processes of innovation – that is, if we ignore the ways that we are in fact bleeding all of the time, and just just mop the blood on the floor under the rug, or fail to ask what kinds of technological possibilities we are cutting away?

Even the more progressive politics of human computer interaction and feminist science and technology studies, which call for open-ended (rather than deterministic) understandings of technology, are still invested in something that might be called “evolvability” – the inherent possibilities in (or design value of) technology so that can evolve along a multi-directional path and into multiplicity. What work might an investment in a notion of technological “evolvability” do towards increasing processes of obsolescence?

Long-lived technological imaginings

There are some obvious ways in which a study of obsolete systems work might reveal insights of value. For one thing, if we are interested in shifting design towards more sustainable and long-lived systems, perhaps we should look at one that has already been sustained over many years. Is longevity something that we can achieve through developing systems that are more and more evolvable, so agile that they can remain forever relevant and current? Or, as some of my interlocutors in the field suggested, perhaps that is a naïve perspective: “Sure, the new software systems are more adaptable, more flexible,” he said, but the software used on this mission “has been around for 40 years or more. Do you think that python will still be the language that is used 40 years from now?”

While it should be obvious that any software tool or programming language will have a limited lifetime, this becomes a rather profound statement in the face of quite commonplace over-evaluations of present technologies and their futures. His statement also points out how even such values as adaptability are merely trends in software methodologies that are subject to the whims of obsolescence – or they may even participate in accelerating obsolescence.

One of the more serious consequences of this naiveté is that it obscures what is at stake here: not the death of a particular obsolete programming language, but the kinds of technological commitments that are necessary in order to imagine long-lived sociotechnical outcomes. Science missions to outer planets of our solar system become unimaginable within a framework in which technologies must be impervious to obsolescence. It takes seven years to get to Saturn, for example, and seven years is now longer than the life cycle of many technologies we design. In this paradigm, we all, engineers and users alike, have gained the skills of adaptation and evolvability, of short-lived commitments to technology, at the expense of more long-lived ones. As anthropologist of memory Paul Connerton has pointed out, planned obsolescence is itself a form of forgetting, one that is a necessary form of participation in the market.

The consequences of studying the cutting-edge

It may seem an over-reaching analogy, but if we think about the seven years it takes to get to Saturn and what it means to understand phenomena on the temporal scale of the Saturn year (29.7 earth years), we also have to imagine how our investments into technological agility might actually preclude our understanding of processes in other domains on similarly large temporal or geopolitical scales. In other words, the foreshortened lifetimes of our technologies may actually be participating in the foreshortening of other kinds of lifetimes.

As others have pointed out, we have shifted from a time when storage was expensive and processing cheaper (the world where my fieldsite still resides) to one where storage is cheap and processing is expensive. But what makes processing expensive is in part that we are so wasteful with the storage we do have, because we believe that the unlimited powers of future processing can be applied to our current storing practices. From the perspective of a long-lived system, this is naïve because of the obsolescence of storage media and the obsolescence of any particular software programming language or development paradigm. Who knows if in the future agile processes may seem outdated and not suitable to the kinds of work that needs to be done? What if slow computing, light on storage, and carefully and ethically sourced modes of processing, are actually the way of the future? What if we actually should be looking back to find a way forward?

~~~

Returning to the question of the role of ethnography in understanding contemporary engineering cultures, what would it mean to consider how obsolete engineering cultures that sit side by side with current ones are not representative of the “past,” nor of some “phase” in a essentialized technological evolutionary life cycle. Instead, they are different sociotechnical forms with different temporal patterns, and studying them might actually give us clues about the a much richer set of possible technological futures we might yet imagine.

When I first arrived to my field site, I did think of it as a kind of window into the history of computing. In many ways it was the pedagogical experience in computer science I had always dreamed of but never received – an immersive introduction to computation in practice where the histories of the field are not erased away. Oral histories of where and why a particular tool was developed were still intact. I could learn not only about new technologies but also FOTRAN and hex code. As some of the engineers pointed out, this diversity of old and new is what makes long-lived technologies a rich environment in which to work, instead of the “cookie-cutter” approach to software development found elsewhere.

However, after spending 9 months with these engineers, I realized that being an ethnographer is not only about encountering different sites of technology production, but understanding the temporal dimensions of these technologies. I was situated not within a “past” of engineer culture, but within a context which could reveal something about the lifetimes of technologies and what it means to live along side of them. I came to see myself not as a preservationist, but as someone who is a member of an engineering culture that is currently entranced with short-lived systems rather than long-lived ones. That the processes of legacy-making and obsolescence are also open-ended ones – and that I might be able to participate in building legacies that are yet to come.