Networked Modes of Production: Source Code Control as Post-Fordist Factory

 

Isaac Quinn DuPont

[draft] 2011

 

Written for RFC: Request for Critique at University of Los Angeles, October 27, 2011. Los Angeles.

(NB: This is a vignette of a much larger research project, and written for an academic, but multi-disciplinary audience. References are mostly omitted, but available upon request. Please request before citing this unpublished work.)

American production

Historians looking back may well decide that the century of technological enthusiasm was the most characteristic and impressively achieving century in the nation’s history, and era comparable to the Renaissance in Italian history, the era of Louis XIV in France, or the Victoria period in British history. During the century after 1870, Americans created the modern technological nation; this was the American genesis. (Thomas P. Hughes)

Once industrialization settled in, the next corporate phase of American history took place. As US President Calvin Coolidge said “the business of America is business”, echoing de Tocqueville’s comment that “American’s are constantly driven to engage in commerce and industry”. Although the post-Civil War conditions were, considered by many, a kind of “economic hothouse” and spurred by many exogenous forces, such as slavery and ready access to environmental exploitation, technology surely played its part (characterized as “an indispensible factor”). Eventually, through mechanization and organizational inventions, the US form of productivity developed in to what has been called the “American system of manufacturing”. David A. Hounshell observed that this approach combined “the idea of uniformity or interchangeability of parts… with the notion that machines could make things as good and as fast as man’s hands, or even better.” By 1870 US production was in full swing as factories developed, power-driven machinery replaced human and animal muscle, communications technology regularized and sped the flow of information, a full-blown market economy developed, and population rapidly increased and moved in to cities and towns. Once F.W. Taylor published Principles of Scientific Management in 1911 capitalists and entrepreneurs started giving new application to old ideals. Oliver Evan’s automatic flour mills that served as productivity ideals from the 1780s were suddenly moving beyond applications in continuous flow production, and with Henry Ford, in to mechanical production. Ford’s constant improvements, charted as successions in the development of new factories: from the old Piquette Plant to Highland Park Ford Plant, and finally its zenith in production at River Rouge Plant. At the same time organizational inventions were coming out of General Motors under the helm of Alfred P. Sloan. These developments increased the rationalization of work. Rationalization is:

the introduction of predictability and order—machinelike order—that eliminates all questions of how work is to be done, who will do it, and when it will be done. The rational factory, then, is a factory that runs like a machine.

In 1934 Lewis Mumford described a shift in the development of humans and technology. Mumford describes an “eotechnic” phase of water, wood, and handcrafts that served as cultural preparation for the industrial era, which arrived as the “paleotechnic” world of steam, iron, and factories that I just described. Next came the “neotechnic” phase that was developing as he wrote. This era was characterized by “mathematical accuracy, physical economy, chemical purity, surgical cleanliness”. Even Ford’s successive factory developments became cleaner and better organized, although it was really with Norbert Wiener’s Cybernetics that the neotechnic age came to fruition. Mumford anticipated Wiener’s advances in feedback and control, suggesting that “the specific triumph of the technical imagination” came with the ability to disassociate the world, and to represent it with symbols. Weiner argued that “the problems of control engineering and of communications engineering were inseparable”. Control is a central thread to the story I want to present today. Although I will not concentrate on it, my conceptual underpinning is Foucauldian, and as such control, as a form of power/knowledge is important. So important, in fact, I insist on calling this set of technologies “source code control”. This notion of control may prove more important than cybernetics ever forecast, because it cuts across not just the operation of software, but also the production of software.

Software development or software production?

This brings us to the issue of how software gets produced. In the vernacular, people tend to speak of software development, rather than software production. Even the word programming, with its action-orientation seems to be losing ground over the last decade or two. The issue of how to speak about how software gets made is central to a debate within the historiography of software engineering, where “software engineering” refers to the set of tools and techniques for the efficient, timely, and organized production of software. While there are some shades of grey to the debate, the main tension is between software engineering as a science—possibly an applied science, or software engineering as mechanical or industrial engineering. With this debate, we see software engineering tools as central actors in the debate. Can we speak of a computer science, or as a mode of production? Obviously, computer science is the popular model, but this doesn’t mean that vestiges of a forgotten past aren’t still present in how software gets made.

