30The Psychology of Computer Programming

Gerald M. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, 1971; Silver Anniversary edition with new commentary, Dorset House, 1998

Linked to 28 chapters: supports 20 · contradicts 1 · mechanism 9 · same claim 7 · pairing 7

Weinberg wrote this book to start a field that did not exist: computer programming studied as a human activity. In 1971 the subject was thought to have no psychology at all. Programming was either an engineering matter or a mystique, a waving of the hands whenever anyone asked how it was actually done, and the industry's answer to the mystique had been to fund scheme after scheme for getting rid of the programmer. Weinberg's reply is that the executives were right about where the trouble lay and wrong about the remedy. His model is anthropology rather than psychology, because a new culture is a place where you do not yet know which questions are meaningful: the sociologist looks for answers, the anthropologist for questions. So the book proceeds by introspection, by observation, by small experiments his students ran in their own shops, and by the practice he says the profession has abandoned, reading programs. What it finds is that the largest variable in programming is not the machine or the language but the people and the arrangements they work in; that a programmer who owns his program cannot see its errors, while a group that has given up ownership finds them in an afternoon; and that differences between one programmer and another swamp the system differences the industry was arguing about. Many of the claims are opinion, he says, and his hope for a reader who disagrees is that the reader will set up an experiment and prove him wrong. In 1998 he put the book back in print without altering a word and added comments after the preface, after each part and after each chapter, saying what had held and what had not.

Programming as human performance

The book opens with a small PL/I program that reads ten thousand numbers and adds them up, and reads it line by line asking one question of each piece: why is this here? Almost nothing in it is there because of the problem. The numbers are taken in batches of a thousand because the machine could not hold forty thousand bytes at once, a limitation of the hardware. The built-in SUM function goes unused because it converted its input to floating point and lost pennies from decimal accounts, a limitation of the language. The array is stepped through by hand because the programmer did not know that an array's name alone stands for the whole of it, a limitation of the man. No more than a fifth of the code, Weinberg reckons, is directed at the specification, and that is typical.

His fourth category is history. Two programmers at the Social Security Administration found an instruction that turned an A into a 1 in a column where only digits could appear, guarded by a pre-edit program that made the case impossible; a keypunch at one district office had punched 1 as A several programmer generations earlier, and the temporary patch had outlived everyone's memory of it. The fifth category is the specification, and it carries the claim the rest of the book rests on. Specifications evolve together with programs and programmers, because in most cases we do not know what we want to do until we have taken a flying leap at programming it. Writing a program is a process of learning, and what is learned is local to one shop, one machine and one set of accidents.

Reading is how any of this becomes visible, and reading is what the profession stopped doing. Programming is a kind of writing, and in every other kind of writing one also reads. Weinberg's surveys found that nine-tenths of first-line managers did not read the programs their people wrote, and he asks how such a manager could know how good they were. "Even programmers do not read programs," he writes on the first page of the first chapter.

If nobody reads programs, then grace is no measure of a program, and neither is anything else you could see by looking at the code. Weinberg refuses the question of what makes a good program in the abstract — no program has a goodness of 83.72 per cent — and replaces it with four questions asked of a total situation. Does it meet its specification. Was it produced on schedule, and with what variability, since what people cannot bear is not the length of a schedule but its spread. Can it be changed when conditions change, and at what cost. And how efficient is it, and efficient in which currency.

The third chapter is about method. Introspection cannot stand alone; observation shows what people do and not what they can do; and experiments cost money that psychology is not used to spending, one small study of his coming to thirty thousand dollars for nine subjects. Publishing that a correlation with experience was 0.72 is false precision, because experience cannot be measured to two decimal places, so the 2 is noise and probably the 7 as well. The average programmer, he says, spends two-thirds of his time working with other people, and ninety-nine per cent of the studies had been of individuals — which he compares to studying the swimming of frogs by cutting off the legs and putting the legs in the water.

