Your second brain, built right.
~ / formula · blog
The elevator pitch, part 1

The elevator pitch, part 1

This week I’m looking back into my PhD research because my final exam is coming up at the end of the month, and the materials merit inclusion in this and the next newsletter because they in any case underpin the trajectory of ACD. Moreover, this writing has to be legible enough since I’m explaining the main bits of my argument to those who are not entirely familiar with the research. This is going to take the form of questions and answers, based on the questions usually asked during the PhD exam, or viva, and thus provides a more intermittent, bite-size (and hopefully thought-provoking) read.

What are the important limitations of the previous work?

  1. Previously, the research only looked at either traditional software studies digital labour approaches, or the industrial devOps research which deals with the uncritical view of software as the means to an end. Therefore, only looking at either the value dimension of labour and its critique, or the technical inquiries into the optimisation of work. The downside of the former is that it is positioned to miss the difference high-complexity production has with low complexity (eg, the problematics specific to software production). The downside of the latter is that it lacks the tools for critical inquiry and is driven by the opportunities for optimisation.
  2. Methodologically, the existing research traditionally falls on either the ontological or epistemological side of looking at software production. This means either looking at the antagonism between the classes, or the organisational design which interprets the market reality as a given.

The general limitation of the focal theories I use (Lury, Barad, Boisot, Magnani) is that they do not talk specifically about DevOps, eg, my project applies the methods previously used in other spheres to high-complexity production.

The cultural theorist Celia Lury theorises problem space and epistemic infrastructure but does not zoom on the relations of production in the same way as, for example, Simon does. The philosopher Karen Barad theorises the diffraction and queer performativity principles but does not look at the impact these principles have on operations. The management scholar Max Boisot cares deeply about the cognitive science of knowledge distribution but does not go far enough into the software production field to understand how it impacts high-complexity production. The philosopher of science Lorenzo Magnani is primarily interested in logic rather than in cultural or organisational studies.

What were the limitations of your work, and how did you overcome them? Can you reflect on the strengths and weaknesses of your research design?

Perhaps paradoxically, I did not have a goal to overcome my limitations, but on the contrary, always sought to maintain them, because working with the limitations helped me to keep my work focused. Such limitations were linked to the specific organisational setting where I was carrying out my research. This meant that I had encountered a lot of things I was writing about, however, some things were out of the scope, - for example, at work there were no established routines for user testing, large-scale information architecture initiatives, business analytics or data-driven decision making specifically linked to the product. Such limitations, however, allowed me to concentrate my efforts on production methods, and on developing my research methodology.

If I were to rewrite my research now, I would narrow down its scope and focus specifically on queer performativity of software. This notion seems key to the rest of this research, so it makes sense to start from the beginning and establish the roots of queer theory in software studies as the affirmative mode of critique, and clarify its potential as a research method (see the previous ACD piece for more details and the two-part post about it on Medium: part 1, part 2). Then I would methodologically apply it to study software as simultaneously as product and service, perhaps with less accent on systems theory and more on the differences between production and distribution.

What is your thesis (i.e. your argument and your position, the answer to your research question)? Explain your thesis in two minutes.

In one sentence:
My argument is that to overcome complexity, software systems have to be approached as queer performative phenomena.
The elevator pitch:

My dissertation, ‘Software Complexity: Towards a Distributed Governance of a Production System’, examines the effects of software complexity on governance in IT firms and software production generally. Specifically, it evaluates the recent trends in development operations (DevOps), such as continuous delivery, disruption-based workflows managed via the support tickets and the distributed practices of audit. I combine complexity management and cultural studies, - specifically, case study research, queer theory and compositional methodology, to inquire into high-complexity production. I found out that there is a valorisation tendency that comes from the profit-driven side of firms that tend to increase the complexity of software systems to expand capital circulation. This trend makes it difficult for organisations to maintain control, and makes projects more costly, increasing software complexity where it could otherwise be avoided. I conclude that approaching software as a queer performative phenomenon creates a new outlook on technology that does not promote its antagonistic relationship to either markets or organisations, creating a possibility of designing teams orthogonally to the complex force of computational processes. The scholars on the Marxist side of the debate study software in terms of antagonistic relations between social classes, and the organisational theorists argue for creating effective technological solutions. My research, however, opens the possibility of looking at software as an active player in the ecology of production, which creates a new important outlook on the cultural study of the DevOps-related professional spheres.

Next week, I will continue this and write about my contribution to knowledge, case studies, my understanding of methodology and the extension of my research into a broader programme.

← Three Reasons Why Computational Art May Be Another Kind of Software

// SUBSCRIBE

Get the Daily by email

Every daily note and weekly guide, in your inbox. No spam.