continent. maps a topology of unstable confluences and ranges across new thinking, traversing interstices and alternate directions in culture, theory, biopolitics and art.
Issue 6.1 / 2017: 4-12

"Lifetime Issues": Temporal Relations of Design and Maintenance

Marisa Cohn

Figure 1: Julie W. takes a call in her office

I am sitting in the office of lead systems engineer, Julie W.,[1] who is responsible for overseeing the engineering team that operates the spacecraft and ensures its health and safety as it orbits Saturn collecting scientific data. Julie has dedicated much of her career over the past twenty years to the Saturn Mission at the Planetary Explorations Laboratory (referred to colloquially as “the Lab”), working first as the Testing Conductor when the spacecraft was in ATLO (Assembly, Test, and Launch Operations) before transitioning to the lead engineer for the Spacecraft Office to manage operations. We have just come from a dramatic meeting convened to discuss mysterious electrical charges that have been building up on the craft after the repeated shorting out of one of its scientific instruments. The critical dispute at the meeting centered on whether these shortages comprise a risk beyond the local instrument’s functionality – potentially impacting the craft as a whole, along with its eleven other scientific instruments – thus requiring caution before turning the instrument back on. At stake if the shortages indeed pose such a risk, is the ability of the spacecraft to fly another five years, the current projection of how much flight time they have left on remaining fuel, and upon which much scientific observation depends. At the same time, a final decision to not turn the instrument back on means the closing up shop of an instrument’s engineering facility and the end of data collection for many disciplinary scientists who use it.

At the meeting, Julie deftly shifted the debate away from the instrument team’s perspective, to a contest between two competing theories of the craft as a whole: one presented by an engineer who had worked with Julie back in the ‘90s on the design and assembly of the spacecraft, flown in specifically for this meeting; the other by an engineer on her current team who has been maintaining the craft for years. On the one hand, she has the theory of a developer who has intimate hands-on knowledge of the spacecraft when it was “still on the ground” – knowledge of its inner workings, manufacturing specifications, and designs; on the other, an operator who has worked with the ongoing behavior of this now remote object day in and out over the decade and a half it has been in flight around Saturn.

This conflict between two theories of the craft, touches upon a divide between two career identities and domains of knowledge at the Lab – between the work of designing, developing, and launching missions and that of operating and maintaining them. This divide, which I will gloss interchangably as design vs. maintenance or development vs. operations, is often explained by engineers at the Lab in terms of the different skills or personalities that are required in different phases of the lifecycle of a mission. It is indicative of the sharp distinctions between professionalized career identities at the Lab that in addition to Developers and Operators also includes Navigators, Science Planners, and Project Managers. At the Lab, these identities cut across mission organizations and have their own lab-wide meetings and personnel management. This “cultural divide” between operator and developer occupational identities is also well established in the engineering management literature which has, for example, shown how it can lead to misconceptions about the nature of work,[2] prevent organizational learning,[3] or obscure invisible forms of work that cross this boundary.[4] This distinction is also pervasive in the software engineering industry and has spurred its own new professional identity of “DevOps” – people who can bridge the gap between Dev and Ops.[5]

Figure 2: Devnet Opsnet: For software developers at the Lab there are distinct ethernet jacks for connecting to the development versions of software systems and those in operations

As Schein outlines, while developer culture orients to an industry-wide occupational community and emphasizes planning for safety, perfectly running machines, and designing humans (or room for human error) out of the system; operator culture is defined locally in relation to the continuously changing environment and ongoing learning or “expected surprises” that arise due to the interdependencies of any complex engineering system[6]. Foundational studies of organizational practice in science and technology studies have also explored this divide in terms of “relations of technology production and use” drawing attention to the contingent nature of operations work that disrupts idealizations of design as a singular authorial practice.[7] As Suchman puts it, “products of professional design will always be based in partial, specifically situated and historically constituted projections” of an artifact’s life, whereas ongoing operational work inevitably surfaces discoveries due to the contingencies of a shifting operational environment.[8]

A truism at the Lab conveys this division aptly, declaring that a spacecraft is never flown by the people who designed it. This is said to hold true at the Mission, which experienced a major turnover of management and personnel when it began to conduct its first scientific observation as it passed by Jupiter on its way to Saturn in 2001. From Julie I heard that this truism reflects the sense that operations work involves uses and conditions that were never “intended” in the original design, something which significantly perturbs developers who cannot bear to see the purity of their designs altered.

