Notes for Philip Kraft Programmers and Managers: The Routinization of Computer Programming in the United States

Key concepts: chief programmer team, de-skilling, electronic data processing, external programming.


Related theorists: Harry Braverman, Norbert Wiener.

Foreword

Identity crisis confronting computer programmers, whether they are managers or engineers, reflects Wiener noting conflation of commands and facts complicating relationship between control and communication.

(v) 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 modern computer was hardly more than a laboratory curiosity. Thirty years later, the same paradox is at the heart of a severe identity crisis which confronts 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 translated into comprehensible messages? Or are they perhaps simply 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 relationships?
(vi) To my knowledge, this is the first study written from the perspective of programmers themselves.

Acknowledgments

Introduction
Programmers, managers, and sociologists

Initial impression that programmers were marginal people not fitting engineer stereotypes, and many were women.

(1) From the start they struck me as marginal people. They did not, for example, fit neatly into the stereotypes that are commonly applied, however unjustly, to engineering workers as a whole. They did not look like engineers are supposed to look (crew-cuts, narrow ties, penny loafers, etc.), nor were they taciturn and awkward around nonprogrammers. They did not appear to be particularly conservative, either politically or socially. Many were women.
(2) It seemed instead to be a peculiar case of an exotic occupation whose obscurity was penetrated only by those in whose interest it was to do so, i.e., managers.

Four literatures of management researchers on programmers: moral uplift, psychological profiling, industry statistics, ethnographies.

(2) By contrast, management researchers have show considerably more interest. . . . More accurately, they have compiled four distinct literatures. These first is a version of the old Norman Vincent Peale/Dale Carnegie brand of moral uplift.
(3) The second kind has to do with what is usually called psychological profiling.
(3) A third kind of management writing is of more immediate interest. It consists of the information about programmers' salaries, their distribution by job categories, by industry, and so on.

Importance of political, social relations of the workplace highlighting power, domination, subordination.

(3) The fourth and last major category is made up of the work of highly experienced programmers who have spent considerable time analyzing the organization of the programming workplace. These writings are fascinating for more than their technical content; the work of F.T. Baker, Harlan Mills, and Gerald M. Weinberg, for example, is also important politically. This is a crucial and often misunderstood point. The social relations of the workplace are arrangements of people which affect more than just efficiency and productivity. They are also relations of power, of domination and subordination.

Most literature on programmers written by managers with the concern of imposing discipline rather than writing better programs.

(4) Put another way, management literature on programmers displays a general concern with developing techniques to get the people managers manage to do what they are told, not simply how to write better programs. It tends to concentrate on ways of figuring out how to predict who can do what kinds of programming jobs (“personnel selection”), how to get programmers to fit into the structure of the organization (“getting on board” or, occasionally, “seeing the Big Picture”), and, all things being equal, to get as much work out of them as possible (“developing motivation” and “acquiring the right attitude”).
(4) Finally, it must also be said that much of this management literature is not very flattering to programmers. . . . The major difference is that while such stereotypes have been used to justify social sneers or to ignore programmers altogether, managers have used similar stereotypes to create techniques to advance their own very specific ends. . . . A common managerial position is that, left to themselves, programmers “would design a system for the computer not for the user.”

Expanding the data base

Programmer manager relationship often viewed as personal rather than organizational, with surprising compliance to manager opinion.

(6) Relationships, for example, between a programmer and a manager were almost always viewed as personal ones, rather than as part of an overall structure which individuals were inserted into or removed from as the requirements of the organization demanded.
(6) I was astounded by how routinely and without much objection programmers accepted their managers' point of view, although it came nowhere close to accurately describing the programmers' real situation.

Manager interviews revealed programming work being organized like any other work in corporate bureaucracy.

(7) The interviews of managers in particular made me aware of just how much like other work programming was being organized and structured. . . . The development of “job standards,” the emergence of increasingly specialized job descriptions, the obvious efforts to reduce overall job skill levels through extensive use of canned programs, structured programming, and hardware innovation—all of these things were, to a social scientist, straightforward efforts to make the social relations of programming like, say, those of the machine shop of the secretarial pool of the drafting room.

