The elevator pitch, part 2

My argument as bullet points

1. Software capitalism creates profits by keeping the software in a state of perpetual disrepair.
2. The valorisation of disrepair works by increasing the complexity of software products through either deferring the integration of tacit knowledge or employing explicit knowledge to create new abstraction layers.
3. The organisation, in its effort to maintain the complexity equivalent to the software system, risks becoming unable to control and audit the production process.
4. Evolving in the intersection of the market and organisation, production acts as an interface for resolving the contradictions between the two domains by enabling the circulation of knowledge between its two parts, the problem space of production and its epistemic infrastructure.
5. The two main circulation moves here are deployments and integrations.
6. Since the deployments largely operate through freely scalable symbolic manipulations, and the integrations deal with embodied and affective tacit knowledge practices which are not as easy to scale, the organisation’s governance mechanisms evolve to become distributed and adaptive.
7. Starting from a general concern that software production teams usually suffer from unnecessary complications that the organisational protocols introduce to their work, the research question grows to become entangled with epistemological and methodological aspects of production.
8. My question is: what kind of approach does production need to develop towards its epistemic infrastructure to plan and control the uncertain and disruptive situation created by the software complexity?
9. The answer to this question is that the approach is queer in the sense that it supports the performative idea of software. This implies that in its real-life manifestations, software has no stable identity, and always appears as something relative to the context: it can be an assembly of components in the code repository, a compiled binary, an interface between the different types of stakeholders, a site for negotiating boundaries, an archive, a piece of documentation or a contract for provision of services. On top of that, we would never be able to determine with any degree of precision where production stops and delivery begins. In other words, the software does not have a private identity which remains the same regardless of other factors that stand next to it, like a bridge, a car or a paper cup, but has to perform its role every time, depending on what kind of relation it enters with its outsides.

What is your contribution?

In terms of the impact my research has on the wider sphere of software studies, the key contribution is that it opens up a new way of thinking about software in terms of queer theory. This pathway immediately calls for a wider set of updates to some aspects of software studies, such as labour’s relation to performativity, relations between production and circulation, and the role of affect in high-complexity production.

In terms of practical outcomes, two contributions should be mentioned right away:

1. Creating a method that points out specific valorisation mechanisms in high-complexity production. For example, I started from a hypothesis that the process of intentional increase of software complexity is prioritised by those parts of organisations which are interested in sales because it allows to expand production and intensify capital circulation. What I found out later after my research is that tacit knowledge is produced as a means of creating scarcity within the system that otherwise wouldn’t have it due to its fractal character. While in its tacit form, the knowledge is difficult to scale across the system in the event of a complexity spike, it provides a great return on investment in terms of efficiency increase warranted by the momentum. When the agent’s abilities to codify and abstract are overwhelmed, they suffer cognitive shocks, causing losses in efficiency. At this moment, the knowledge is converted to its explicit form, making it possible for the organisation to create new business divisions and address any complexity effects.
2. Another important contribution is the notion of a minimum deployable product (MDP), a reverse side of the minimum viable product (MVP). MVP is frequently assumed in DevOps sources as the system’s initial stable state that can be used in the production environment by test-driven development. MDP of my project effectively functions in reverse to mark the product’s final stable state, which only exists in production until the underlying errors, - or technical debt of the ideal version of the system as it is present in the infrastructure as code, - are dealt with. This finding implies that to maximise the system’s effectiveness, defined here as the amount of social value relative to the limit of the available resources, DevOps has to necessarily ensure the system’s breakdown.
3. The notion of system traction, defined as a relation between the rate of change in a software production system and the ability for its effective audit, is expressed in the adhesion between the system’s epistemic infrastructure and its problem space. While the related notions of the system’s momentum and team velocity are useful for understanding the system’s maturity and the expected efficiency of a team effort, traction relates the system's operational capacity to the organisation’s ability to control it. Traction metric is particularly relevant to distributed production models, where the teams can vary greatly in their professionalism, institutional affiliation and work patterns.