When you ask most software programmers how software gets made, they tend to believe in a kind of “idealist” theory of programming, in which everything exists, often abstractly or in a Platonic space, where programming is just the science of writing down these ideals. Just as a scientist inscribes nature, that already exists, a “computer scientist” (a programmer) represents pure ideal forms. There’s an element of truth and seduction to this view: computers are the first tool to mechanize and experiment with ideas, truth, and knowledge. But, a different conception is possible, a social constructivist, or in another sense, a labour model of programming. This conception has natural alliances with politics, both hegemonic and counter-hegemonic movements.

David A. Mindell argues that “the histories of computing that focus solely on computers as conceptualized by mathematicians are incomplete. It is wrong to suggest that computers arose first as logic machines and then took on cybernetic or connected characteristics. Ideas of communications, systems, and human interaction were present from the early days of computing.” Mindell argues that “mathematicians of course played critical roles, as did the business machine industry,” but he wants to situate the history in the conceptual space of control.

Without getting into all the details I’ll merely highlight the historical debate, and then move on to other issues. Michael Mahoney offers a kind of pluralist position, suggesting that depending on your historical focus and timeline, different conceptions of software engineering came to be. Mahoney also provides the most vivid and studied look at the history of software engineering, so we’ll take our lead from him. Mahoney locates the genesis of software engineering in the 1968 NATO-sponsored “Software Engineering” conference in Garmisch, Germany. With the ’68 conference we see the connection of a number of different conceptions of software and its production come together. Before the late 1960s software was problematic to develop, and characterized by a so-called “software crisis”. This software crisis resulted in extreme labour shortages, due in part to inadequate methodologies for training and production. According to Mahoney, the conceptual backdrop for all approaches to resolving the labour shortage was already at the heart of the computer—Turing’s self–programming machine. The ability of the computer to read its own tape, in effect, “self–program” allowed programmers to automate their own jobs. As it turned out, this proved extremely difficult in practice, and the degree of automation for software production is still underwhelming. Conceiving of a computer as a universal Turing machine was, and still is, an academic conception, but before the commercialization of the ‘60s this view had considerable sway. Interest in these analytical models faded as it was realized that the problems were too diverse and too numerous for a single mathematical model, and worse still, those pushing for software engineering as an applied science soon realized that the most pressing and difficult area is production in a “economics–driven context”.

Mahoney describes a socio-technical extension in this process: “[1] the use of programming environments to constrain the behaviour of programmers and [2] the extension of programming systems to encompass and ultimately to automate the entire software development cycle.” These environments were “[i]ncreasingly… viewed in terms of disciplining programmers.” Also described as “supportive” environments, they were developed in fields as broad as “mathematics and computer science[,]… industrial engineering[,] and project management”. The considerable effort to develop these environments took a succession of forms, for which Computer-Assisted Software Engineering (CASE) tools are perhaps the best example. During the ’68 conference F.L. Bauer called for form of “computer surveillance” that in its original logic was innocuously used to ensure productivity compliance. Later, R.W. Bemer’s position paper from IFIP echoed the desire for computer surveillance, and saw it as integral to his portrayal of the “software factory”. Perhaps more than anything, the factory environment offered managers the ability to constrain and surveil workers. Drawing a parallel, Mahoney notes that:

Ford did not have to concern himself about how to constrain workers to do things in ‘the one best way’ [a stock tenet of Taylorism]. His machines of production embodied that way of doing things; the worker had little to do with it. The same was true of the assembly line itself.

Since the early 1900s engineers had been trained for managerial duties in preparation for mass and assembly line production, so once the 1968 software engineering conference separated design from implementation, programmers quickly came under the control of a technologically proficient managerial base. Management realized, however, that the culmination of efficient modes of production in Taylor’s “scientific management” and Ford’s assembly line were not suitable models for software production. These were ideals for modes of production, but they were not yet attained and to what extent the old “rules of thumb” practices could be replaced with scientific measures was unclear.

McIlroy argued during the ’68 conference that the trivial limitless reproduction of a prototype was not what the factory model brought to software production, instead certain industrial techniques carry over to software production, such as sub-assemblies, interchangeability, and machine tools. Moving from the machine shop to the factory assembly line, Bemer argues,

A factory, however, has more than human supervision, it has measures and controls for productivity and quality. Financial records are kept for costing and scheduling. Thus management is able to estimate from previous data: not so with programming management in general. Computer supervision and aid are vital, with the accent on human engineering factors so that working in the environment is both attractive and effective for the programmer.