Programmers seemed unaware of organizational processes; contrast to FLOSS stereotypes of bazaar revolutionaries.

(7) Programmers, for the most part, seemed unaware of this process and generally believed that they occupied special, unique positions and enjoyed the personal protection of their managers.
(8) It seemed to me, in other words, that programmers and other computer people were at a distinct disadvantage in their dealings with their managers in the matter of how their day to day existence in the workplace was to be organized.

How this study is organized
(8) In
Programmers and Managers I have proceeded from a description of what programmers do to an analysis of how managers organize programmers to do it.

A note on software scientists
(9) Their discoveries and inventions are not necessarily useful to managers unless carefully modified to meet the latter's own, very particular needs.

Structured programming as quintessential managerial selection process to deskill and control programmers that is not inherent in the technology itself; related to Feenberg underdetermination.

(9) Structured programming is perhaps the most striking example of this managerial selection process. . . . I have suggested that managers use structured programming to de-skill and control their programmers. Yet, there is nothing inherent in the principles of structured programming—at least as put forward by people like Edsger Dijkstra, David Gries, and many others—which suggests that its developers are concerned with anything except making the writing of programs a more clear-headed and self-conscious undertaking than it presently is.

Electronic data processing managers, not scientists, decide how scientific innovations are applied.

(9) Whatever the intentions of software scientists, it will be edp managers, not scientists, who decide the manner in which scientific innovations will be applied to the problems of profit-making and employee control.


1 Computers and the people who make them work
Introduction

(11) What products we buy and therefore what jobs we will have, whether there will be tight money or inflation or both, whether the government will send troops to some distant corner of the globe, are decisions some people have made or will make on the basis of information processed for them by computers.

Aura of magic surrounding computers and edp in general.

(12) There is, however, still an aura of magic surrounding computers, and electronic data processing--”epd”--in general.

The division of labor in programming
(14) The problem is that the work of providing instructions to the computer is no longer done only by people called computer programmers.

Separation of work in modern programming.

(16) In spite of the lack of clear-cut boundaries between the software suboccupations, the divisions point to what may be the most important aspect of modern programming: the work of head and hand have been separated and given over to difference people.


The computer and how it grew

External programming.

(23) Changes in the operating “program” were made by adjusting a given combination of switches and physically rearranging special self-contained circuits called “plug boards.” These were circuits permanently wired to perform specific calculations such as square roots or cosines and were “plugged in” or removed as needed. The entire cumbersome process was known as “external programmingsince the instructions could be changed only by physically moving the plug boards, control switches, etc.

The stored program computer

Symbolic code languages relieved applications programmer of having to write or know machine language by transferring tasks to other programmers.

(24) The development of symbolic code languages relieved the “applications programmer” of having to write instructions in machine language, in fact, from having to know machine language or to understand much at all about the machine.
(25) The stored program computer made programming easier for some software workers only because others now had to do a much more involved and time-consuming kind of programming. . . . The more simplified the source code (or the more elaborate the computer application or both), the more complex and time-consuming were the required machine language instructions and translator.

Later developments

Microprogramming libraries of special routines in auxiliary units followed by high level programming languages.

(26) Whole “libraries” of special routines could be stored in relatively small auxiliary units and called for when needed without significantly reducing the machine's core (i.e., data) memories or slowing down the central processor. The technique, known as microprogramming, made it possible to do common processing problems (such as bookkeeping reports) by using the simplest code possible. . . . Software specialists soon developed a series of powerful “high-level” programming languages which could generate extensive and complicated machine operations when requested to do so in the most economical source code.

Separation of user and programmer

Time-sharing only radical transformation after solid-state technology.

(26) With the exception of time-sharing, the advances which came after solid-state technology, microprogramming, and so on, have been primarily on the order of refinements rather than radical transformations.

Goal of managerial control with ideal of eliminating the programmer altogether.