Going back over this part in 1998, Weinberg found the executives unchanged except in scale: the funds spent on schemes to eliminate programmers had grown beyond anything he had imagined, not one scheme had eliminated anybody, there were ten times as many programmers, and every scheme had been invented by programmers themselves. On reading he had nothing to retract, only a finding to add: the people who get value out of reading each other's work are the good ones, so the good get better and the bad get worse. Of the four questions he revised one, defining quality as value to some person, which puts the trade-off inside the definition, and reporting that the mean had improved while the variance had not. On method he conceded the laboratory. Programming was not too complex to be studied, he decided, but very likely too complex to be studied in one; and he had stopped fighting the observer effect and begun to use it, after a client whose review went unusually well while he watched had his photograph blown up into a life-sized cutout to attend the later ones.

The programming group

The second part divides programmers into three assemblages: the group, who share a place and a machine but work on separate programs; the team, two to a dozen people producing one program together; and the project, many teams with their own standards and documentation groups, like the Austrian army. The group comes first because its lesson holds in all three. An organisation chart is a toy: little programming work would get done if interactions had to follow its straight lines.

The story is a university computing centre whose common room held vending machines at one end. Two serious students complained of the noise around them, and the manager, who had never been in the room, looked in for fifteen seconds and had the machines moved out. A week later a delegation arrived to say the consulting service had collapsed, though the two consultants insisted they were working as fast as ever. He finally set a graduate student in sociology to interview the queue.

What the students had been doing at the machines was reading their output together, and since most of their problems were alike, someone standing there usually knew what was wrong. That channel had been carrying most of the load, and instead of putting the machines back, the manager hired more consultants, who complained about the triviality of the questions until the service was abandoned. The lesson is not that informal structures are good but that they always exist, so that changing the furniture deranges systems you cannot replace at the same cost.

The chapter then turns to why all this is resisted. Most programmers, asked, would say they prefer to work alone, and hiring had long selected for the detached type. Detachment from people goes with attachment to programs: the program becomes an extension of the man, and everyone knows whose it is even when his name is not on it. Owning a painting is harmless because taste settles nothing; owning a program is not, because the machine returns a verdict. Weinberg runs the syllogism out loud — this program is defective, this program is part of me, therefore I am defective — and observes that its harshness is exactly why it is never reached. So the thin listing comes down the corridor and the explanation is the keypunch operator, never a plain admission; and where the error is subtler than a blank page the eye simply does not see it.

The remedy cannot be a direct attack, since attack produces defence and defence is the thing to be removed. It has to be a restructuring of the social environment and of what the programmers value. He calls the result egoless programming. The story Weinberg tells at length is Bill G., writing a simulator for an early space tracking system whose heart was a loop of thirteen machine instructions. In his group nobody went to the machine without a second person reading the code first, and swapping the favour was usual. Bill was having a bad coding day. As Marilyn B. worked over the thirteen instructions and found one error after another he grew not more defensive but more amused, and came out announcing that she had found seventeen bugs in thirteen statements. Marilyn, reasoning that where there had been seventeen there were probably more, went looking for a critic of her own, and three more were found before the day ended. When the code went on the machine no further error was ever found, and the simulator ran in more than a dozen installations for at least nine years. On the mean time to finish a program Weinberg claims nothing; on the variance he claims a great deal, since one of Bill's twenty errors might have survived into integration and disordered somebody else's schedule.

By 1998 the batch centre had gone the way of the Brontosaurs, as he put it, but the social function of a common physical place had not: electronic mail, whose arrival he had failed to predict, does not do what proximity does, and the survival of the half-height partition proved to him that working managers ignore the research. His one clear error ran the other way: he had predicted that remote terminals would isolate programmers, and had underestimated how much programmers want the company of other programmers. On egoless programming he made two admissions. It was the idea in the book most often cited, most often misunderstood and most often denied, and he wondered whether calling it less-ego programming would have spared it the argument. And the gap he had complained of in 1971, that nobody had run the experiment, had closed: there was by then no shortage of evidence that technical reviews produce more reliable code more cheaply and more consistently. What he had learned from the holdouts was that reasons which were never logical cannot be answered with logic.

