David M. Berry’s 2011 text The Philosophy of Software offers readers a look into the ontology and materiality of code and software in the era of Web 2.0. Using a critical, phenomenological approach, Berry’s book is useful for both world-of-code neophytes as well as those more fluent in programming. Crucial to the books’ overall orientation is the situation of code “as socio-technical assemblages that are more or less socially embedded in broader networks of social relations and institutional ensembles” (62.) Beyond a general review of Berry’s book, I am interested in discussing a fundamental theme contained within it: how do we view programmers as workers, craftspeople, or artists? In this post I explore one aspect of code as “socially embedded” assemblage, namely, the function of code and its relationship to production and labor. In particular, I am interested in interrogating the relationship between structural and ideological constraints as they pertain to code and software production.
The themes of labor and production are repeated in The Philosophy of Software. Code, as understood by Berry, is both a consumable product (one that programmers assist in creating) as well as a condition of possibility for work and production. Indeed, Berry notes the productive capacity of code itself when he suggests that code is an “action,” a “mechanism,” and an “unfolding process” which itself does work (52.) We are also reminded that code is often treated as property–and owning it “can therefore be a very lucrative activity” especially if one can monopolize a platform (40.) Thus, entities–corporate or not–have reason to keep code to themselves.
In addition to understanding code as possibly proprietary, Berry quite powerfully makes visible the production of code itself, which “costs money and labour” as well as “continual inputs of energy, maintenance, and labor to keep functioning” (61.) Here, we begin to feel out the subject position of those who program for profit or pleasure. Indeed, it is programmers perform that intellectual labor–whether paid or unpaid–which has both intellectual and economic value. Although programming is “immaterial” [rather than physical] labor within our knowledge society, capitalists [managers, etc.] seek to increase productivity and appropriate the surplus value of workers. Berry writes that “Taylorist methods” such as employee-surveillance, “modularity, object-oriented programming, [and] agile programming” functionally return “the software process into something more like a pin factory” (175.) The ideology of intellectual property rights and code-as-property further contributes to the return to Taylorist/scientific management practices. As an example, consider Microsoft’s proprietary-influenced practice of “building” its OS every day; it means that workers are not only producing but are under constant surveillance and disciplined against “breaking the build” by both peers and management (Barry himself notes this process on page 68 of his text.) Although their work is perhaps a bit more abstracted and differently-mediated than early Taylorist methods, workers/programmers are nevertheless subjected to a modified brand of scientific management meant to increase productivity and efficiency. This, in turn, may alienate the worker from her/his labor.
But, what if we think about programmers in a different way, as craftspeople or artists? The desire for productivity embedded in a capitalist ideology necessarily intersects with the structural and creative aspects of code and coding. In my view, Berry does an excellent job of demonstrating how the best programmers can operate creatively within the “precise rules” and limitations that make possible flexible, functionable, workable code (46.) That is, a skilled programmer working towards concise, “beautiful” code has to operate within “programming environments…which can be unforgiving,” (45) and which require time-intensive, diligent “proofreading” and revising lines of code over and over again. This code may be described as “elegant,” a term elsewhere used to describe code that is clever, concise, simple, efficient… The programmer, then, might be articulated alternately an aesthete, an artist, or a skilled craftsperson in order to push against the demands of a fast-moving, highly productive “industrial processing model” of code and software production (40.) Berry seems to consider this possibility when he writes about “the literary craftsmanship” of specialist software (40.) Given code and software production’s embeddedness in a system of global capital, does reframing the idea of the coder/programmer as specialist, craftsperson, and/or aesthete help to push back against problematic labor practices? If we think this way, does code serve as a specialists’ tool of the trade? Ought coding be protected or taught to the masses? What are the implications of either move?