(27) In short, expanding applications and increasing complexity combined to require the services of people skilled in the ways computers worked rather than in the substance and content of their application. Responsibility for the computer's operation had been transferred to a new, or rather, several new, specialized occupations. The “final users”--primarily large organizations which could afford the hardware—became the employers of skilled workers, who, like some other employees, operated advanced labor-saving machines. This proved to be quite important. The desire of organization users to treat computers like other labor-saving machinery intensified the already great pressure on hardware makers to simplify the computer's use. The goal, expressed early and often in the short history of the computer, is the same as in all other engineering industries: managerial control. . . . [quoting Robert Bosak] The ultimate is to remove the programmer entirely from the process of writing operational programs. In effect, the manager would write and modify his own programs.

Producing programs left to anonymous army who have little understanding of why they are doing what they do, strengthening separation between those who think and those who do everything else.

(29) Most of the routine and tedium associated with the daily tasks of producing programs are left to an anonymous army of people who merely do what they are told, understanding little of what they do and less of why they are doing it. At least up to now, the computer has intensified, not reduced, the separation between those who think and those who do everything else, an division now beginning to separate software workers as well.


2 The organization of formal training
The engineering heritage and its consequences

Twentieth-century engineering occupations share little with older civil and mechanical; creations of their industries and employers like other raw materials used in production.

(31-32) Although it is often assumed that twentieth-century engineering occupations, including electrical engineering, are continuations of the older civil and mechanical engineering, in fact old and new share little except the titles. . . . Modern engineers, unlike their namesakes, were from their beginnings the creations and creatures of the industries which employed them. . . . They were considered by their employers to be another raw material, much as the metals or minerals used to fashion electric generators or chemical dyestuffs.

Adapting tradition

The early period: Hardware makers and in-house training

Social role of programmer understood by IBM, but training still master apprentice model.

(36) IBM, perhaps better than any of its competitors, understood that programmers trained by the company and using its machines would go out into the world carrying with them a profound appreciation of the virtues of IBM computers. . . . Their training courses, even by the standards of the electrical industry upon whose traditions they drew, were elaborate and carefully done.
(37) Whatever the differences, however, all remained structured more or less along the same master/apprentice model developed during World War Two.

The mass-production of programmers

Role of SAGE in history of software training.

(37) The Cold War had culminated in the “police action” of Korea, and in America it produced a belief in an imminent Soviet air attack. In response, the United States government authorized the most elaborate of all edp projects the military (or anyone) had undertaken up to then—the Semi-Automatic Ground Environment, or SAGE. . . . SAGE's role in the history of software training came about because barely five years after the first computer went into service it undertook to train the 2,000 programmers necessary to make the project operations.

SDC spin-off of RAND developed managerial techniques for small number of senior personnel to oversee large number of junior personnel, institutionally separating conception and construction.

(37-38) The task of doubling the national programmer workforce was given to the System Development Corporation (SDC), a spin-off of the RAND Corporation. . . . What were needed were not new techniques to help people become programmers or to help programmers improve their ability to program. Instead, what was necessary was a series of managerial techniques that would allow senior edp personnel to oversee the activities and production of junior edp personnel.
(38) In short, the SAGE/SDC program prompted the institutionalization on a large scale of the separation between the conception of a computer program and the physical task of constructing it.


Trained by future employers, not by peers as in guilds; temporarily modulated by emergence of personal computer and later floss.

(46) This must be considered the most important feature of the formal organization of software training: by and for whom it is organized. Programmers cannot claim, as do physicians or plumbers, that they are trained by their future peers and colleagues. Like other engineering workers, their training is not in their own hands, passed on from master to apprentice. On the contrary: programmer training is in the hands of their future employers, directly in the case of company schools and inhouse training, indirectly in the case of institutions which exist to service local, regional, or national employers.

Social class differences mirrored in software training.

(49) With respect to software training, it is possible to discern the emergence of a similar social division, one which channels the sons and daughters of the less affluent into low-level technical and clerical positions, while directing the children of the comparatively more prosperous to positions in the field which offer considerably more in the way of interesting work, material rewards, career opportunities, and high social standing.


3 De-skilling and fragmentation
Introduction

De-skilling is standardizing work to produce standardized products.

