Programmers and Managers: The Routinization of Computer Programming in the United States

by Philip Kraft

Norbert Wiener, perhaps better than anyone else, understood the intimate and delicate relationship between control and communication: that messages intended as commands do not necessarily differ from those intended simply as facts. Wiener noted the paradox when the modem computer was hardly more than a laboratory curiosity. Thirty years later, the same paradox is at the heart of a severe identity crisis which con fronts computer programmers. Are they primarily members of "management" acting as foremen, whose task it is to ensure that orders emanating from executive suites are faithfully trans lated into comprehensible messages? Or are they perhaps sim ply engineers preoccupied with the technical difficulties of relating "software" to "hardware" and vice versa? Are they aware, furthermore, of the degree to which their work whether as manager or engineer-routinizes the work of others and thereby helps shape the structure of social class relation ships? I doubt that many of us who lived through the first heady and frantic years of software development-at places like the RAND and System Development Corporations-ever took time to think about such questions. The science fiction-like setting of mysterious machines, blinking lights, and torrents of numbers served to awe outsiders who could only marvel at the complexity of it all. We were insiders who constituted a secret society into which only initiates were welcome. So today I marvel at the boundless audacity of a rank out sider in writing a book like Programmers and Managers."

118 pages, Paperback

First published July 18, 1977

Reviews

[André · Rating 4 out of 5]

VERBILLIGUNG DER PROGRAMMIERARBEIT IN DEN U.S.A., 1977: "MUCH OF THIS MANAGEMENT LITERATURE IS NOT VERY FLATTERING TO PROGRAMMERS"

Ende der 70er Jahre, nach Sichtung der wenigen Studien über Programmierarbeit, die fast ausschließlich für Manager geschrieben wurden, stellt der US-Soziologe Philip Kraft fest, dass Manager die Arbeit von Programmierern nicht richtig einschätzen und kontrollieren könnten – sie gäben die Kontrolle unfreiwillig an ihre Programmierer ab, weswegen "most serious and thoughtful work of management researchers (…) are concerned primarily with ways of arranging people to make them amenable to management influence."

(Arbeits-)Wissenschaft im Kapitalismus als eigene Sphäre – also gesondert von der materiellen Produktion und den Arbeitern – gibt Arbeitern nicht nur die Kriterien ihres Handelns vor, sie sind als Kriterien des Kapitals auch gegen Arbeiter durchzusetzen. Alle Vorgehensmodelle sind aus Managementsicht gedacht und formuliert… Kraft entdeckt in seinen Interviews mit Programmierern, dass sie kein adäquates Bewusstsein davon haben, dass und wie sie als Berufsgruppe "amenable to management influence" für o.g. Kriterien gemacht würden, schlimmer noch:

"Relationships, for example, between a programmer and a manager were almost viewed as personal ones, rather than as part of an overall structure (…) It would not be correct to say, however, that programmers as a group had no overall perspective of any kind. They did and, not surprisingly, it closely resembled what their managers told them was the case. I was astounded by how routinely and without much objection programmers accepted their manager's point of view, although it came nowhere close to accurately describing the programmers' real situation."

Bemerkenswert ist, dass Kraft ein arbeitssoziologisches Buch für Programmierer schrieb. Er identifiziert vor allem Disziplinierungs- und Deskilling-Techniken zur Verbilligung der Arbeitskraft, die übrigens Karl Marx schon in seiner Kritik an Adam Smith zur fehlenden Unterscheidung zwischen gesellschaftlicher Arbeitsteilung und der Arbeitsteilung in Betrieben erkannte. Der Fragmentierung (Modularisierung) von Programmierarbeit in vereinseitigte (spezialisierte) Jobprofile, meist vereinfachte, geringer entlohnbare Standardaufgaben für die "Hands" und in einige wenige, komplizierte Aufgaben für die "Heads" entsprach (entspricht) auch die Institutionalisierung der IT-Ausbildung: Dual- bzw. betrieblich ausgebildete Codierer und Anwendungsprogrammierer bzw. Fachinformatiker einerseits und teure, akademisch ausgebildete Systemprogrammierer und -analytiker bzw. Software-Engineers oder Computer Scientists andererseits.