The programming team

A team is formed when the work exceeds what one mind can hold, and at that moment technical conflicts become interpersonal ones needing a social mechanism to settle them. Weinberg's arithmetic for the cost of that mechanism is blunt: three programmers organised as a team do about twice the work of one of the same ability, and three such teams about twice the work of one team. An eight-month job for one person is a four-month job for three and a two-month job for nine, and two months is the floor, because it is doubtful that nine programmers can do anything useful in less time than it takes them to get organised.

From this comes his rule for staffing: give the best programmers you can find enough time that you need the fewest of them. Goals have to be set by the team if they are to be accepted, and the cost of a merely apparent consensus is the chapter's best story. A seven-phase system had one programmer write a shared input-output package; Joe R., who thought himself the better candidate, was sore for a week and then seemed to get over it. Four years later the machine was replaced by a nearly compatible one whose input-output was different. The package was converted, the interfaces preserved, and the system blew up in a section that was clean, while the company paid rent on two machines. One of the original programmers, brought back, recalled that Joe had been disappointed, and which section was his. That section had stolen a word of the resident input-output area for a branch into its own code and restored it on exit: Joe had quietly written his own version of the routines he had lost the argument about, and in the new system that word held a tape position.

On leadership Weinberg is a partisan and says so. Authoritarian handling produces working to rule: a manager appalled to see programmers arriving at half past ten, who had not found out they had been on the machine until two, enforced the clock and halved output overnight. Leadership among programmers means influence, and programmers give it to people they think are good at what they do. A leader with no technical claim can be respected if he admits it; what he cannot do is pretend, as Arnold C. discovered when his two most experienced people encouraged him to put a nonsensical algorithm to the project and then took it apart in front of everyone. The alternative to headship is circulation: influence moves to whoever the moment needs, the teacher when something must be learned, the debugger when the debugging starts. What matters is that leadership is settled inside the team rather than imposed from outside. Only the leader who is ready to step down, Weinberg writes, has a real chance of success.

Teams tend to choose two leaders, a task specialist who allocates and coordinates and a maintenance specialist who settles conflicts; the second, Weinberg observes, is very often a woman, and no study has tested it. Against this the chapter sets the alternative then circulating inside IBM, Harlan Mills's chief programmer team, built like a surgical team around a master programmer with a backup and a librarian; Weinberg wants it published so that it can be tested against egoless programming, and wonders whether it suits those who fancy themselves chief programmers better than the rest of the workers.

Twenty-five years of watching teams changed his definition of one. A team is no longer a collection of programmers producing a single program but a collection producing better products by working together, and what separates a team from a group is not a shared product but a shared way of learning: the goal they hold in common is helping each other perform better. The staffing rule survived with three amendments — the smallest number is never one, sufficient time has to include the time a team takes to form, and it is better still to have teams running before there is anything urgent for them to do. He also withdrew a hedge. Of his own sentence about shortcuts that work only if everything goes right, which it rarely does, he wrote that rarely was pussyfooting, since something always goes wrong, and that hedging like his had kept the optimistic estimate alive. On the sentence recommending at least one woman programmer on every team he explained the survey behind it: none of the women in his advanced class had ever worked on a team with another woman. By 1998 the only place he still found that bias was in the leaders managers appointed, two to one male.

The programming project