In the end, Mahoney concludes that neither software factory techniques nor automatic programming are likely to solve the real challenges facing software production.

As software production

There is a striking fact about these dates that too frequently gets passed off as coincidence. The first NATO-sponsored Software Engineering conference took place in 1968, a year of no small importance. In fact, I argue that you can’t tell the history of software engineering without reference to the Paris ’68 events, protests at NYU, Columbia University, and so on for the next half-decade. The software crisis was prompted by the commercialization and broad demand for computing resources in all aspects of life. In addition to the abstract fears, but real responses, to the rationalization and mechanization of thought and growing technocracy, there was the fear of deskilling and replacement of labour by computers and computerized tools. What we see in this exogenous history is the dialectic of “the system of American production” and the protests against machines. Rather than simply a rational and natural development, the system of American production contains many contingencies, and through tools such as source code control human cognition can be captured and pressed in to the service of capital. The fears of the late ‘60s were not so much of an abstract artificial intelligence, but instead were characterized by labour. Internally the fear was that the labour to produce software would be replaced by automatic programming, but externally, and more significantly, the fear was that software replaced workers and democratic principles. Although rarely written in to history by software programmers during the late 60s and early 70s, Forrester offers this sentiment in 1967:

“The engineer who at one time was the educated and elite leader in matching science to society is fast becoming just another member in the industrial labor force.” (Forrester, 1967)

It appears, although the empirical evidence is scant, that software programmers have not been subject to deskilling. It is undoubtedly true that some jobs have been deskilled by software, and many have been replaced, but software production has largely been immune to this trend. The pervasive opinion within software development is that software engineering, and CASE tools in particular, merely free the software programmer from the drudgery of running tests, launching builds, optimizing code, etc. In the late 1600s Leibniz described this impulse:

It is unworthy of excellent men to lose hours like slaves in the labour of calculation which could be relegated to anyone else if machines were used.

What this description highlights, however, is that software production does entail labour. And, once labour is an issue, other forces come into play that are largely independent of the concerns of software developers.

As Andrew Feenberg notes in Questioning Technology, modern political theory subsumed technological activity under the economy and did not raise the same kinds of questions about rights and responsibilities. He notes that common sense instrumentalism treated technology as a neutral means, requiring no particular philosophical explanation or justification.  Feenberg argues that what he calls “substantivism” became a new popular culture of technology in the ‘60s and ‘70s. By substantivism he means,

modernity is also an epistemological event that discloses the hidden secret of the essence of technology. And what was hidden? Rationality itself, the pure drive for efficiency, for increasing control and calculability.

We see something like substantivism in Max Weber’s dystopian conception of an “iron cage” of rationalization. Or, in Marshall McLuhan’s phrase, “technology has reduced us to the ‘sex organs of the machine world’”. Feenberg argues that the attitude towards technology shifted in the 1960s, where early enthusiasm for nuclear energy and the space program gave way to a technophobic reaction. But, it was not so much technology itself as the rising technocracy that provoked public hostility. And by “technocracy” Feenberg means “a wide-ranging administrative system that is legitimated by reference to scientific expertise rather than tradition, law, or the will of the people.”

In terms of historical lineage, source code control systems were in existence during the 1968 software engineering conference. The most sophisticated of these, going beyond the usual technique of swapping coloured correction punch cards to manage software variants, was IBM’s CLEAR-CASTER. While CLEAR-CASTER was in use from at least 1968, it was in 1972 that Marc Rochkind developed SCCS within Bell Labs, and this set the structurization  and mainstreaming process in motion. SCCS was initially developed on punch cards, for use with punch cards, but quickly moved on to so-called “online”, terminal-based, interactive systems. By 1975 SCCS was in use outside of Bell Labs, and other source code control systems were quickly developed.

The ’68 May Events in Paris where characterized by student and labour protests. These protests were not just against capitalist control of the economy, but against more general technocratic control of society. They argued for a revived form of democratic “self–management”. For example, one leaflet argues,

This is why the ultimate weapon of the workers struggling for revolution is DIRECT MANAGEMENT of their means of coordination and production.