Figure 3: Bunnysuited engineers pose for a photo in the cleanroom during ATLO – Assembly Test and Launch Operations

Operations work, in this view, demands letting go of designs to make room for the emergent life of an object in space which could never have been fully known in advance. It is precisely this unknowability that had Julie’s lead operator for the spacecraft bus (the main body of the craft, akin to a computer’s motherboard) jumping up and down with excitement at the meeting as he proposed his theory of why the shortages were occurring. From his point of view, no matter what facts the developer could draw forth from manufacturing specifications of the spacecraft hardware, these could only ever be based on simulations and estimates. In contrast, the team was now witnessing a frontier of engineering knowledge – having never seen what happens when these resistors and capacitors endure the vacuum of space for so many years. The very duration of this machine’s lifetime, its aging and decay, propel it to the cutting-edge and if he can convince his team and superiors of his theory he might just get a publication out of it.

Figure 4: Lead engineer explains why the shortages are occurring

This shorting out of an instrument was one of several disruptions that emerged during my time at the Mission that engineers began to refer to as “lifetime issues.” While there are many sources of disruption to routine work on a mission, lifetime issues are those that are attributed to the aging of the craft, precipitated not by any particular occurrence so much as by the very longevity of the craft. Other examples of “lifetime issues” included when one of the reaction wheels (wheels used to articulate the position of the spacecraft) started to show signs of “drag” – a jump in the amount of torque needed to command the wheel at a particular speed. Ultimately the cause of drag was attributed to the seizing up of lubricant in the reaction wheel casing, something which was not predicted by its manufacturing specifications which guarantee its cycles per lifetime based only on upper bounds of spin rates. What was never simulated, nor feasible to simulate in manufacturing tests, was what happens when this wheel dwells at very low speeds, just shy of zero, for extended periods of time, as happens when stabilizing the spacecraft in its orbit on a regular basis. Every time I think of this, I imagine two hypothetically identical wheels, separated at birth, one living out a slow death in space, the other expending its short life at a manufacturer’s testing facility, spinning at its maximum speed until it expires.

Wikipedia: Reaction Wheel

 The wheel’s seizing up or the instrument’s shorting out are both moments of rupture in the work of the spacecraft team, moments which can also be quite final about the fate of an instrument, or a wheel, as well as the forms of work that attend them. Yet they are also the outcome of a slow drag over time, as the externalities of the assumptions embedded within these design specs build up slowly over time until they become evident. Lifetime issues, rather than residing strictly in the time of maintenance, draw together multiple moments from across the life of an artifact. The partial death of the craft, the loss of one of its instruments, is a moment “out of order” [9] not only because it is a moment in which things have broken down, but because of the way that two forms of knowledge about the craft that are ordinarily kept distinct are put to test against one another.

Figure 5: Julie explains the assembly of the craft

In her office, Julie tries to explain to me the details of the competing theories, walking me through a circuit diagram used at the meeting to discuss where the shortages are theoretically occurring. She then pulls down one of her commemorative 3D models of the craft to show me how the instrument is positioned in relation to its sensors or “pick-ups”. Dissatisfied with both of these, she pulls out an enormous binder of hi-resolution photographs cataloging the spacecraft hardware when it was still being assembled. As she leafs through picture after picture, she traces the wires with her fingers, showing me where her engineers fused the wiring together that “gives the spacecraft [hardware] its great performance to this day” and where the wires connect to the spacecraft sensors, its “eyes and ears” that deliver the telemetry data that is all her team now has on hand to figure out what is going wrong with the craft.

There is something about seeing these images of the spacecraft in ATLO, its internal wirings exposed, after so many months at the Mission seeing only models, diagrams, data visualizations, and software simulations, that gives me a sudden visceral experience of the distance in both time and space between the craft depicted in these photos and the one now orbiting Saturn, fully out of reach. Here Julie is, in the midst of a debate about an object which cannot be touched or observed directly, tracing the wires in the photos almost as if to bring the tactile memory back to her from years ago. Despite the mundane day to day operations of keeping a craft in flight and delivering science, it is also a reminder of the awesome feat of maintaining such fine-tuned control over a machine that is over a billion kilometers away. It also drives home the feeling that the craft can be in two places at once. It can be here in the Lab through models, diagrams, software programs, simulations, design documents, code libraries and high-res photographs as well as flying in outer space. The craft is multiple[10] and its trajectory from design to launch to operations to death is not a simple linear temporal arc. These multiple bodies of the craft that may originate in different times, in fact co-exist and continue to re-articulate each other in practice.

