what makes code different than other media?
I was having a discussion today with one of my Ph.D. students about examples of humanities style, conceptual, critical analysis work in the domain of software design and couldn’t think of many examples. Certainly there’s work in HCI conceptualizing interaction, infrastructure, design. There’s also Michael Jackson’s Problem Frames, conceptualizing the software world, problem world, and how they relate. None of these really felt like satisfying answers to the question, what makes code different than other media? And what are the implications of these differences on society?
I’m not usually one to get mired in such debates; most of my research is fairly practical and atheoretical. But this one has always compelled me. I think its the question that drives many of the questions I ask as a scholar and much of what I teach.
One standard answer to this question is that code differs from other media in that it is rigid. Oftentimes, people describe distinguish it from the physical world by describing it as discrete or binary, where other media are fluid and continuous. The problem with these characterizations of code is that they aren’t usefully explanatory or predictive. If code is rigid, what does that say about people’s interactions with it? That they will be similarly rigid? In what way? People will struggle to do what they need to do when they need to do it because the media will not allow it? How is that different from not being able to write on paper because of the moisture in the air? Is paper not rigid in the environments in which it may be used?
We have to go further. Let’s go to the source: maybe it all boils down to the precision of numbers. Maybe what we mean when we say software is rigid is that it models the world through numbers, most of which fail to fully represented what they intend, or cannot fully represent what they intend to represent because what they intend to represent is not one clearly defined thing. For example, any effort to store someone’s age is inherently wrong because it’s a construct that has no precisely defined starting point, is always being updated, and is, in many cases, determined socially. That a variable knows your date of birth isn’t really enough, because in some situations, a person may want to present their to others in other ways (I’m below 40). What would make this rigid, then, is that the decision of how to model and communicate age is a universal one, made by a designer, independent of the context in which the age will be communicated. Any particular software’s way of dealing with age will therefore be inherently rigid because the modeling of the world and its information will not be determined by the individual situation in which it is conveyed, but long before in a uniform way. Even attempts to have the use of information react dynamically to context will require context that models the world in similarly discrete ways, ensuring that there are at least some circumstances in which the adaptive techniques will not have enough information to make the choice a human would have made.
But it’s not just numbers. Another fundamental part of the medium of code is branching, a dichotomous form of decision making that only leaves room for finality. The machine needs to know, unambiguously, what it should do next, because delay is the utmost failure. How does branching make machines rigid? In one sense, its not the branching itself that leads to rigidity, but the inability of programs to easily change their decisions. When a person begins to walk down a path and realizes its the wrong direction, the person can change their mind, turn around, and walk down a different path. When a program follows a branch, modifying this decision and returning to a previous state is no simple matter. The designer must have anticipated this need to return to a state and architect the software in a manner that facilitates this reversal. Just like with numbers, it is the machine’s modeling of the state of the world, and its orientation toward reaching future states, rather than prior states, that makes software rigid.
Other media are rigid in similar ways. When you put pen to paper, the medium does little to allow you to return to prior states. In this case, software-based sketching tools are far more flexible. But perhaps this is apples and oranges, since the paper hasn’t made a decision, it’s the person that’s made a decision. The same is true for some mechanical media. If you dent a piece of aluminum, it’s non-trivial to get it to return to its prior state.
Both of these examples conflate the designer expressing something in the media and the person using the expressed thing. With software, it is the consumer that feels the rigidity of the medium; the producer of software experiences rigidity in conforming to syntactic and semantic rules. Where each of these parties experiences rigidity has more to do with whether the program is being written or used.
Perhaps then there is some meaningful distinction between the medium of code and the medium of execution. To this point, I have largely been discussing the rigidity of program execution and its relationship to branching and numbers, overlooking the rigidity in the expression of code. I suppose that the rigidity in the expression of code may have some role in biasing software developers into creating program executions that are also rigid. For example, because it is difficult to teach a program to make some state changes reversible, the resulting execution of software is rigid in its ability to return to prior states.
Obviously there’s much more thinking to do here. What are the implications of these conceptualizations, as they are now? If one chooses software over some other media for facilitating information transfer, one should expect that the way the software models the world, and the biases and oversights inherent to that model, will leak through to people’s experiences, biasing and restricting people’s use of the software to conform to its model of the world. People will recognize these biases and go to great efforts to workaround them, to overcome them, and to have them changed. No model will be perfect because many things that are modeled are not well defined or must change to fit the situation, and therefore these reactions to software are inevitable. A science that allows software developers to analyze the limitations of the models inherent in a particular program and predict the reactions to its limitations would help software teams and society better anticipate software’s limited ability to facilitate and support human activity.