Krafts 132 Seiten umfassendes Buch aus dem Jahr 1977 ist ein kurzweiliger, arbeitssozialgeschichtlicher Einblick in das Leben von Programmierern der späten 40er Jahre (Stichwort ENIAC und Computer-Frauen) bis zu den späten 70ern (Schwerpunkt). Unklar war mir beispielsweise, dass die meisten Programmierer der U.S.A. in firmeninternen Kursen ("von der Straße weg") statt an Akademien ausgebildet wurden – als Berater und Support für die eigentlichen Produkte: die Maschinen. Software als separates Produkt gab es ja erst Ende der 60er. Man findet hier auch Details zum Closed-Shop-Betrieb in den 60ern (Programmierer durften keine Maschinen mehr bedienen, Abspaltung in "Operatoren").

1970 Census USA:

Comp. Programmers Male: 123861
Comp. Programmers Female: 39181 (24%)
Comp. Systems Analysts Male: 92922
Comp. Systems Analysts Female: 14668 (14%)

[Jan D · Rating 4 out of 5]

This was a fascinating read, also in the light of which of the changes did happen and which not. It is also quite readable (although a bit dry) and short (120p). Kraft suggests that programming is more and more routinized (in 1977) by managements’ successful attempts to make it cheaper and programmers more controllable. Interestingly, engineering traditionally often collaborated with management to standardize and simplify tasks (p20) and thus programmers also collaborate with management to make themselves obsolete (a similar mechanic can be seen in Ho’s “Liquidated”).

Kraft points out that education of programmers (at least at the time of writing) was not organized by programmers themselves, but by employees and that programmers (at least at the time of writing) are split into sub-disciplines of coders, programmers and system analysts, in raising order of prestive and academization. System analysts are doing the creative and abstract work, the ones lower in the hierarchy execute. Managers work to make the people in the roles lower in the hierarchy replacable by having the specification work done by the analysts and the implementation being done in a routine and standardized way that needs minimal knowledge of context.

Kraft does also analyze the change of tools, here programming languages. From today’s point of view, it seems strange to see “structured programming” (i.e. what is commonly assumed when code is written) as a de-skilling-measure driven by management. But it makes sense, since it promises to produce code that is understandable by people who have not written it and thus allows replacement of workers (this, Kraft says); it also enables abstract specification by systems analysts e.g. in diagrams (I assume), and was aligned with interests of academics in computer science who argued for structured programming (I assume– Dijkstra, Knuth were two proponents).

Having a career and being a professional is attractive for programmers. However, Kraft says that both are defined by management. Since programming work does not lend itself to a military like command-hierarchy and promotions along it, careers are mainly justifactions for a pay raise which comes with a new title and sometimes visible symbols like better office furniture. Professionalism usually means fitting in the organizational structures that managers set up and is also used to suggest that having a union is not needed for programmers.

Kraft assumed a continued split of the profession into recognizable sub-professions for clerical (executing) and creative (specifiying) work. This is not what happened in the long run, it seems. This might be partly due to the agile movement which strongly emphasized work-in-code and eshewed abstract, upfront planning. This does not mean that there are no hierarchies for programmers, but rather than being split by sub-professions, the hierarchies are are constructed from prestige of workplace (big tech companies of consulting them is high-prestige) or whether one’s workplace is outsourcing or is taking outsourced work (often outside of US and Europe). What also did not occur is the inaccessibility of the job and its total subjugation to management’s norms. At least compared to other jobs, there seems to be still considerable freedom, maybe because of the continued demand for programmers. There are still few programmers who are unionized, but there are visible movements to change that.

At the time of research in the mid to late 1970s, the manager and their corporate hierarchies might have been the most influential group at many workplaces. However, the dominance of management has fallen in favor of investors through the 80s and 90s (see, e.g. “The New Spirit of Capitalism”, Boltanski & Chiapello). The manager is still very much a person that programmers are often annoyed with: Managers still try to controll programer’s work to a large extend and they have, unlike investors, a workplace presence. Additionaly, a few, but prominent programmers became ultra-rich, so it might have been easier to integrate programmers into shareholder-value capitalism. It might be worthwhile today to research “programmers and investors”.