Figure 6: A timeline mural of the Mission traces from the earliest forms of astronomical technique up to the launch of the Mission. This linear narrative illustrates the "done at launch" attitude that many operators complain discounts the work that happens after launch.

The decision over whether to turn a shorting instrument back on, draws out development and operations as competing theories of the craft, as differently embodied ways of knowing its materiality, that are epistemologically incompatible: one based in the authority of having been there during the spectacular time of launch, the power of being together with the craft when the Mission originated; the other based on the authority of having lived with the craft over time, through the period when the spacecraft has become known in its particularities. The contrast then is not only between competing ideas but between two different modes of knowledge, both of which Julie’s career spans.

Figure 7: Still from Clip Julie explaining the wiring of the spacecraft bus

Julie, tracing the photographed wires with her fingers, seems almost to be trying to recall the craft and its materiality, to bring that time back to her. She begins reminiscing not only to the time when these photos were taken, when the spacecraft was in ATLO, but also tracing out the entire coincident timeline of her own career path and the life of this object. Julie explains that it was her intimate knowledge of the craft, knowledge that was gained when the craft was physically present, that recommended Julie to her superiors as the right person to take over operations of the craft.

As she explains to me, that is why they brought her on as the head of the spacecraft office as they entered into operations. “They needed someone who had been there, touched the spacecraft.”

“My claim to fame is that when I tell [the project manager] about the solid state power switches, I know how they look, I know where [they are], their combination, I know how they’re plugged in, how they’re wired. I’ve traced the wires out to wherever the parts went. And I think that is a fairly unique background for operations. Not very many people want to follow [a spacecraft] into operations. It takes a special kind of person. At [the Lab] operations is not particularly valued as a career choice. You know, they want designers, they want the paper writers. And so it is funny… we always laugh because it is operations—running a spacecraft in flight – is what gets you in the newspapers. If we were successful in doing our job then this is great, these great pictures come down and they hit the spacecraft and they hit the newspapers and [the Mission] is wonderful. If it is a disaster in operations you get: “spacecraft saved again” or “lost spacecraft.” So you’re still in the newspaper. And so while I don’t claim to understand why operations is not a valued position, I do just kind of say, well we’re the ones that get you publicity, good or bad.”

Julie goes on to compare her own “meandering career path” with those of her male colleagues with whom she worked in the past, men whom she describes as the “cream of the crop” and “top of their class at CalTech” who went “straight to the top” at the Lab. These are men, still touted as the “pioneers” of the Mission, whom I had seen arriving to podiums to receive accolades or to speak about the accomplishments of the Mission at lab-wide events, venues where stories of the frontiers of space science are told and re-told, events well-attended by Mission engineers who still claim these men as their own. In deciding to stay on as lead engineer of Spacecraft Operations, she expresses feeling at the time like she was “dropping out of the game,” watching as her colleagues moved on to mission after mission. Yet she also speaks with gratitude for the longevity of the spacecraft, grateful to the engineers who fused its wires together so well, that give the machinery its great performance to this day, and which has granted her a long and fulfilling career. “I used to think I might have had another mission in me. But I think I’ll ride this one out… It’s been a good ride.”

Figure 8: The stickiness of career identities: a joke placard given to Julie by her engineers with a mantra to help her remember she is no longer the ATLO Test Conductor after she continued to sign off with her old handle.

In this articulation, development and operations are not only two forms of knowledge or career paths, but also different temporalities. Development work enables engineers to always be at the forefront of space science engineering, working on the newest missions about to launch, working with the latest technologies and methodologies; whereas operations work inherently entails devaluation as the forms of work and technology that might have been current at launch slowly obsolesce. Development work runs in faster time cycles, the quickened pace of “the game” – whereas operations work represents the long dureé, the “ride” or “slow burn.” Development and operations are in this sense chronotopic in that they bring together strong identities with spatial and temporal ordering of organizational practice and narratives.[11]  In the spectacular time of assembly and launch and the drawn out time of maintenance what is ordered is not only work and the movement of people onto and off of projects, but also affective temporal relations to work as expressed in the “game” or the “ride”. Development work brings with it the power of being together when the craft is built, the deadlines and the spectacle of the launch. Operations work involves coming together with colleagues over many years, an “epic journey” in which lives are marked out together by the alignments of major personal life events to mission milestones, punctuated by retirements and deaths of both robots[12] and colleagues, as well as by the launches of other missions.