(51-52) Labor costs can be reduced because the work necessary to turn out a standardized product can itself be standardized. This is what I mean by de-skilling. It is a deliberate effort to transform work made up of separate but interdependent tasks into a larger number of simpler, routine, and unrelated tasks.

Tiny proportion of labor force used to make skills of vast majority unproductive.

Do autonomous technologies transfer deskilling performed by previous generations, making us collectively dumber?

(52) In effect, the skills and talents of a relatively tiny proportion of the labor force—research scientists, production engineers, systems analysts, and similar creative workers—have been used to make “unproductive” the skills of a vast majority of the rest.

The de-skiller de-skilled

Canned programs, structured programming, Chief Programmer Teams central changes making programming less complex and more routine.

(54) The fragmentation of programming into suboccupations like coding, program design, and systems analysis suggests that the industry has been able to introduce changes in the way programming is done to render it less complex and more routine.

Canned programs

Structured programming

Structured programming and modularization encourage programmers work like machines.

(57) Unlike such piecemeal approaches, structured programming offered an entirely new way of writing programs, elegant in theory and unambiguous in principle. Indeed, the principle was simple: if managers could not yet have machines which wrote programs, at least they could have programmers who worked like machines. . . . They could call only for certain kinds of information; they could ask only specified questions about that information; on the basis of the answer they received to their question, they could call for a particular machine operation (or an answer to another, approved question); when the operation was completed, they had to stop.
(58) If there are only a few pre-determined ways of ordering a program's logic, considerably less skill, training, and experience are required to grasp the major logical tools of the trade. Moreover, since the procedures are few, universal, and well-understood, one programming routine will develop much like all others. . . . Both writing and debugging are further facilitated by structured programming's logical partner, modularization, which breaks down an entire software system into limited-function, discrete units, written independently and then fitted together in a pre-determined way to form a single system.

Structured programming freed managers from dependence on individual workers and made job-based fragmentation possible.

(58) Structured programming and modularization thus achieved two long cherished managerial goals at once. They freed managers from dependence on individual high-level software workers. They also made possible for the first time a genuine job-based fragmentation of labor in programming.
(59) Structured programming, in short, has become the software manager's answer to the assembly line, minus the conveyor belt but with all the other essential features of a mass-production workplace: a standardized product made in a standardized way be people who do the same limited tasks over and over without knowing how they fit into a larger undertaking.

Chief programmer teams

CPT formalizes natural organization under structured programming, similar to surgical team.

(59-60) The CPT is little more than a formalization of the way programmer groups tend to be organized in practice when structured programming techniques are used. According to one of its most influential proponents, F. T. Baker, the Chief Programmer Team “is organized around a nucleus of a Chief Programmer, a Backup Programmer and Programming Librarian. . . . The Team in then augmented by additional programmers who produce the remainder of the code under the close supervision of the Chief and Backup Programmers.”

Programming as mass production work

Automatic regulation and supervision creates docile programmers.

(61) Canned programs, structured programming, and modularization are designed to make the supervision of software workers by managers easier and more like the supervision of other workers, i.e., by restructuring the work so that simly by doing it the worker regulates himself. The organization of the work and workplace are thereby turned against the worker; regulation and supervision become, for all material purposes, automatic.
(62) Programming, even coding, is still primarily a mind-skill and there are few hard and fast rules of behavior which managers can compare against an efficiency expert's model in order to check performance.


4 The programmer's workplace: Part I the “shop”
Introduction

The social structure of the programming workplace

Observation of three workplaces, interviews, and published sources ground workplace analysis; compare summary to more recent ethnographic approaches by Rosenberg, Takhteyev.

(66-67) The analysis of software workplace relations presented here has been derived from several sources. The most important has been direct observation of three software workplaces: a systems programming group in a large computer manufacturing company; an applications group in another manufacturing facility, part of a diversified industrial conglomerate; and the computer center of a large university. Formal interviews and informal discussions with programmers, analysts, managers, consultants, and academics provided additional valuable information. Finally, four published sources were especially useful: Weinberg, Pettigrew, Hebden, and Greenbaum.

Physical setting

Is separation of workers and machines reproduced today in datacenters and version control systems?

