Space and time of infrastructure

Space and time of infrastructure  ### Infrastructures that do not work My mission is to explore the infrastructures that do not work. I look at inefficiency and dysfunction because to me it opens a path to thinking about who benefits from it, but also more importantly, presents the inefficiency as intentional. In other words, accidental and inconsistent knowledge features in the present are purposefully created to set up future capital returns. In this sense, I find the case of digital infrastructures, such as Public Cloud services (AWS, Azure or Google Cloud) as the most productive, since they are present in the form of software, in code, which is essentially a kind of writing (the software operations refers to this type of infrastructure with a very descriptive term, ‘infrastructure-as-code’ ). Due to its nature as writing, such systems allow the capitalist financialisation mechanisms to scale up to great extremes. Infrastructure-as-code is a code that, when executed, is capable of starting the servers, partitioning disk images to create data storage units and databases, building up alarm and messaging services, and consolidating all of the parts into the unified infrastructure with reports, dashboards and command line interface (shell) access. For example, here’s a breakdown of virtual services that I have been working on recently, that enables the operation of a standard online publication website via AWS: ![](DraggedImage.png) What you see here is that the architecture is broken into several services, with all of them as a whole coming together to create a functioning digital infrastructure, yet, similarly to the material infrastructures of roads and bridges that exist in the real world, the cultural, organisational and imaginary elements are so closely intertwined with technology that the idea of infrastructure as a whole starts to lean heavily towards its epistemology, - that is, the most appropriate method to study it becomes a method that looks at the knowledge that precedes the system, exists in it, and asks about the kinds of knowing it enables and produces. Therefore, my working definition of **infrastructure** identifies it as a system-agnostic network where the nodes are the institutions, people, buildings and information resources that generate, share and maintain specific knowledge. What we see in the illustration above is only a part of the picture, more specifically, the part that allows for the frictionless circulation of capital devoid of the physical particularities of real time and space and organisational cultures. ### DevOps imaginary Even though this kind of research falls squarely in the purview of software studies, it is not concerned with the traditional software studies agenda, such as the critical study of software engineers and other staff as individual contributors. I’m more interested in dealing with DevOps - a discipline that has emerged in the mid-noughties in the intersection of software development and operations. In the definition of one of its key protagonists, business consultant and engineer, David Farley, DevOps’ key feature is its interdisciplinarity, which allows inter-divisional access in and across organisations for the sake of reliability of software releases. In a more general sense, DevOps is a methodology for the production of the means of production that deals with the business strategy in the form of code, termed appropriately as ‘infrastructure-as-code’. Two points are worth mentioning here. First, the uncritical study of DevOps, which has increased since the inception of this discipline does not carry as much potential as the original idea of merging development and operations, since it only focuses on polishing the existing status quo, and cares mostly about productivity metrics, which makes the majority of operations research procedurally solutionist. In other words, much of the management research is more concerned with innovation and has the goal of intensifying the circulation of capital within the existing framework, rather than inventing or creating a disruptive change, which could aid in developing new frameworks and theories. For example, project and quality management studies look for the roots of efficiency concerns beyond production and argue that ‘increased efficiency means getting more out of the resources used’, [^1]which expands the influence of efficiency control mechanisms beyond the service provider into the supplier and customer organisations. > Supplier and customer quality assurance: ‘increased efficiency means getting more out of the resources used’ Second, the virtual quality of operations in public cloud services, of course, does not mean that Amazon and other providers do not have to build new server warehouses as their turnover scales up. What likely happens, I argue is that time and space get split up from the moment when digital components are introduced into the infrastructures viewed in their capacity for circulation of capital - that is, there appears the space and time of infrastructure, separate from the clock time and topological space of the real-world production. ### Queer space and time To address those two points, I focus on this production of new space and time by adopting the critical instrumentation of queer theory, and specifically how this theory deals with spatial and temporal dimensions. I refer to this process as ‘queering the infrastructure’, relying on such queer theorists as Judith Halberstam and Siobhan Somerville. ‘Queering’ in this sense is the practice of undoing normativity beyond the application to body or sexuality, which intends to understand the means and purpose of existing identity categories, both normative and non-normative. Since ‘queer’ operates through non-normative logics, it has the potential of creating a view of embodiment, community, organisational culture, and their dealings with technology that would produce notions of time and space which are more productive than simply techno-essentialist and capable of differentiating the temporal and topological attributes of an infrastructural imaginary from those of the material world. In this context, the proposal for queer DevOps is based on the interpretation of software systems, including digital infrastructures, as queer performative phenomena. They are queer in their ambiguous context-dependent manifestations, coming from the theorisation of Karen Barad, for example, by unclearly wavering or flickering from being a product to being a service. They are also performative, rephrasing the fundamental gender performativity postulate of Judith Butler, in that digital entities are constantly evoked to perform various roles in the real world, every time deployed from scratch as imprints of a larger architectural logic that creates the conditions of possibility for institutional and cultural epistemologies. The queer performativity of software comes from its indeterminate nature which evolves together with the users and contexts, for example, Microsoft Word, which does not contain any text by default, takes shape every time it is launched and the new text is entered. Thinking about normativity and technology makes me raise some difficult questions, for example, what’s the relation between the two has been, and how is it changing? Is it possible to challenge the normativity in technology to distinguish how technology can be queer and in which ways its performativity can be superimposed onto the performative dynamics of organisational cultures? One pathway that I’m exploring now is the notions of space and time, as some of the most persistent characteristics of infrastructures, digital and material alike. Halberstam, in their work on space and time categories, engages with _queer time_ as a specific model of temporality that emerges within contemporary culture once we leave the temporal frames of the normative ethos of reproduction, family, longevity, risk/safety, and inheritance. _Queer space_, correspondingly, refers to the place-making practices in which queer people engage and it also describes the ‘new understandings of space enabled by the production of queer counterpublics.’[^2] To conclude, the queering of both time and space helps to reveal the meaning of inefficiency for the sake of profit I mentioned in the beginning. _Queer time,_ in its counterposition to the normative idea of time in management studies, deals with the work, resource and risk breakdown structures, and carrying out scope, schedule and cost planning. These are essentially diagrams and plans of something due to change and therefore will never have happened, not least because of those diagrams and plans. _Queer space,_ on the other hand, provides a reference scale which departs from the complete and externalised presentation and human-to-human relationship. Instead, it dissolves the subject to become imperceptible and dehumanised, albeit still richly imbued with affect. Here, we can look at another set of diagrams, such as this matrix org chart and matrix of responsibilities, discussed by project management educator Fred Harrison and the team topology diagram from the DevOps practitioner Matthew Skelton. These diagrams can arguably respond to questions nobody asks them, for example, about the new relationship to events through the entanglement of the more-than-human subjects comprised of impact and influence stakeholder forces, technical protocols, compliance policies and cultural and managerial artefacts.[^3] [^1]: Kojala et al., 2008: 17. [^2]: Halberstam, 2005:18. [^3]: Lykke,2022:130.