Routine meetings at the Mission are interrupted for lab-wide events to celebrate mission launches. Engineers also make an effort to attend mission launches, a once in a lifetime experience.  Photos from one such event were shared by one engineer after she returned from her vacation spent attending the final launch of the Endeavor space shuttle from the Kennedy Space Center in Florida.

Yet while we can see these two forms of work as temporally and culturally distinct, they are also brought together. For one, they come together in the sense that they are always understood in relation to one another. Julie’s comparison between the game and the ride reveals the ways these two identities are worked together in relation. Julie, tracing the wires with her fingers is not only trying to recall the craft and its materiality, but is also tracing out a comparison between these two forms of life as they coincide within her own career. She is tracing out the shared history of her own career and the life of the spacecraft object. Her uncommon choice to stay with the Mission, provides a source of continuity to the team and forges a link between development and operations. Within the time of the spacecraft’s lifetime, then, as in the duration of her career, these heterogeneous knowledges are bound together, and she as she faces a decision about the end-of-life of one part of the spacecraft, she struggles to make a cut between them.



Ensmenger suggests that within software engineering the two kinds of work that are considered development and operations share more than they differ. He suggests that instead of there being anything essentially different between the two, we ought to consider what the demarcation accomplishes in practice.[13]  It is true that the boundary between these two forms of work breaks down at the Lab at times, such as when “development talent” needs to be retained in operations work roles during times when no missions are in development. The changeover of personnel from development to operations on the Mission is also gendered in that this changeover comprised a male attrition from top roles which have mostly been taken over by women. This leads to a feminization of operations work which likely contributes to its marginalization. In this sense operations acts as a form of reproductive labor[14] in that it continues to accrue success to the Mission’s designers even as it is seen as merely maintaining the status quo.

Design is a time of origins, of seminal moments, of creativity, while maintenance is the time of stasis, a form of reproductive labor that is not meant to generate novelty (which is why when it predictably does produce novelty this is treated as a crisis or source of pathos rather than par for the course.) Design often succeeds in achieving its quickened temporality through deferral of the problems that are too messy to deal with under the pressure of launch. This often leads to the pathologizing of operations as the vector if not the origin of mess. (I heard many times that the Mission “attracts” personalities, or that people need a strong personality in order to work there, or that particular people attract bugs to surface in the 40-year old code running there.)  So while I concur with Ensmenger that we should ask what the demarcation accomplishes in practice, this demarcation is not something that is done once and for all at the moment of “hand-off” but is done again and again. In drawing attention to lifetime issues I wish to consider not only what the purification of these two kinds of work accomplishes but also what adheres in their relation to each other over the lifetime of a technological object.

Lifetime issues are a particular strain of mess which arises not only from the deferrals of design but from the deferrals that are inherent in any decision, they form a kind of wake of decisions that have been lived with for a long time. At the Mission there was always a critical distinction drawn between forms of discovery and of forgetting. When an anomalous event occurs, such as unexpected data being returned from the craft, or when a fault is triggered, the appropriate response is framed in terms of whether the event was due to something which the organization already knew about the behavior of the craft or its operational environment but was forgotten, or if this is a form of “discovery” of something previously unknown about the craft – something you hope happens rarely at such a late stage in the lifetime of the Mission. Yet the attribution of “lifetime issue” to such an event has a way of dissolving this distinction since a lifetime issue is in some ways both a form of discovery and a form of forgetting – it is a kind of unforgetting of something which should have been known all along but never was.

In one such instance during my fieldwork when the spacecraft went into “safing” – a very rare event in which the spacecraft cannot read a received file and points towards earth to await further instruction) – there were major concerns about whether an error had been introduced in a software update sent to the craft. As it turned out, the file sent was corrupted by a single “bit flip” – a zero turned to a one due to the bombardment of cosmic rays. This was, of course, a great relief to Julie and the project manager since they could simply resend the original file. But this event was also re-framed as a lifetime issue, given that the occurrence of cosmic rays, while rare, are bound to intercept the radio signal to the craft so often during the long life of the craft. “Over the years,” Julie offered, “the spacecraft has in a way become a fine-tuned instrument for detecting the occurrence of cosmic rays.”

The usual attempt to distinguish what is forgotten from what is discovered simultaneously purifies the source of an anomaly to either the human or the machine while locating that source in a specific moment within a linear progressive temporality. Whereas, lifetime issues seem to reside in the very notion of the duree, neither then nor now, and locate the event within a collective body of the craft, its infrastructure, the organization and the people within it. Design and maintenance are coupled together in a relation that is at times symbiotic and at other times parasitic, but typically one that is gendered as masculine/feminine. Yet lifetime issues also reveal relations in excess of that heteronormative coupling; they constitute a “queer time” in which the temporal logics and forms of knowledge that were previously purified from each other touch, where “continuities… and contradictions among past, present, and future” and are shown to be bound together.[15]  

