Revisiting Software Research (1)

MIT Press began its software research department in 2009, with editors including: Matthew Fuller, Lev Manovich, and Noah Wardrip-Fruin.

In 2022, Wendy Hui Kyong Chun, Winnie Soon and Jichen Zhu will join Noah Wardrip-Fruin to form a new editorial group. In this roundtable, they each explain why software research is still necessary today, and explain why software research is still necessary today. Ask a question, and the rest of the editorial members answer, opening up each other's vision for the department. The translation of the Q&A section of the editorial team is placed in the next article.

 Original link: http://computationalculture.net/software-studies-revisited/#fn-4933-9
Date of publication: May 2022 Wendy Hui Kyong Chun, Winnie Soon, 
Noah Wardrip-Fruin, Jichen Zhu/Wen YeV/Translator

Wendy Hui Kyong Chun:

There is no doubt that the 2009 software research series is radical and necessary. Software is so ubiquitous and important, it's unbelievable that a series like this hasn't been around until then. Since its launch, there has been an avalanche of books, series, and journals devoted to all forms of software: from platforms to infrastructure, from big data to machine learning. So why do we still need such a series and what are we going to do with it?

Software research is still so important because software is so obscure: it goes beyond the categories listed above; it touches and reshapes almost everything, and is also touched and reshaped by almost everything. Software research enables us to think in broad, or interrelated terms, and enables us to act beyond and beyond the various levels and programs. This is no accident. As I wrote in Programmed Visions: Software and Memory (published in the series in 2011), software seems to help us deal with the new media Babel, which supposedly allows us to see the vision that generates the sensible part. invisible whole. Software has become a form of enlightenment—a way of understanding an invisible but powerful whole, and the concept of software underlies its appeal. Software has become a metaphor for ideas, ideologies, and economics: cognitive science understands the brain/mind in terms of hardware/software; molecular biology envisions DNA as a series of genetic "programs"; and culture itself is set up as a The form of "software" opposed to nature is "hardware".

At the same time, software is, or should be, a notoriously difficult concept—the clarity that software provides as a metaphor should give us pause because software also breeds deep ignorance. Who really knows what lies behind our smiling interface, behind the objects we click and manipulate? Who can fully understand what their computer is doing at any given moment? Software as a metaphor for metaphor hinders the normal function of metaphor, that is, the function of clarifying an unknown concept through a known concept. For if software clarifies an unknown, it clarifies through an unknowable (software). The paradox of mastering what we don't know, through what we don't fully understand, contributes to the appeal of software rather than diminishing it. It combines the visible and the invisible, the known and the unknown, it separates interface and algorithm, software and hardware, a powerful metaphor for everything we can't see but produce visible effects, from genetics to the invisible hand of the marketplace, From ideology to culture.

The point is that software is not pre-planned. Its existence was accidental: In the mid-1940s, the engineers building high-speed computers didn't plan or see the need for software. At first, software included everything outside of hardware, such as services. The term "soft" for software is gendered. Grace Murray Hopper claims that the term software was introduced to describe the compiler, which she initially called the "newborn baby product" of the computer; Jeffrey Chuan Chu is ENIAC (the first One of the hardware engineers who worked on an electronic digital computer), he called software Frankenstein's "daughter" (hardware his son). Software as a service was originally priced by the labor cost per instruction. The emergence of software as a stand-alone thing has been closely linked to changes in business models and copyright and patent law, which have transformed software from being a non-copyrightable and non-patentable thing to being both. The business model is again driving its transition to services. Furthermore, programs exist first in biology, and as I argue in Programmed Visions: Software and Memory , these failed eugenic visions of programming the future informed the emergence of computational programs.

Thus, changes in software signal profound economic, political, and cultural changes. An almost unforeseeable thing in history, the ghostly existence of software produces and challenges understanding, enabling us to understand the world through its uncontrollable intermediaries.

The most exciting work in software studies, as evidenced by my colleague Winnie Soon's Aesthetic Programming: A Handbook of Software Studies , is to work in the vast space of software studies and through it to engage in queer theory, critique Work in Sexual Race Studies and Software Art. As mentioned above, software is always dealing with issues of gender, race, and sexuality. As this series restarts, we will focus on these core questions through work that is both experimental and theoretical.

So my question to the group is: how do we deal with "soft" in software? Also, for the first time, software is defined as everything that is not hardware, and software has moved from "baby stuff" and plugin configuration to contracts of things. How does this series address the seemingly chameleon-like qualities of software and how it relates to changes in gender and racial labor practices?

Winnie Soon :