What distinguishes a project from a team is a third role, the leader of leaders, who sees the work only through other managers. Weinberg's first demand of a project is that it stop imagining itself a house of cards: a project is a river that stays the same river while the water changes. Mark S., the only man who understood a control program he had designed, asked twice for an experienced programmer so that he could train a successor, was sent trainees, and was given a substantial raise instead. He quit before drawing a week's pay at the new rate, and the system was delivered more than a year late, ran too slowly to do the job, and was scrapped. Henry F., in the same position, trained his two best people to know as much as he did and left a project that finished. The maxim Weinberg draws is not subtle: if a programmer is indispensable, get rid of him as quickly as possible.

Measurement goes wrong as a matter of arithmetic. On one military project a monthly progress report had to reach a printer twelve days before its deadline, and every level above the teams wanted days to review it; working the dates backwards, what a team submitted was due four days before the month it described had begun. What the teams sent up was therefore a forecast, what came out of the top was labelled progress, and nobody worried about the difference. Then each reviewer smoothed. An unusually high figure was shaved, a low one was raised so as not to draw attention, a long list of problems was trimmed and a short one padded. Six or seven stages of this produced a report showing steady progress every month and no measurable relation to anything at the bottom.

News lives in the extremes and every stage removes them; and a manager who believes good management produces a smooth operation reads the fluctuations as the misjudgements of people too close to the work. Against this Weinberg sets Asch's line-judging experiments, in which most subjects will call the shorter line longer if everyone before them does, and in which a single dissenting ally restores almost everyone's sight. His illustration is a meeting of six team leaders about to send a crew across the country to test the system. Everyone agreed all was on schedule. The manager let a silence run for a full minute and caught the smallest movement of a hand. George had a slight delay. How long. Maybe six weeks. Asked once more whether anyone else had a problem, a second leader said that if George got four extra weeks his group should have them too, and eventually all six parts turned out to be behind.

Because the lines of control and the lines of reporting are the same lines run backwards, a hierarchy cannot separate doing the work from judging it. Remoteness does the same thing to judgement higher up: a supervisor responsible for work he does not understand rewards the appearance of work. The same reflex attaches women to menial work, and Weinberg gives that a section of its own, reporting a survey in which two women talking was called gossip, a woman talking to a man was flirting, and two men talking about basketball was business. Each prejudice has its price, he writes, and excluding anyone from any position on any ground but incompetence robs the project of the best performance it could have had.

He closes the part with the 1969 NATO software engineering conference, where Joel Aron reported an informal study of a dozen projects with one success among them, virtually all the failures ascribed by their own managers to management rather than to missing technique — and where, on the next page of the proceedings, C. A. R. Hoare says that basically all problems are technical. Hoare is right in a sense, Weinberg answers, and it does not work out that way; people are coping with problems they do not understand and with problems they do not know they do not understand, which is itself a failure of management.

Nothing in the psychology of measurement had moved by 1998. People still played what he then called schedule fiction and schedule chicken, and for the reason he had given: they were still pressed to supply the answer management wanted rather than information about the state of the work. A new generation of managers still believed loyalty could be bought, not noticing that anyone who can be held by money can be taken by more of it. The Austrian army still stood, he said, at least in most managers' minds. What he withdrew was the excuse. Higher managers had gone on being ignorant of software, but people with no software experience had by then run large software projects successfully, which told him the missing skill had never been the software; it was management, and the software had been the alibi. Of the section on women in projects he allowed a grudging half-step: no longer a different species, he wrote, but treated by some as an inferior form of the same one. He had ended the part by saying the picture must be filled in or the industry should stop doing programming projects until it was. Nobody stopped, he noted, so the projects themselves became the research.

Programming as an individual activity

However much of the variation is social, a residue remains, and the third part goes after it in the order an experimenter would: ask first whether the subjects were doing the same task at all, then hold the environment still, then divide the people into personality, intelligence and training. Programming, like loving, is one word covering an infinity of activities, and the widest gap inside it is between the amateur, whose only user is himself, and the professional, who writes for other people.

What a programmer is trying to do matters more than almost anything about him. Weinberg gave four programmers the same substantial problem with specifications copied identically except for the last page. Two were told to produce a fully debugged program using the least processor time possible, with core up to 128K; two were told to produce a debugged program in the shortest time without regard to speed or space. None knew the instructions differed.