In this sense, lifetime issues present a disconcertment[16] in the distinction between development and operations work. Rather than maintenance being merely design’s after, it is its other. Operations is development’s alterlife in that it requires rethinking the scale of entanglements and inheritances.[17] Drawing on Freeman, they show how technological media, rather than only evolving over time, also produce “nonsequential forms of time… that fold subjects into structures of belonging and duration.”[18] 

What lifetime issues surface are the ways that both development and operations are bound up in the co-histories of people and objects over time.  When lifetime issues arise they reveal the ways that development and operations work are articulated and re-articulated in relation to each other throughout the lifetime of the object. They form a kind of looking back that gathers up the shared timings and co-histories of people, organizations, and artifacts into a collective. Lifetime issues thus highlight that the relations to design and maintenance are at once temporal and affective, as well as how these two are drawn together within the duration of the object’s lifetime.



[1] The uniqueness of this case makes anonymization difficult. I have anonymized the mission organization and laboratory in order to diminish any undesired effects a direct link to the article might have on ongoing operations. With the exception of Julie W., whose particular work experiences are central to this piece, I have anonymized other engineers at the mission by combining roles and attributing quotes to pastiche personas in order to obscure links to specific individuals working on the mission. Other events and circumstances are lightly fictionalized to reduce technical nuance not relevant to this analysis

[2] Jerry S. Busby and Ralph E. Hibberd, “Mutual Misconceptions Between Designers and Operators of Hazardous Systems,” Research in Engineering Design 13, no. 3 (September 1, 2002): 132–38.

[3] Edgar H. Shein, “Three Cultures of Management: The Key to Organizational Learning,” Sloan Management Review 38, no. 1 (Fall 1996): 9–20.

[4] Lucy A Suchman, “Working Relations of Technology Production and Use,” Computer Supported Cooperative Work 2, no. 1–2 (1994): 21–39.

[5] See for example, “DevOps: Solving the Gap Between Operations and Development Teams | Sandhill,” accessed February 13, 2017,

[6] Schein.

[7] Suchman 1994.

[8] Lucy Suchman, “Centers of Coordination: A Case and Some Themes,” in Discourse, Tools and Reasoning, ed. Lauren B. Resnick et al., NATO ASI Series 160 (Springer Berlin Heidelberg, 1997), 41–62.

[9] Graham, Stephen, and Nigel Thrift. "Out of order understanding repair and maintenance." Theory, Culture & Society 24.3 (2007): 1-25.

[10] Annemarie Mol, The Body Multiple: Ontology in Medical Practice (Duke University Press, 2002).

[11] Philippe Lorino provides a brilliant analysis of chronotopes of engineering work including design, operations, manufacture, and sales: “The Bakhtinian Theory of Chronotope (spatial-temporal Frame) Applied to the Organizing Process,” in Proceedings of International Symposium on Process Organization Studies. Theme: Constructing Identity in and Around Organizations, 2010, 11–13,

[12] For discussion of robot death see Janet Vertesi, “Seeing Like a Rover: Visualization, Embodiment, and Interaction on the Mars Exploration Rover Mission,” Social Studies of Science 42, no. 3 (June 1, 2012), p 406-7.

[13] Ensmenger, Nathan, “When Good Software Goes Bad: The Surprising Durability of an Ephemeral Technology” (MICE (Mistakes, Ignorance, Contingency, and Error) Conference, Munich, (September 11, 2014). 

[14] Silvia Federici, Revolution at Point Zero: Housework, Reproduction, and Feminist Struggle (PM Press, 2012).

[15] Elizabeth Freeman, Time Binds: Queer Temporalities, Queer Histories (Duke University Press, 2010).

[16] Helen Verran, “Engagements Between Disparate Knowledge Traditions: Toward Doing Difference Generatively and in Good Faith,” in Contested Ecologies: Dialogues in the South on Nature and Knowledge, ed. Lesley Green (HSRC Press, 2013), 141–61.

[17] Murphy, Michelle, “Keynote Plenary Presentation: To What Extent Is Embodied Knowledge a Form of Science and Technology By Other Means?” (4S/EASST Conference, Barcelona, 2016).

[18] Freeman, 11.