Review of Management, Labour Process and Software Development

Barrett, R. (Ed.). (2004). Management, Labour Process and Software Development: Reality bites. London: Routledge.

Management, Labour Process and Software DevelopmentManagement, Labour Process and Software Development is a collection of essays that are simultaneously broad and narrow. The included essays are all broadly sociological in approach—some qualitative, some more quantitative—and cover a relatively short period of data collection. As Barrett notes in her Introduction the collection was assembled from independent studies conducted in late 1990s and early 2000s, and brought together during the 2001 Work, Employment, and Society conference in Nottingham. As Barrett and others are roughly aware of, the dot.com boom and bust occurred during this period which at the very least colours the analyses, and potentially invalidates them. The topic is mentioned, but no author seems to take its unprecedented impact into full consideration, perhaps because there is a desire to salvage their work, or perhaps because they dismiss the notion that the time was unique. Despite the unfortunate timing (or at least unfortunate in the sense that no author engages with the situation at hand), the collection is invaluable for better understanding software production.

After Barrett’s Introduction, Philipson offers a very short but useful history of software, starting with Babbage and running up to the contemporary. Barrett argues that this forms the bedrock for the other authors to work on, and she is right. The amount of detail Philipson is able to pack in to the survey is impressive, and while most of the survey information is already well known, some is seemingly new, e.g., Philipson offers a helpful bit of analysis of Grace Hopper’s contribution to modern compilers, noting that Hopper’s development was (while still important), somewhat different from modern usage.

Given the sociological framing it is no surprise that common sociology of work authors are quoted heavily, with nearly all authors citing Friedman, Braverman, and Burawoy. Castells makes a surprising leitmotif as many authors grapple with his suggestion that software developers will become the aristocracy of the future; most authors conclude that Castells’ prediction is, so far, quite untrue. The contrast is to be found in Taylorist and Fordist modes of production, but here too, most authors deny that software developers are labouring on a factory line.

So, the result is somewhat measured—with developers enjoying time flexibility, holding some allegiance and commitment to work, but constantly looking for new skills and opportunities (so no Taylorist de–skilling). Software developers are occasionally managed by direct control, but a subtle hand is necessary, especially in financial boom times when workers have more autonomy; instead, “shadow production”—comments, builds, and documentation—is used to control workers in a secondary fashion. Most of the work of developers is analytical, and many authors deny that even routine aspects (such as bug fixing) constitute a de–skilling or assembly line process, since the developers never encounter the same situation twice (and thus must always be thinking). Andrew, Lair, and Landry argue that because structuration is involved in craft and assembly line production it is not a hallmark of factory production, so even through structuration is present in software development it does not constitute factory production. Andrew, Lair, and Landry see standardization as the test for factory production, concluding that because software engineering methodologies are used more like a roadmap than a technically–mediated production environment, standardization is minor in software production. Andrew, Lair, and Landry do make an exception for CASE (Computer Aided Software Engineer) tools, but they see these as specialized tools that enhance a software developer, rather than de–skill them. As to be expected given the methodology, these descriptions and conclusions portray a highly descriptive picture, and seem to ignore the considerable desire for automatic, modular, and self–describing software engineering (as seen starting with the 1968 software engineering conference in Germany).