The group told to finish fast used two-fifths of the machine time and a third of the personal time, and their programs ran about ten times slower; a repeat on a different problem gave the same two-fifths and one-third with a speed gain of half. Both groups hit a compiler bug in a feature one approach depended on; the fast group abandoned that approach long before discovering why, the others stayed to the bitter end. The instruction also changed their estimates: the group working to a schedule estimated conservatively and beat its estimates, while the other estimated optimistically and did worse.

Programming is not one kind of work but a succession of kinds, and the belief that it is uniform effort requiring uniform talent is why so much of it is misassigned. It is here that Weinberg gives the ratio the industry took from him. On small problems where one stage dominates, two studies of the same population can report thirty-to-one differences in performance, depending on whether the problem rewards attention to detail or the broad view; on larger problems the differences fall to two or three to one. But the thirty-to-one is not an illusion. It is the spread of ability within a stage of the work, and a project that divided its effort by kind of work rather than by program could collect it — which is what egoless programming already does.

On personality Weinberg asserts the unfashionable half plainly: few managers can name anyone who turned out not to be intelligent enough to program, and everyone knows someone temperamentally unfit for it. Hiring preselects for intelligence; personality has more dimensions and responds to circumstances. Humility gets the longest note, because without it the programmer learns a few techniques, feels himself an expert, and is crushed by the machine.

Aptitude he treats as a measurement problem with an honest answer nobody quotes. The best correlation reported between a programmer aptitude test and a supervisor's ranking was 0.7, which accounts for 49 per cent of the variation; and most organisations using such tests were using them on programmers who were already experienced, testing aptitude in people whose performance could simply be looked at. Programming, an author complains, has no equivalent of the audition an orchestra gives an oboist; why not, asks Weinberg — sit the applicant down to write a small program. Intelligence, he concludes, has less to do with the matter than personality, work habits and training, all of which can be changed later in life, which turns the problem from selecting programmers into making them.

On motivation the profession has it backwards. Driving force raises performance to a maximum and then drops it quickly to nothing; programmers as a group, in his experience, are overmotivated, which is why projects come apart as the pressure rises. On training he publishes a result against himself. Finding that the syntax of Job Control Language was blocking his students, he emphasised exactly those details in his lectures and kept records: in that class 83 per cent of all errors were the errors he had lectured on, and a control class given the same exercises and no class time on the subject made 87 per cent. The lecturing had almost nothing to do with it and the exercises had everything.

The last part turns to the tools and asks of each the same question: on what evidence about people was this designed. The answer is generally none. His principles for language design — uniformity, compactness, locality and linearity, tradition — are psychological rather than mathematical, and his evidence for the first is a survey.

FORTRAN then allowed a subscript to take seven forms and nothing else. Asked whether 21 - K was a legal one, nine of 117 experienced FORTRAN programmers said correctly that it was not, thirty-one said it was, and seventy-seven did not know — and when the nine who were right were asked to write the rule down, not one could. Fifty-three PL/I programmers asked about their own language, whose rule has one form, got it right forty-nine times, and the four who were wrong had come from FORTRAN. On time sharing against batch, the argument the industry was then conducting most loudly, Weinberg cites the one body of experimental work and its conclusion: no general case can be made for either mode, because individual differences in performance overshadow computer system differences.