The computer source code above (refresh.js) is considered a piece of code writing (Codework) , referring to an experimental writing genre that allows computer language and natural language, whether for human or machine reading and execution. Get weird at the same time. Writing such a manifesto is also writing a piece of software that is expressive, expressive, and executable. This turns attention to the argument that code consists of non-neutral commands, and that no syntax, names, or even punctuation are taken for granted. Using web-based technologies, including HTML, CSS, and JavaScript, web browser extensions allow a small piece of software to add features and functionality to the browser. Figure 2 shows work utilizing dynamic font types from browsing sites. #refresh: Software Studies Manifesto can be read, run, and executed as a browser extension that can interfere with browsing of any web page.

It contains two files: manifest.json (see Figure 3) and refresh.js (see Figure 1). The manifest.json is a standardized file name and file format for network extensions, and it lists some basic metadata in detail , such as name, version, homepage URL, description, and which JavaScript source file to execute. The naming of this file "manifest" has its specific use in the web technology world, which contains enabling parameters and information, as a context and configuration file for a web application. (Translator's Note: The Web App Manifest is a json file. When deploying the manifest, you can set the webpage on the home screen of the device, load the file, and let the browser open and display the webpage like a native app. See Progressive Web Apps for details. program). Such a web application form should be accessible by any web browser or web crawler. As a verb, manifest means "to demonstrate or prove something by means of a sign or action". "refresh.js" deals with the content, customization, styling and interaction of the popup (as a manifesto). As a noun, manifesto means to publicly announce and disseminate over the web, a written statement of our intentions and motivations: As editors, we want to create new spaces to engage in software practice and computing culture.

My question is: what excites you about software and software research? Since a piece of software can be highly technical, how do we critically explore the relationship between software technicality and software culture on a broader global scale?

Jichen Zhu:

We never seem to be better at making software than we are now. From augmented reality, deep neural networks, and virtual assistants to blockchain, face recognition, and the art of generative adversarial netwoks (GANs), today's software often dazzles users with new features or higher performance, right here This was almost unthinkable a few years ago. "Smart" systems become "deep" and "big" Big. IoT and Non-Fungible Tokens (NFTs) continue to blur the boundaries between physical and digital, hardware and software.

At the same time, we are becoming less aware of the software we make. More and more software stacks are required to run an application, with each layer obscuring what is actually happening beneath it. Rule-based symbolic AI gives way to statistical machine learning models trained from massive datasets. (Annotation: The former does not require training, does not have a large amount of data, and simulates the knowledge and judgment of experts through rules. The rules are formulated by people and have high interpretability; and we cannot fully understand the basis for the latter decision.) As a result, even technical experts, It is difficult to fully understand these black boxes. Economic interests, rising online geopolitical threats, and nationalist protectionism are all putting pressure on software developers to keep the software ecosystem more closed.

While in theory we can make software do anything, in practice we become less confident about what to do. The new wave of human-computer interaction is shifting away from the clearly defined community of practice and the traditional engineering culture it inherits. The researchers commented that the field currently faces "ontological uncertainty, epistemological proliferation, and ethical conundrums." For example, focusing only on immediate user satisfaction has led to widespread long-term (single) concerns like Filter Bubble. How do we evaluate software products to account for vertical and social effects? Self-driving cars have turned the ethical Trolley Problem into a reality; how should designers of car control software handle these decisions? : When a collision is unavoidable, how does the autopilot program choose the direction of travel or collision).

What technological future do we desire? This is as much a question of technical design as it is a philosophical, ethical and political one. It requires both a critical analysis of existing software practices and a reimagining of future possibilities.

Programmers, UX designers, HCI practitioners, and all software makers: that's why you need software research.

The most important question to me is: How can the books in this series help expand the insights of software research to inform the production and design of software critical?

Noah Wardrip-Fruin:

I believe our best hope for software is complete intellectual promiscuity.

Understanding the specific dangers of algorithmic regulation requires a deep dive into software that can only be understood in conjunction with disciplines like mathematics and critical race theory. To understand how social networks shape community, identity, conspiracy, and hate speech, we need to combine tools from fields such as sociology, psychology, and human-computer interaction with tools from fields such as network analysis and artificial intelligence. In order to understand the possibilities and ideologies embedded in algorithmic media forms such as computer games and interactive storytelling, we must draw from fields such as media, visual, and literary studies, while also examining such algorithmically embedded media Mechanisms and assumptions, the towers of abstraction with contingency to which they are attached. In order to find new ways of making software, we must bring together ways of working, from participatory, critical design to campaigners and the free software community, to understand our projects and evaluate our work in new ways so that Do is more likely to be queer and decolonizing than Taylorism.

The only problem, of course, is that we have organized the world for this way of thinking and making. For example, we lack degree programs, intellectual gatherings, exhibitions, and publishing spaces that welcome (or even tolerate) this kind of work. My hope is that the restructured software studies department can be an alternative home and support for those who pursue an understanding of software properties with a non-disciplinary, eclectic approach, which is what our world is all about today. needs.

For me, the most important question is: How do we find and support such authors or groups of authors? How can we help shape the environment so that people, especially junior researchers, are more likely to take on the time and risk that these jobs require ?