(68) But whatever the official reasons, separating the software worker from the machine, the machine room, and machine room employees constitutes the first and perhaps the most important of the head/hand separations he or she experiences in the data processing workplace (Greenbaum).

Different social relations typical of each suboccupation.

(70) Each of programming's suboccupations has a unique set of social relations which must be examined separately. Let's start with the bottom of the programming ladder.

The programmer's day

Programmers permitted breaks but expected to be writing code, formerly on paper, most of the day.

(70-71) Coders and programmers—and software workers generally—are spared this sort of involuntary servitude to the machine, and, whether they think of it in such terms or not, the first cup of coffee in the morning is very much a symbolic statement of this independence.
(71) Managers, according to one well-placed observer, assume that if pencil is not meeting paper, the programmer is slacking off (Weinberg). . . . Programmers as clerks, in other words, are not expected to read—or to think—any more than the immediate job requires.

The analyst's day

Analyst function as conceptual architect involves super programmer and managerial generalist activities.

(72) The analyst's role as “conceptual architect” contains elements of both the technical specialist—the “super programmer”--and the managerial “generalist,” the intermediary who works out the specifications set by the customer and which are to be met by the programmers who do the work.

Software's marginal man: The programmer manager

Programmer manager has ambiguous position.

(76-76) The ambiguity of their positions has made software supervisory employees marginal people in several respects. If technical overseers, their role makes them foremen—neither employees nor managers. They are subject to conflicting pressures from their colleagues on the one side and from conventional managers on the other. If they are primarily managers rather than technical specialists, their personal dilemma can be not simply a technical role, but a socially superior one. Yet, they come to their positions in a questionable way. Seldom are they technically more skilled than the people they supervise.

After hours

Transition to always working state noted by Castells and others.

(77-78) Analysts, managers, and high-level specialists put in longer work days, take their work home with them, and go off to work-related meetings. . . . Few coders or low-level programmers take work home with them, unless enrolled in a training program. . . . As their work has been made to look like conventional industrial work and their workplaces arranged accordingly, low-level software employees have responded by thinking and acting like production-line workers.


5 The programmer's workplace: Part II careers, pay, and professionalism
Introduction

Argues there will be less movement across suboccupations and more within by creation of variety of job titles, social subdivision.

Social subdivision of suboccuptations already striated such that movement among levels made more difficult alludes to type of problems relevant to new spirit of capitalism, as in division into careers at the two extremes of the continuum from alienated majority to privileged minority, for coders and low-level programmers and managers, with technical specialists in the periphery of the minority.

(81) The suboccupations, in other words, have been subjected to a process of social subdivision: more or less the same kind of work has been given a variety of job titles in order to reward different kinds of people in different ways.

Careers for coders and low-level programmers

Training for low-level software workers narrowly vocational and heavily ideological.

(82) The training of low-level software workers is narrowly vocational and heavily ideological, that is, coders learn not only what they are expected to do for their entire working career and to accept without question the reason for doing it, but the right of superiors to tell them what to do.
(83) But it is unlikely for present-day coders to be recruited through the ranks to more than straw-boss status (however formally designated). Promotions to higher positions in (technical) programming or in analysis and management usually requires more training, more credentials, or both.

Careers for managers

Managers trained as generalists expected to aim beyond technical specialization.

(84) “Generalists” are trained for and are expected to see themselves aiming towards careers manipulating people, ideas, and situations, not technical information.
(84) Of the two, the advantages clearly lie with the technically knowledgeable manager rather than the technical specialist who managers other specialists.

Careers for technical specialists

Judgment of experience of technical specialists in the periphery of the top level minority of generalist managers reflects personal experience in commercial software, in everyday struggles with imposed multiple substantive job tasks and absense of authority structure leading teams.

(86) If supervisors and low-level programmers hardly ever cross career paths, for technical specialists who constitute the core of most “shops,” the situation is much more fluid.
(86) Technical and scientific occupations, on the other hand, are not inherently amenable to military-like separation of substantive job tasks or to authority distinctions based on them.
(87) One solution is simply to attach different titles to the same work and associate each title with slightly different pay.