How did you select case studies, and why case studies?

A case to me is an event of problem negotiation that involves a collaboration of human and non-human agents, has an established audit protocol, and is connected to the problem space of production via such means as, for example, support tickets. Cases are flexible and can be nested, and organised hierarchically as well as in clusters based on non-hierarchic sorts of dependencies. Cases are different from projects in that the projects are conceptual devices oriented towards delivery. They are static and report-based and are best described in nouns, such as deliverables, metrics or deadlines. Cases, on the contrary, are elusive and flexible - they are best described by verbs, - even the use of the word ‘casing’ to define the case study method is best because then it becomes possible to understand how they are conducted and carried out. Casing is interested in the processes, rather than outcomes. While projects are indispensable for delivery and reports, the cases are equally necessary for tracing the differences in how specific parts of work are done, or to be able to understand how the problems are negotiated, and how the completion of projects changes the hypothesis in the organisation’s strategy. The selection of case studies was rather straightforward since I was involved in a day-to-day job as a product lead - they would originate from the key features the team was working on, which I would then relate to theory, my cases bear a rather non-personal character in this respect and evolve around organisational trends rather than particular individuals.

What do you mean by methodology? How do you relate to the theoretical and empirical in your understanding of methodology?

I understand the methodology simply as the study of research methods. In my project, the best way of studying research methods is to begin from either patterns or anti-patterns of the research domain, which ultimately means, coming to theory from empirical encounters. This is why cases are more important than projects - with cases, it is possible to follow patterns through the work process as projects come and go. Concomitantly, the casework provides the required interrelation of theory and practice, with its funnel-shaped roadmap.

The roadmap highlights the three phases of casing. The goal at the initiation is to come up with a set of guidelines, usually in the form of a case report, that would propose a way to reduce the amount of knowledge and leave only the evidence specific to the case at hand. In the second stage, the complexity is further diminished through selecting the variables and coming up with the core formulation of the case problem, or any underlying principles. In the third stage, there is the reverse move ‘back to the case’, where the principle is verified through the application in the field, which means widening the complexity aperture. (Rihoux and Lobe in Byrne and Ragin, 2009: 230.)

How do you extend your research into a broader programme? What does your thesis allow you to do?

As mentioned in the contribution question previously, my project opens up a new outlook on DevOps, which means some re-understanding of the main themes and core notions within the discipline. More specifically, there are key themes that require urgent attention within this emerging research programme:

1. System environment component as the space of user-side situated knowledge that emerges in runtime. This is important because it will give the tools for defining the boundary between the software system as an event of continuous deployment, and the ecology of local interactions with it at the point of delivery. Here, we need to theorise a new notion of the problem space of distribution, a counterpart of the problem space of production created in deployments.
2. Another important boundary is defining where hardware stops and software begins. For example, should smartphones be seen as a product in and of itself, or is it conditioned from its inception to delivery as a software-enabling service?
3. The study of the political dimension of affect is another important trajectory due to its potential as a means of reducing complexity. In its use by the sociologist Patricia Clough, affect is the ‘pre-individual bodily forces augmenting or diminishing a body’s capacity to act’, (Clough, 2008: 1) which are open for engagement with the technologies, including both the technologies of circulation and distribution, as well as the technologies of control. The political dimension of such engagements becomes important as the post-disciplinary governance adopts explicit manipulation of affect, such as in soft power, to produce the subjects of value exchanges and control protocols.

References

Byrne, D. S., and Charles C. Ragin, eds. 2009. The SAGE Handbook of Case-Based Methods. Los Angeles ; London: SAGE.

Clough, Patricia T. 2008. “The Affective Turn: Political Economy, Biomedia and Bodies.” Theory, Culture & Society 25 (1): pp. 1–22. https://doi.org/10.1177/0263276407085156.