Paper: Unruly Bodies of Code in Time
An online discussion in the Learning From Incidents community made me dig out my notes on a work of ethnography joined with software engineering titled Unruly Bodies of Code in Time. It's a chapter from a book, written by Marisa Leavitt Cohn, which studies how software engineers tend to consider their code to be timeless and immaterial, but at the same time turn out to have harsh judgments on legacy code, obsolescence, and the impact on their careers. I've picked this one because a) I needed it this week b) it's a cool humanities view of software engineering c) it has some solid quotes.
The chapter is organized first in an overview, and then in "vignettes", which are sample stories from the ethnographic work, done by embedding themselves in the software development teams at the JPL labs (NASA) responsible for the Cassini mission.
She first mentions that software engineers deal with "material instantiations of code" particularly when dealing with long-lived projects running on legacy software. They have to deal with unmaintained languages, older hardware, deprecated protocols, and keeping things running. Yet at the same time, there is a strongly held belief that code itself does not decay, much like math, I assume.
Bodies of code are increasingly bound up in the contingencies of historical organizational decisions, material constraints of available technologies, as well as the careers of those maintaining the code.
[...]
The negotiations that take place in managing aging software are not only a matter of securing computational systems from disastrous changes; they are also a matter of how engineers manage the temporality of obsolescence and the entanglement of their own careers, language proficiencies, and expertise with the lifetimes of systems they develop or maintain.
[...]
Those who want to commoditize their expertise must then detach themselves from the concerns of particular bodies of code and their accidental materialities, and align with more universal, timeless ideals of code as immaterial.
The first vignette is from a guy who works as a navigator first, and sees software as a tool to do his job, but not an end in itself. He wants to bring in a new more modern system and has to write glue code to make it work, but also wants to make sure he remains seen as a navigator, not as a software guy, because then he's gonna be stuck handling more software:
Aligning to software work can make one indispensable if you are the only person who knows that tool, which could be bad in the long run if some other more exciting mission comes up. It also puts you at risk of becoming a software person and being seen as someone to ask to write code rather than to design a mission tour. [...] working with the new software was also a matter of distancing himself from the legacy systems in operation at Cassini that are no longer relevant.
[...] By positioning himself against the legacy software to his broader professional network at the lab, William made sure that while he was aligned to the mission system, he was not aligned to the software code in the same way that his colleagues were.
His colleagues turned out to call him out on it as if he were "selling out" to the newer system because he aligned to newer regimes. From his perspective, they are “fearing the corpse but gripping the casket.”, which is an absolutely quotable bit.
The second vignette is from a green engineer working with some old ass code base and frequently triggering incredibly old bugs that nobody else triggers because they all tend to know how things are supposed to work. By not knowing what the unspoken rules are, he keeps walking into decade-old erroneous behaviours that people had no idea could happen, such as writing over files that were supposed to be immutable for 40 years or so.
Generally the code is a sort of patchwork of various fixes, and takes a life of its own:
When I ask if after he surfaced this bug in the system, were they able to fix it. “Not really, but [we could] just be more aware of [it]. We call those ‘features.’ When it is something that you can’t change and is just the way it is. It’s a feature. Like we have features,” he says, as he gestures to his face.
This, as the author later points out, is a very direct sign that code is material and not intemporal, but career engineers will keep stating and believing code is intemporal.
The third vignette is about a software developer who actually likes working with legacy software, enjoying the sort of detective work required. He had first worked on the Cassini mission in 1996, left for other projects, and had then more recently come back. He stated, specifically, that working with new software made him feel like a replaceable cog in a machine; new work is cookie-cutter, broken down like in an assembly chain. This felt repetitive and made his experience irrelevant.
The author points out that the general take of software engineers is to believe newer systems are better. Newer systems are generally thought to be overvalued because they're expected to be more future-proof. She does ask:
What does it mean, after all, for a system to be more maintainable than one that has been maintained for over 40 years? Systems are durable, not because of some attribute of the programming paradigm in which they arise, but simply by virtue of people contributing to keep it going.
She mentions that working with newer systems isn't so much a gain in what they can do, but the ability to continuously truncate the histories behind them. In order for code to act as a commodity, its historicity must be removed:
In long-lived systems, particular temporalities of work must be maintained in order for the system to remain vital, and likewise a system can “fail” for lack of those who know how to program in older languages. [...] legacy is considered a derogatory word, referring to code that has stuck around too long and become heavy. Old software is pathologized for being mired in the past, and those who care too much for it are as well. [...] At the same time, newer systems and methods are adopted with a rhetorical promise of eternal youth, as the solution that will never age.
[T]he “trope of immateriality” is both analytically weak, smoothing over technical complexity, and ideological in suggesting that digital systems liberate us from the historical and material contingencies of other media
She concludes by mentioning that software can live and die by the people leaving projects and taking away the memory and history required to keep it current with its surroundings. She solidly sits in the camp that all software is material and temporal. Software engineers maintain a sort of "moral economy" where old code requires more and more maintenance, and its maintenance work is therefore de-valued, and people perceive more and more privileges towards software that has not yet been written.
This ethos shapes the attachments and moral commitments of engineers to competing valuations of maintenance and innovation. As in rubbish theory, legacy code is that which is not yet thrown away but is durable despite its devaluation and troubles the moral economy of software work. It is in this duration of unruly bodies of code in time that the ideology of “immateriality” lives
Does anyone think she got much wrong?