Technical specialists can change careers if willing to abandon technical aspects, which seems to make knowledge soluable and cost soul (Heraclitus).
(87) Unlike coders, technical specialists are in a good position to make career changes, but only if they are willing to abandon the technical aspects fo software or use their technical knowledge and experience in explicitly mangement applications.

Pay

Argues managers hide structured nature of employment.

(91) Programmers, particularly low-level programmers, are not in a position to understand how structured their employment is. . . . Managers make every effort to reinforce programmers' belief that salaries are largely individual affairs worked out between the programmer and his or her own manager.
(92) Salary schedules are generally not made public below managerial levels.

Professionalism

Professional ideology grafted onto nonprofessional occupation another managerial strategy to control workers.

(93-94) We have not yet exhausted the arsenal of managerial techniques of control. Of these, perhaps the most intriguing is management's use of an ersatz professional ideology grafted onto a nonprofessional occupation in order to encourage its members to “act like professionals.”

Professional redefined to involve universal job descriptions, training programs, certification processes yet not arbitrated by peers, licensing, or conversion to entrepreneur; managers have the power to define what programming is.

(95) Managers, logically enough, have therefore changed the definition of professional which, for them, has all the advantages of the old guild organization and none of its disadvantages. Professionalism for programmers as it has emerged in management literature means: the establishment of universal job descriptions and standards, formulated, of course, by managers; common training programs; and perhaps a common certification process similar to that found among traditional engineering employees. On the other hand, the managers' image of professionalism does not include certification by an authority controlled by the programmers' peers; it does not include, certainly, licensing, nor does it foresee under any circumstances making independent entrepreneurs out of software workers. Management's vision, in other words, is of a profession without professionals. . . . In short, the managers' notion of professional programmers is one which gives them and not the programmer the power to define what programming is.

Individualism confined to self image substitutes for advantages of collective action and genuine professional standing.

(96) The result has been to impose on programmers all of the disadvantages of collective action by denying them the advantages of either unionization or genuine professional standing, and doing so in the name of individual development. It is an individualism of a peculiar sort, confined to programmers' self-images, while major decisions about the work they do, pay, and about their career prospects are settled for them in an impersonal way by thoroughly organized employers.


6 The routinization of computer programming
Introduction

Ironic that Babbage an early proponent of cheapening labor.

(97) The transformation of programming is not the result of technological imperatives inherent in the logic of programming or computing. Programming has changed because managers, concerned about profits, have set about systematically and carefully to change it. . . . Harry Braverman, in his definitive study of the organization of the modern workplace, has cited one of the earliest and clearest management statements on the “cheapening of labor,” that of the English manufacturer and economics writer, Charles Babbage.

Management practice and the de-skilling of programmers

Changes in work

Structured programming the key management de-skilling effort, akin to limiting workers choice of tools and using standard parts and materials, industrial rather than craft production.

(99) The centerpiece of management efforts to de-skill programmers is structured programming. . . . The limitations on procedure are the intellectual equivalent of limiting the worker's choice of tools as well as the sequence of their use. . . . This is similar to the restrictions placed on an industrial worker with respect to the choice of materials.
(99) Structured programming makes it possible to organize programming along the lines of industrial rather than craft production.

Modular programming and Chief Programmer Teams extend structured programming to workplace organization.

(99-100) To aid in the production of a standardized product, structured programming as a way to structure work has been complemented by various social arrangements to structure the relationships between software workers. The most important of these, discussed in some detail in Chapter 3, are “modular programming” and “Chief Programmer Teams.” Both are extensions of structured programming principles to the level of workplace organization. . . . The detail workers are assigned “modules” which from the viewpoint of production engineers are identical to subassemblies in manufacturing workplaces. The modules—designed by “high-level” specialists and constructed according to the guidelines of structured programming—can be assembled, tested, and repaired independently of each other. A whole “system” can be structured to operate at all times (although at reduced capacity) while individual modules are checked for errors or replaced by new modules designed to alter the performance of the larger system.

Legitimation techniques and propaganda

Function of supervisors has become more ideological; evidence today is yearly performance management goal setting, communication of organization plans, job simplification and time tracking.

