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.
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.
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.
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.
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.
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.
Computers and the people who make them work
(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.
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
(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 programming” since 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.
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
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.
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.
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
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
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.
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”
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.
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
(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.
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
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.
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.
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.
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
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.
machine interface unmediated by human programmer has become the
modern GUI, but still needs programmers to build and maintain
(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.
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.