These are the parts his 1998 comments are hardest on. The third had held the most hope for him and delivered the most disappointment: a quarter-century later, he wrote, individual programmers were no better suited to the work by personality, no more intelligent, no better motivated, no better trained and no more experienced than their predecessors. They were far more productive, and he credited none of that to the individual — better tools, better teams, better management. The experiment with the changed page he came to regard as the most important he had seen in the field, because it showed that programmers do about whatever they are asked to do; that result sent him out of psychology and into the writing of requirements. The aptitude section came with a confession: he had left the subject out of the manuscript, and two of the publisher's reviewers, who sold such tests for a living, insisted the book address the most important subject in programming, so he wrote those pages to get the book published, and said that if they had helped kill the practice he was glad of it. The personality chapter he would have rewritten entirely, having taken up the Myers-Briggs indicator and Virginia Satir's work on how people cope under stress. On the tools he was unembarrassed: he would cut the two chapters on languages to two paragraphs and expand the one on tools to ten volumes. The coverage analysers and test harnesses he had only dreamed of all existed by then and hardly anyone used them, which left the obstacle where he had found it, not in the tools but in ego-full programming and in the low standing of the people who test. One thing he had missed outright: he had worked with the designers of Simula in Oslo in 1968 and admired the language, and had not thought the object-oriented idea would matter to general-purpose programming.

Since 1971

Weinberg put the book back into print for three reasons he gives plainly: to hand the original to a new generation, to supply the historical perspective a young field does not have, and to take a once-in-a-lifetime chance to comment on an industry's development and on what he had thought might happen. He left the 1971 text as it stood, antiques and all, on the principle he gives anyone whose work is under review, that hiding the errors throws away the part a reader learns from. His verdict on his own forecasting was that it came out "worse than I hoped, but not as bad as I feared", which is what he says of any technical review. On the one purpose the book had announced, triggering a new field, he refused himself the credit: there were by then many people studying programming as a human activity, but he would not say the book had started that, or that it amounted to a field.

Set his two lists side by side and they divide along a line he does not draw. Everything the twenty-five years had changed was machinery or its economics: the tools, which he calls a utopia beside the ones he had; the number of programmers; their output, far larger without their being any abler; the death of aptitude testing, which he hopes he helped kill. Everything the years had left alone was an arrangement between people: the reading of programs and the reluctance to have your own work read, the fiction that accumulates as a report travels up a chain, the Austrian army in the manager's head, the half-height partition, the cost of individual variation to anyone trying to predict a schedule.

The movement he named as the great hope carried his idea furthest. He saw the teams then forming under the Agile banner as egoless teams, and the code review that now gates almost every change in the industry is Bill G. and Marilyn B. with an audit trail, by way of Michael Fagan's inspection procedure at IBM, which turned the swapped listing into a defined meeting with roles and recorded defects. The name travelled worse than the practice, since many read egoless as a demand that programmers have no ego rather than as an arrangement in which the code is not owned. The chief programmer team, tried on a New York Times indexing project and reported a success, never generalised: it needs chief programmers. The ratio has had the roughest ride. Thirty-to-one was a careful claim about differences within a stage of the work, hedged down to two or three to one on large problems, and what the industry remembered was the round number. When Lutz Prechelt went back to the underlying data in 1999 he found the largest ratios were artefacts of comparing the best subject on one task with the worst on another, and that something nearer four to one survives — roughly the fate Weinberg predicted for anyone publishing a correlation to two decimal places. And the observation that a person cannot report an error which will be heard as a report about himself was given a name and a measure in the work on psychological safety that began the year after the reissue, which found in hospitals what he had found in programming shops: the teams that look worse on the error count are often the ones that can afford to count.

The dated parts are plain, and he marked most of them himself: the programmer is a man throughout, the machines are gone, and the debate that consumes the last part of the book was settled by hardware rather than by evidence. The field he set out to start did not start. The experimental literature on programming is small beside the industry it describes, and most claims about how software should be built are still argued the way Hoare argued them at the NATO conference. The epilogue he left untouched, saying he had nothing to add to it. Having asked the reader to become a better programmer, it asks what he should then turn his talent to, tells of the young man who thanked him for a book that had helped him at a chemical warfare laboratory, and concludes that bad systems can be built by people with good hearts. If something is not worth doing, he writes, it is certainly not worth doing right.