(101) Because engineers are able to redesign work tasks so that more and more workers effectively supervise themselves as they do their jobs, the functions of supervisory workers have become more ideological than ever. They have increasingly tended to concentrate on techniques of legitimation, that is, on promoting through various forms of propaganda the “inherent” right of managers and owners to control not only what the workers make, but where, when, and now even how they make it.
(101-102) They are encourage to identify corporate profitability with technical rationality, technical rationality with efficiency, and their own individual success and advancement with the success of their future employers. . . . They come to understand that advancement requires they identify with the goals and expectations of the organization, i.e., of the owners and managers. . . . The goals they must identify with—job simplification and deliberately induced “obsolescence”--are intended to allow managers to get rid of employees, not promote them.

Company propaganda, pervasive ideology of individualism, management-defined professionalism.

(102) Of the many devices employers use to establish their “right” to define both the software product and the manner of its making, three deserve emphasis. They are direct company propaganda, a more vague but also more pervasive ideology of indivdualism, and the encouragement of a management-defined programmer “professionalism.”

Personal success in collectivized setting.

(102) Normally, individualism would be expected to promote resistance to management's claim that it has the right to control work. But this is an individualism of a peculiar sort, one which encourages personal success in the most collectivized of settings.
(103) It is a code of behavior to be adhered to by programmers but drawn up by their employers. . . . An internalized “professional” ideology, in other words, replaces the conveyor belt and the foreman.

Predictions and other essays in prophesying

Design of operating systems, languages, and firmware predicted to become the loci of opportunities for highly skilled programmers.

(104) The design of operating systems, of high-level languages, of the logic wired into the machines, the breaking up of work into sub-tasks, and other work directed towards coordination and supervision of detail labor will remain critical parts of future data processing. The major exception among supervisory tasks will likely be low-level management which will be taken over by machines.

Man machine interface unmediated by human programmer has become the modern GUI, but still needs programmers to build and maintain it.
(104) Almost certainly, as the amount of detail work increases, so, too, will the number of software detail workers. . . . The “man-machine interface” which managers and engineers look forward to is one unmediated by a human programmer.
(105) The great differences in rewards and in formal training (or at any rate, in formal credentials) will mean sorting out people according to social class background to a much greater degree than now.

Questionable position on entry of women and minorities in programming.
(106) It should be stressed, to avoid confusing cause and consequence, that the de-skilling of the “average programmer” has not come about
because of the influx of less skilled women, black and/or brown employees. On the contrary, management-designed routinization has made it possible to use less well trained and less skilled workers to begin with.

The future of programmers and programming

Grim prediction for future of majority of software workers; disrupted by emergence of personal computer, Internet, and floss?

(106) It is hard to anticipate a happy future for the majority of software workers, particularly for the newest and least skilled entrants. Not only will their work be further degraded, but recent trends have shown how white collar detail workers are just as vulnerable to layoffs, dismissals, and demands for “increased productivity” as their blue-collar counterparts.

Unfair burden of cultivated individualism, evidence of absence of collective action against layoffs, acceptance of management explanations for eliminating less productive colleagues of the pseudo-profession.

(106-107) The faith, when combined with a carefully cultivated individualism, produces two major results. The first is an unwillingness to challenge the management's definition of what is going on and how the employee should behave. The second is a commitment to dealing with those problems of work or career which do arise on an individual rather than a collective basis. . . . There is no psychological defense because the other side of “individual” success is “individual” failure. . . . It is a terrible and—if my analysis of the structure of the programming workplace is correct—an unfair burden for the programmer to bear. . . . Even in times of relative economic crisis in the edp industries—notably 1971-1974—software workers who kept their jobs while friends and colleagues were losing theirs merely felt relieved and did little to resist the unseemly treatment of fellow “professional” workers. Instead, the survivors accepted with little objection management references to “dead wood” and “obsolete” training and shouldered without complaint the added work left by their former colleagues. The routinization of programming is likely to leave such attitudes unaffected.



Kraft, Philip. Programmers and Managers: The Routinization of Computer Programming in the United States. New York: Springer-Verlag, 1977. Print.