I was hav­ing a dis­cus­sion today with one of my Ph.D. stu­dents about exam­ples of human­i­ties style, con­cep­tual, crit­i­cal analy­sis work in the domain of soft­ware design and couldn’t think of many exam­ples. Cer­tainly there’s work in HCI con­cep­tu­al­iz­ing inter­ac­tion, infra­struc­ture, design. There’s also Michael Jackson’s Prob­lem Frames, con­cep­tu­al­iz­ing the soft­ware world, prob­lem world, and how they relate. None of these really felt like sat­is­fy­ing answers to the ques­tion, what makes code dif­fer­ent than other media? And what are the impli­ca­tions of these dif­fer­ences on society?

I’m not usu­ally one to get mired in such debates; most of my research is fairly prac­ti­cal and athe­o­ret­i­cal. But this one has always com­pelled me. I think its the ques­tion that dri­ves many of the ques­tions I ask as a scholar and much of what I teach.

One stan­dard answer to this ques­tion is that code dif­fers from other media in that it is rigid. Often­times, peo­ple describe dis­tin­guish it from the phys­i­cal world by describ­ing it as dis­crete or binary, where other media are fluid and con­tin­u­ous. The prob­lem with these char­ac­ter­i­za­tions of code is that they aren’t use­fully explana­tory or pre­dic­tive. If code is rigid, what does that say about people’s inter­ac­tions with it? That they will be sim­i­larly rigid? In what way? Peo­ple will strug­gle to do what they need to do when they need to do it because the media will not allow it? How is that dif­fer­ent from not being able to write on paper because of the mois­ture in the air? Is paper not rigid in the envi­ron­ments in which it may be used?

We have to go fur­ther. Let’s go to the source: maybe it all boils down to the pre­ci­sion of num­bers. Maybe what we mean when we say soft­ware is rigid is that it mod­els the world through num­bers, most of which fail to fully rep­re­sented what they intend, or can­not fully rep­re­sent what they intend to rep­re­sent because what they intend to rep­re­sent is not one clearly defined thing. For exam­ple, any effort to store someone’s age is inher­ently wrong because it’s a con­struct that has no pre­cisely defined start­ing point, is always being updated, and is, in many cases, deter­mined socially. That a vari­able knows your date of birth isn’t really enough, because in some sit­u­a­tions, a per­son may want to present their to oth­ers in other ways (I’m below 40). What would make this rigid, then, is that the deci­sion of how to model and com­mu­ni­cate age is a uni­ver­sal one, made by a designer, inde­pen­dent of the con­text in which the age will be com­mu­ni­cated. Any par­tic­u­lar software’s way of deal­ing with age will there­fore be inher­ently rigid because the mod­el­ing of the world and its infor­ma­tion will not be deter­mined by the indi­vid­ual sit­u­a­tion in which it is con­veyed, but long before in a uni­form way. Even attempts to have the use of infor­ma­tion react dynam­i­cally to con­text will require con­text that mod­els the world in sim­i­larly dis­crete ways, ensur­ing that there are at least some cir­cum­stances in which the adap­tive tech­niques will not have enough infor­ma­tion to make the choice a human would have made.

But it’s not just num­bers. Another fun­da­men­tal part of the medium of code is branch­ing, a dichoto­mous form of deci­sion mak­ing that only leaves room for final­ity. The machine needs to know, unam­bigu­ously, what it should do next, because delay is the utmost fail­ure. How does branch­ing make machines rigid? In one sense, its not the branch­ing itself that leads to rigid­ity, but the inabil­ity of pro­grams to eas­ily change their deci­sions. When a per­son begins to walk down a path and real­izes its the wrong direc­tion, the per­son can change their mind, turn around, and walk down a dif­fer­ent path. When a pro­gram fol­lows a branch, mod­i­fy­ing this deci­sion and return­ing to a pre­vi­ous state is no sim­ple mat­ter. The designer must have antic­i­pated this need to return to a state and archi­tect the soft­ware in a man­ner that facil­i­tates this rever­sal. Just like with num­bers, it is the machine’s mod­el­ing of the state of the world, and its ori­en­ta­tion toward reach­ing future states, rather than prior states, that makes soft­ware rigid.

Other media are rigid in sim­i­lar ways. When you put pen to paper, the medium does lit­tle to allow you to return to prior states. In this case, software-based sketch­ing tools are far more flex­i­ble. But per­haps this is apples and oranges, since the paper hasn’t made a deci­sion, it’s the per­son that’s made a deci­sion. The same is true for some mechan­i­cal media. If you dent a piece of alu­minum, it’s non-trivial to get it to return to its prior state.

Both of these exam­ples con­flate the designer express­ing some­thing in the media and the per­son using the expressed thing. With soft­ware, it is the con­sumer that feels the rigid­ity of the medium; the pro­ducer of soft­ware expe­ri­ences rigid­ity in con­form­ing to syn­tac­tic and seman­tic rules. Where each of these par­ties expe­ri­ences rigid­ity has more to do with whether the pro­gram is being writ­ten or used.

Per­haps then there is some mean­ing­ful dis­tinc­tion between the medium of code and the medium of exe­cu­tion. To this point, I have largely been dis­cussing the rigid­ity of pro­gram exe­cu­tion and its rela­tion­ship to branch­ing and num­bers, over­look­ing the rigid­ity in the expres­sion of code. I sup­pose that the rigid­ity in the expres­sion of code may have some role in bias­ing soft­ware devel­op­ers into cre­at­ing pro­gram exe­cu­tions that are also rigid. For exam­ple, because it is dif­fi­cult to teach a pro­gram to make some state changes reversible, the result­ing exe­cu­tion of soft­ware is rigid in its abil­ity to return to prior states.

Obvi­ously there’s much more think­ing to do here. What are the impli­ca­tions of these con­cep­tu­al­iza­tions, as they are now? If one chooses soft­ware over some other media for facil­i­tat­ing infor­ma­tion trans­fer, one should expect that the way the soft­ware mod­els the world, and the biases and over­sights inher­ent to that model, will leak through to people’s expe­ri­ences, bias­ing and restrict­ing people’s use of the soft­ware to con­form to its model of the world. Peo­ple will rec­og­nize these biases and go to great efforts to workaround them, to over­come them, and to have them changed. No model will be per­fect because many things that are mod­eled are not well defined or must change to fit the sit­u­a­tion, and there­fore these reac­tions to soft­ware are inevitable. A sci­ence that allows soft­ware devel­op­ers to ana­lyze the lim­i­ta­tions of the mod­els inher­ent in a par­tic­u­lar pro­gram and pre­dict the reac­tions to its lim­i­ta­tions would help soft­ware teams and soci­ety bet­ter antic­i­pate software’s lim­ited abil­ity to facil­i­tate and sup­port human activity.