In the 1960s the universities were also being reorganized along a model of a so–called “knowledge factory” (a striking note of familiarity to our contemporary situation). This factory is supposed to supply the technocratic hierarchy with its members, and it is also the place in which the new scientific knowledge used by this hierarchy is first discovered. The students in France were centrally concerned with their role and participation in this factory, and their supply of the hierarchy. In the United States and Canada the concern was the same, but we also see evidence of direct antagonism against computer systems. During the ‘60s punch cards were still the common form of mechanically–readable storage and many technocratic processes employed this technology. These cards came to stand as a symbol for alienation and the mechanization and rationalization of society. The University of California administration used punch cards for class registration, and incoming freshmen were given advice not to “fold, spindle, or mutilate his IBM card”.  The students begun actively resisting the use of punch cards, with one Berkeley student pinning a note to his chest: “I am a UC student. Please don’t bend, fold, spindle or mutilate me”. Just as anti–war protestors burned their draft cards, students burned (or imaginatively altered) their punch cards.

The development of source code control was part of this technocratic expansion, as well as a response to the potential opening of new modes of production. As some of the early computer pioneers recognized, a post–Fordist technology such as the computer has considerable liberatory potential, but this directly challenges hegemonic forms of power and control, so, concerns such as the “software crisis” required tangible answers to ensure that machines continue to, in the words of Marx, convert human labour in to capital.

Once computing systems became interactive, that is “online”, source code control constrained the software programmer even further. When we trace the history of source code control technologies through time, up in the early ‘80s with RCS and CVS, and then other popular systems like Subversion and finally Git, we see features added, e.g., client–server architecture to increase panoptic surveillance, the addition of “management dashboards”, integration with continuous and automated build and test systems, and so on, all adding to the further entrenchment of rationalized, technocratic, and alienating modes of production. The logic of software engineering is so entrenched that the decision to use or not use source code control is no longer legitimate, and software programmers have to accept the constraints and salient history of their tools.

New opportunities

I’ll leave with a glimmer of hope in all this. There are obviously many issues that face software programmers (and by extension, all work and play being managed by similar tools)—such as deskilling & job replacement, anxiety and resistance to mechanization, lack of physical access/information, lack of control of speed and timing of rest and work, repetition and boredom; but rather than focus on these, I’d like to submit that we look at new opportunities, if only we can get past the path–dependency of the history of source code control. A few possibilities that need more exploring, by academics and practioners alike, include:

• Distributed Version Control Systems (e.g., Git): These systems allow private work, but are still distributed. Issues with respect to automatic forking may spell new hierarchies (both good or bad), or different ways of working  (every variant is a project fork, and inclusion back in to the main branch is requested). The use of DVCSes for open source software production holds promise, but there’s still plenty of critique of open source modes of production, and questioning to what extent they replicate existing power structures or not.

• Social source code control (e.g., Github or Social Versioning System): Github is a popular online repository that employs Git as a technology in the back–end, but the result is more than merely the sum of its parts. With the social features of Github it does seem like work is being changed somehow, and quite possibly it has nothing to do with Git (it’s likely that a Subversion–hub would have similar transformative qualities). A much less popular, and much more radical alternative is the Social Versioning System (SVS). This system is developed by a team of academic computer–art/software developers specifically to challenge modes of production and interaction with software. SVS permits livecoding, where interpreted code is changed on the fly, e.g., game objects are not just interactive within the game, they can be reprogrammed as the player desires.      
• Ubiquitous version & variant control: Version and variant control has increasingly become ubiquitous and consumer friendly. Wikis have permitted roll–back versioning for quite some time, and the ill–fated Google Wave included extensive live replay and versioning of text documents. Google Docs, Dropbox, and now even Mac OS X include simple version management. These advancements bring new challenges and new opportunities. E.g., about a year ago a journalist wrote an entire article using a Google–wave–like product that displayed his writing and (saliently) his thinking process. He argued that the future of teaching how to write could be revolutionized by such technologies, since no longer would a student be constrained to read the beautiful prose of a Melville or Hemmingway, but instead could follow its production step by step. 

While software developers are understandably hesitant to characterize their work in terms of labour, I think we should question the computer “science” model. Computers are the first devices in history to mechanize and automate thinking, and a second wave of production is possible if we recognize the labour required to perform this automation. If software is characterized as more than a science of thought—if it is political, social, constructive and constitutive—then human cognition can develop within these technologies, not from without.