Book-Reader-Assist/library/The Psychology of Computer Programming/Chapter-04-The-Programming-Group/Chapter-04-source-text.md

The Psychology of Computer Programming — Chapter-04: The Programming Group

• Source: /library/The Psychology of Computer Programming/source-file.pdf
• PDF pages: 83–106
• Pages without text: none
• Note: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.

---

THE PROGRAMMING GROUP he study of the programming group is important for an understand- ing of the other types of programming organization. Even when there is a formal organization of the programmers into teams and projects, informal connections arise much as they do in an “un- structured” group. Indeed, the first lesson we must learn from social psychology is the difference between formal and informal groups. FORMAL AND INFORMAL ORGANIZATION The organization chart is a nice toy for a manager, but little program- ming work would ever get done if interactions among programmers had to follow its narrow, straight lines. Perhaps because organization charts look much like flow diagrams, programming managers who have come 47

48 Programming as a Social Activity up through the ranks seem to place too much confidence in them, rather than in the less formal mechanisms which they themselves used so suc- cessfully when they were in the pits. But human interactions are never narrow, never straight, and hardly ever in the directions shown an organi- zation charts. Many serious mistakes have been made in imagining that formal structure was the only structure in an organization. In projects, of course, much of the informal structure is determined by the structure of the work, and thus may follow organization charts more or less closely, depending on how well the project is organized. But in a computing center, even if it is completely at the service of individual programmers, an informal structure always grows to correct and com- plement the work of whatever formal structure exists. Sometimes, if the powers-that-be are sufficiently wise, innovations in the informal structure can be implemented formally, although not always as exact equivalents. An example of this type took place in the computing center of a con- sulting engineering firm. Jobs were run on a remote batch basis, and most programmers were spread around the three buildings near to the group with which they worked. Turnaround time was irregular, and there was no reliable way to determine in advance when a job would come out. The number of the last job processed was posted on a board outside the return window, but programmers from remote offices could easily waste half an hour coming to read the board and find out that their job was not ready. As it happened, one of the secretaries had an office whose placement permitted her to see the board out the open door, without moving from her desk. She was an attractive young thing, and one of the programmers happened to call her for a date at a time when he was waiting for a job to be returned. When they had talked for a while, she commented that he must have work to return to, but he replied that he was waiting for a job anyway. “Oh,” she said innocently, ‘what number is it? | can see the board from here.” With that remark began a service whose existence gradually became known to all the outlying programmers. It was such a good service, in fact, that the secretary soon had difficulty carrying out her other duties. In this way, this informal mechanism finally came to the attention of the administration. Wisely acknowledging that the service could not just be cut off, the administration decided to inaugurate a special inquiry number over which one could hear a tape recording of the latest number posted. The man- agement was even wise enough to use the secretary’s old extension— although the telephone company gave some resistance before this was accomplished. Thus, a rather smooth replacement of a rather inefficient, but useful, informal service was made—with the concomitant gain in secretarial time for more conventional duties. It should be noted, however, that the new formal system never com-

The Programming Group 49 pletely replaced the old, informal one. The recordings were made more or less at intervals of thirty minutes, so that it was possible for a number to be posted on the board as much as half an hour before being noted on the telephone. For ordinary circumstances, this proved sufficient—but in a computing center, somebody always has extraordinary requirements. Thus, when a programmer was really in a hurry for a job, he would revert to the old system and call the secretary. Now, however, her workload was sufficiently decreased so as not to affect her other work, and so the system has remained unchanged, in all probability, to this day. Besides, she enjoyed talking to all these bright young programmers—and they, let us admit, enjoyed talking to her. Not all conflicts between the formal and informal have such happy endings. In this case, the administration of the computing center recog- nized the function that the informal organization was serving; but in other cases, they might not even be aware of the existence of the function. A case in point occurred at a large university computing center. Because so many of the programmers were students who had no offices, a large common space was provided near the return window, so that the students and other users could work on their programming problems. In the ad- joining room, the center provided a consulting service for difficult prob- lems, staffed by two graduate assistants. At one end of the common room was a collection of vending machines —coffee, coke, candy, and what-have-you. Although the room was quite large, the noise from the revelers congregating at the machines often became more than some of the workers could bear. Finally, a pair of serious-minded students appointed themselves as a committee and went to the computing center manager. He, of course, had never personally gone into the common room, so when he went to investigate their com- plaint, he was appalled at the goings-on at the far end. Without more than fifteen seconds of observation and consideration, he went back to his office and inaugurated action to have the machines removed to some remote spot. The week after the machines had been removed—and signs urging quiet had been posted all around—the manager received another delega- tion. This one was much larger and much better organized. They had come to complain about the lack of consulting service; and, indeed, when he went to look for himself, he saw two long lines extending out of the consulting room into the common room. He spoke to the consultants to ask them why they were suddenly so slow in servicing their clients, but they told him that they were working as fast as they had ever done— if not faster. For some reason, they said, there were just a lot more people needing advice than there used to be. The manager spent two weeks checking for a possible source of the increased load, but all courses and other users were carrying on normally.

50 Programming as a Social Activity Still, the load remained, and students were complaining that they were not able to finish their assignments. Finally, he set a graduate student in sociology to interviewing the students queued up in the consulting lines. After some time, he discovered the source of the problem. It was the vending machines! When the vending machines had been in the common room, a large crowd always hovered around them—but not particularly for fol-de-rol, as the manager had so quickly assumed. True, they were drinking coffee and chatting, but they were chatting about their programs. The typical behavior of a student when he arrived at the computing center was to pick up his output and head for the coffee machine. There, while sipping coffee, he could have a first look at the program and also show it to his buddies who might be standing around. Since most of the student prob- lems were similar, the chances were very high that he could find someone who knew what was wrong with his program right there at the vending machines. Through this informal organization, the formal consulting me- chanism was shunted, and its load was reduced to a level it could reasonably handle. By moving out the vending machines, the manager had broken up the focus of this informal structure and put the resulting load on his con- sultants. Unhappily, he could not easily believe that this was the cause of the overload, so instead of restoring the machines, he tried increasing the number of consultants. The consultants, however, complained of the trivia they were having to deal with; and eventually the consulting service was abandoned altogether, for lack of people willing to do it. When last ob- served, this computing center was furnishing consulting through informal channels—with students scurrying around from office to office until they could find one of the staff programmers to answer their trivial questions. Where it will all end, it’s hard to say; but we can be sure that the students will always get their questions answered—at whatever the cost. The point of these stories is that informal mechanisms always exist and it is dangerous to change things without understanding them, lest you derange some smoothly operating system which you will not be able to replace at similar cost. Many such derangements occur through a change in the physical layout of things—a change which is so common around computing centers that it will pay us to spend a few words on the relation- ship between physical structure and social structure. PHYSICAL ENVIRONMENT AND SOCIAL ORGANIZATION We all know that physical surroundings affect the quality and quantity of our work. What we are alluding to here, however, is not the effects of

The Programming Group 51 noise, light, heat, and other factors, which have been much studied by industrial psychologists. No doubt there are important benefits to be gained from following the design criteria developed in putting together programmers’ working quarters. (Someone should definitely study the de- pressing effect that the all-too-common half partitions have on program- mer productivity. They manage to cut off all useful communication while permitting all disturbing sound and movement to penetrate.) What we are concerned with is how the layout of work space affects the pattern of social interaction which in turn influences the work that is done. As a simple example, consider the establishment which replaced its ancient elevators with spanking new automatic ones. This was most un- fortunate for the programmers, for the old elevator operator had run an informal pickup and delivery service for them between the programming floor—the eighth—and the machine room—the basement. Of course, nobody could justify hiring a messenger just for going from the eighth floor to the basement, so the programmers lost a lot of productive time. Another function this operator served was locator of missing persons. With the machine room on one floor, keypunch room on another, and programmers’ offices on a third, chances of finding a missing programmer in the first place you looked were less than fifty-fifty. The elevator opera- tor, however, could be relied upon to know immediately on which floor a given person could be found. With these two losses—plus the loss of other services such as rerouting of misdelivered mail and relaying of important messages—the new automatic elevators proved to be a net loss, even though the elevator service itself seemed a bit faster. Although the switch to automatic elevators is perhaps more rare, the moving of offices is an almost daily occurrence in some shops. As long as the programmers all remain together, this often has the salutary effect of making two people aware of each other’s existence. In the old days, this function was often accomplished in the anteroom of the machine room, where we all queued up to take our fifteen minutes of on-line debugging. A typical conversation—circa 1956—went like this: “What’s he doing in there so long? I’ve got some really important work to do—but there’s just one more bug.”’ “He’s debugging FORTRAN.” “FOR-what?” “FORTRAN. Stands for Formula Translation. They claim you'll be able to write programs as mathematical formulas and this program will trans- late them into machine code automatically.” “Come on. You’re kidding?” “That’s what they say. As for me, | suppose it can be done, but it can’t be as efficient as hand coding. It won’t sell.” “Well, it’s sure using a lot of machine time. He looks like he’s playing

52 Programming as a Social Activity the organ there, flipping those keys up and down. There ought to be a better way.” “There is.” “Yeah? What’s that?” “!’m working on it right now. We’re doing it on the West Coast, but the only machine is here, so we have to come here to debug. It’s called a Monitor System.” “Monitor System?” “Yes, it’s sort of an automatic operator. Takes the programmer away from the machine. For example, I’ve got thirty jobs here which I’m going to run in my fifteen minute shot.” “Thirty? You’re pulling my leg!” “No, | mean it. By eliminating the operator, we achieve a fantastic speedup—and eliminate set-up and tear-down time, too.” “Well, good luck. But | don’t see how I’m going to debug my programs if | can’t be at the console. As it is I’m going crazy waiting for these— what was that name?—FORTRAN guys. See you later. I’m up now.” A surprising amount of useful information was transmitted in this way. Operating systems eliminated this social structure in the same way as automatic elevators eliminated the other. Still, if there is a common room right next to the place where computer output is returned, useful mixing can take place there. Personalized delivery services, however, tend to isolate the programmer from this type of interaction, and terminal systems for remote-job-entry and exit may make his isolation worse. This aspect of terminal operations is probably going to be a curse, not a blessing. ERROR AND EGO Many programmers who have read this far will be surprised at the emphasis placed on the social interaction among programmers. Pro- gramming—perhaps more than any other profession—is an_ individual activity, depending on the abilities of the programmer himself, and not upon others. What difference can it make how many other programmers you run into during the day? If asked, most programmers would probably say they preferred to work alone in a place where they wouldn’t be disturbed by other people. The ideas expressed in the preceding paragraph are possibly the most formidable barrier to improved programming that we shall encounter. First of all, if this is indeed the image generally held of the programming profession, then people will be attracted to, or repelled from, entering the profession according to their preference for working alone or working with others. Social psychologists tell us that there are different personality

The Programming Group 53 types—something we all knew, but which is nice to have stamped with authority. Among the general personality traits is one which is measured along three ‘“dimensions’—whether a person is “compliant,’’ ‘“aggres- sive,” or “detached.’’ The compliant type is characterized by the attitude of liking to “work with people and be helpful.’”’ The aggressive type wants to “earn money and prestige,’”’ and the detached type wants to “be left to myself to be creative.” Now, every person contains a mixture of these attitudes, but most people lean more heavily in one direction than the others. There is no doubt that the majority of people in programming today lean in the “detached” direction, both by personal choice and because hiring policies for programmers are often directed toward finding such people. And, to a great extent, this is a good choice, because a great deal of program- ming work is “alone and creative.” Like most good things, however, the ‘‘detachment” of programmers is often overdeveloped. Although they are detached from people, they are attached to their programs. Indeed, their programs often become exten- sions of themselves—a fact which is verified in the abominable practice of attaching one’s name to the program itself—as in Jules’ Own Version of Algol, better known as JOVIAL. But even when the program is not Officially blessed with the name of its creator, programmers know whose program it is. Well, what is wrong with “owning” programs? Artists ‘“‘own’’ paintings; authors ‘“‘own”’ books; architects ‘‘own’”’ buildings. Don’t these attributions lead to admiration and emulation of good workers by lesser ones? Isn't it useful to have an author’s name on a book so we have a better idea of what to expect when we read it? And wouldn’t the same apply to pro- grams? Perhaps it would—if people read programs, but we know that they do not. Thus, the admiration of individual programmers cannot lead to an emulation of their work, but only to an affectation of their manner- isms. This is the same phenomenon we see in ‘‘art colonies,” where every- one knows how to look like an artist, but few, if any, know how to paint like one. The real difficulty with “property-oriented” programming arises from another source. When we think a painting or a novel or a building is in- ferior, that is a matter of taste. When we think a program is inferior—in spite of the difficulties we know lurk behind the question of “good programming’’—that is a matter at least potentially susceptible to objec- tive proof or disproof. At the very least, we can put the program on the machine and see what comes out. An artist can dismiss the opinions of a critic if they do not please him, but can a programmer dismiss the judgment of the computer? On the surface, it would seem that the judgment of the computer is

54 Programming as a Social Activity indisputable, and if this were truly so, the attachment of a programmer to his programs would have serious consequences for his self-image. When the computer revealed a bug in his program, the programmer would have to reason something like this: “This program is defective. This program is part of me, an extension of myself, even carrying my name. / am defective.” But the very harshness of this self-judgment means that it is seldom carried out. Starting with the work of the social psychologist Festinger, a number of interesting experiments have been performed to establish the reality of a psychological phenomenon called “cognitive dissonance.” A classical experiment in cognitive dissonance goes something like this: Two groups of subjects are asked to write an essay arguing in favor of some point with which they feel strong disagreement. One group is paid one dollar apiece to write this argument against their own opinions, the other is paid twenty dollars apiece. At the end of the experiment, the subjects are retested on their opinions of the matter. Whereas “common sense” would say that the twenty dollar subjects—having been paid more to change their minds—would be more likely to change their opinions, cognitive dissonance theory predicts that it will be the other group which will change the most. Dozens of experiments have confirmed the predictions of the theory. The argument behind cognitive dissonance theory is quite simple. In the experiment just outlined, both groups of subjects have had to per- form an act—writing an essay against their own opinions—which they would not under ordinary circumstances like to do. Arguing for what one does not believe is classed as “insincerity” or ‘hypocrisy,’ neither of which is highly valued in our society. Therefore, a dissonance situation is created. The subject’s self-image as a sincere person is challenged by the objective fact of his having written the essay. Dissonance, accord- ing to the theory, is an uncomfortable and unstable state for human be- ings, and. must therefore be quickly resolved in one way or another. To resolve a dissonance, one factor or another contributing to it must be made to yield. Which factor depends on the situation, but, generally speaking, it will not be the person’s self-image. That manages to be preserved through the most miraculous arguments. Now, in the experiments cited, the twenty dollar subjects have an easy resolution of their dissonance. “Of course,” they can say to themselves or to anyone who might ask, ‘I didn’t really believe those arguments. | just did it for the money.” Although taking money to make such arguments is not altogether the most admirable trait, it is much better than actually holding the beliefs in question. But look at the quandry of the dollar group. Even for poor college students—and subjects in psychological

The Programming Group 55 experiments are almost always poor college students—one dollar is not a significant amount of money. Thus, the argument of the other group does not carry the ring of conviction for them, and the dissonance must be resolved elsewhere. For many, at least, the easiest resolution is to come to admit that there is really something to the other side of the argument after all, so that writing the essay was not hypocrisy, but simply an exercise in developing a fair and honest mind, one which is capable of seeing both sides of a question. Another application of the theory of cognitive dissonance predicts what will happen when people have made some large commitment, such as the purchase of a car. If a man who has just purchased a Ford is given a bunch of auto advertisements to read, he spends the majority of his time reading about Fords. If it was a Chevrolet he purchased, then the Chev- rolet ads capture his attention. This is an example of anticipating the pos- sibility of dissonance and avoiding information that might create it. For if he has just purchased a Ford, he doesn’t want to find out that Chevrolet is the better car, and the best way to do that is to avoid reading ‘the Chevrolet ads. In the Ford ads, he is not likely to find anything that will convince him that he is anything but the wisest of consumers. Now, what cognitive dissonance has to do with our programming con- flict should be vividly clear. A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct—even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with’ the symptoms of this dissonance resolution—in others, of course. The programmer comes down the hall with his output listing and it is very thin. If he is unable to conceal the failure of his run, he makes some re- mark such as “Those keypunch operators did it again.” or “The operator put my cards in out of sequence.” or “When are we going to get that punch fixed so it duplicates properly?” There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple “| goofed again.” Of course, where the error is more subtle than a complete failure to get output—which can hardly be ignored—the resolution of the dissonance can be made even simpler by merely failing to see that there is an error. And let there be no mistake about it: the human eye has an almost infinite capacity for not seeing what it does not want to see. People who have specialized in debugging other people’s programs can verify’

56 Programming as a Social Activity this assertion with literally thousands of cases. Programmers, if left to their own devices, will ignore the most glaring errors in their output— errors that anyone else can see in an instant. Thus, if we are going to attack the problem of making good programs, and if we are going to start at the fundamental level of meeting specifications, we are going to have to do something about the perfectly normal human tendency to believe that ones ‘‘own’”’ program is correct in the face of hard physical evidence to the contrary. EGOLESS PROGRAMMING What is to be done about the problem of the ego in programming? A typical text on management would say that the manager should exhort all his programmers to redouble their efforts to find their errors. Per- haps he would go around asking them to show him their errors each day. This method, however, would fail by going precisely in the opposite direction to what our knowledge of psychology would dictate, for the average person is going to view such an investigation as a personal trial. Besides, not all programmers have managers—or managers who would know an error even if they saw one outlined in red. No, the solution to this problem lies not in a direct attack—for attack can only lead to defense, and defense is what we are trying to eliminate. Instead, the problem of the ego must be overcome by a restructuring of the social environment and, through this means, a restructuring of the value system of the programmers in that environment. Before we discuss how this might be done, let us look at some examples of what has hap- pened when it has been done—how it affects the programmers and their programs. First of all, let no one imagine that such restructuring is the ivory tower dream of social theorists. Programming groups who have conquered the ego problem do exist and have existed from the earliest days of com- puting. John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image today of von Neumann is of the unparalleled computing genius—flawless in his every action. And indeed, there can be no doubt of von Neumann’s genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today. Average people can be trained to accept their humanity—their inability to function like a machine—and to value it and work with others so as to

The Programming Group 57 keep it under the kind of control needed if programming is to be success- ful. Consider the case of Bill G. who was working in one of the early space tracking systems. His job was to write a simulator which would simulate the entire network of tracking stations and other real-time inputs. His system had to check out the rest of the system in real-time without having to have the worldwide network on-line. The heart of the simulator was to be a very small and very tight loop, consisting, in fact, of just thirteen machine instructions. Bill had worked for some time on this loop and when he finally reached the point of some confidence in it, he began looking for a critic—the standard practice in this programming group. Bill found Marilyn B. willing to peruse his code in exchange for his returning the favor. This was nothing unusual in this group; indeed, no- body would have thought of going on the machine without such scrutiny by a second party. Whenever possible an exchange was made, so nobody would feel in the position of being criticized by someone else. But for Bill, who was well schooled in this method, the protection of an exchange was not necessary. His value system, when it came to programming, dic- tated that secretive, possessive programming was bad and that open, shared programming was good. Errors that might be found in code he had written—not “‘his’’ code, for that terminology was not used here— were simply facts to be exposed to investigation with an eye to future improvement, not attacks on his person. In this particular instance, Bill had been having one of his “bad pro- gramming days.”’ As Marilyn worked and worked over the code—as she found one error after another—he became more and more amused, rather than more and more defensive as he might have done had he been trained as so many of our programmers are. Finally, he emerged from their conference announcing to the world the startling fact that Marilyn had been able to find seventeen bugs in only thirteen statements. He insisted on showing everyone who would listen how this had been possible. In fact, since the very exercise had proved to him that this was not his day for coding, he simply spent the rest of the day telling and retelling the episode in all its hilarious details. Marilyn, at the same time, did not feel any false confidence in her own work on the problem, for—she reasoned correctly—where there had been seventeen errors, there were probably a few more. In particular, she knew that after a certain amount of time working on the code, she had internalized it as much as had Bill, even though she had not written it originally. So she in turn went looking for a critic; and while Bill was giving everyone an enormous laugh at his expense, Marilyn and others managed to find three more errors before the day was over. As an epilogue to this incident, it should be noted that when this code was finally put on the computer, no further errors were found, in spite

58 Programming as a Social Activity of the most diabolical testing possible. In fact, this simulator was put into use in more than a dozen installations for real-time operations, and over a period of at least nine years no other errors were ever found. How different might have been the story had Bill felt that each error found in that code was a wound in his pride—an advertisement of his stupidity. This incident is not an isolated case, and this group is not unique. Why, then, are such groups not more conspicuous? Why is the practice of ‘‘egoless programming” not more widespread? A number of factors might be invoked to account for the impression that such groups are rare. First of all, many of the successful software firms are based on this type of interaction, and though they will admit to it under direct question- ing, they often regard this knowledge as valuable proprietary information. Secondly, groups working in this way tend to be remarkably satisfied and stable, so that the programmers we find wandering from installation to installation are not likely to have come from such a group. Moreover, these gypsy programmers—to achieve a constantly escalating salary range—must encourage the myth that the best programming is the prod- uct of genius, and nothing else. Another reason these methods are not better known is that nobody has ever experimented on the difference in quality of work produced by this method and the method of isolated individual programmers. Some experiments have been performed on factors affecting programmer pro- ductivity, but these have suffered first of all from emphasis on the mechan- ical aspects of programming, not the social. For example, a study will be made comparing time sharing with batch processing or language A with language B, because someone is trying to prove that he should be allowed to develop a time-sharing system or a compiler for language B. The people who run these experiments seem to take for granted the individual nature of programming effort—for that is probably the way they have always operated. Besides, things are complicated enough working with individuals. When you compare system X and system Y and find out that 90 percent of the variance in your experiment comes from individual programmer differences, who wants to add the complication and expense of studying group performance? An interesting anecdote—which we mentioned briefly in the chapter on methods—can be told about one of our studies that tried to assess the difference in programming results obtained when different programmers were given slightly different impressions of what they were to achieve— efficient coding or quick completion. As usual, individual subjects were employed, but one of these subjects—they were all students on a special three-month course—happened to come from a group that practiced egoless programming. At a certain point, he came to me and said that he

The Programming Group

59

had reached the point in his work where he needed someone to look over

what he had done. As the object of the experiments was not to study

differences between group work and individual work,

| was forced—

against my own beliefs—to request that the subject try to proceed with-

out outside assistance, which would only add to the variance of the

experiment.

As a sidelight to this incident, it should be noted that this programmer’s

work seemed to the evaluators to be better organized and better executed

than the other four programmers working on the same problem. In dis-

cussing this question with him, he raised the point that he had worked

throughout as he always did in his own group—always with an eye to

making the program clear and understandable to the person or people

who would ultimately have to read it. This insight indicates that all the

advantages of egoless programming are not confined to the detection of

errors, though that was perhaps the earliest and strongest motivation for

adopting the technique. In fact, it might be useful to examine our four

factors in good programming in the light of what effect this method would

have on them.

For meeting specifications, the value is quite clear. On the matter of scheduling, the effect on the mean time to complete programs is not immediately evident, but the effect on the variation should be clear from our example of the bugged simulator. If it is true that programmers have bad coding days—and this seems supported from a number of sources—then a piece of code written on one of these days is going to have an extra long debugging cycle. In the case of Bill G.’s program, the twenty bugs might have taken several weeks to root out. Moreover, it seems likely that at least one of them might have survived in the system past the time when this piece was integrated with other pieces— in which case the schedule of other parts would have been adversely, or at least unpredictably, affected. Not only is the variation in debugging time reduced, but since there is more than one person familiar with the program, it is easier to get realistic estimates on the amount of real progress that has been made. It is not necessary to rely on a single judgment—and of the person least likely to be unbiased, at that. The adaptability of programs is also im- proved, for we are assured that at least two people are capable of under- standing the program. Under certain programming circumstances, this represents an infinite improvement. Also, the entire work is less sus- ceptible to being disturbed if one of the involved programmers happens to be sick, or pregnant, or otherwise missing, as programmers are wont to be. This not only reduces variations in schedule, but also makes it more likely that at some time in the future, when the code must be modified, someone will be around who knows something about it.

60 Programming as a Social Activity On the question of efficiency, we can make no hard and fast statements. There certainly seems to be no reason why programs developed in this way should be Jess efficient than other programs. By having a second party look at the program, it would seem that we increase the possibility of eliminating at least the most obviously inefficient areas, although overall efficiency is usually going to be primarily influenced by the original structure chosen. One final advantage of this method lies in the effect it has on the person reading the program of someone else, for, if we are correct in assessing the value of reading programs, he cannot help but become a better programmer for the exercise. We shall have more to say on this subject under the heading of programmer training, but it does seem that the general level of competence of such a group is likely to raise itself even in the absence of specific measures for education. CREATING AND MAINTAINING THE PROGRAMMING ENVIRONMENT The question of creating such a desirable environment as we have described is different from the question of maintaining such an environ- ment once it exists. Maintenance is by far the easier task, for converting an existing group to this philosophy will usually run against the phenom- enon of “locking” or ‘fixation’ of social structures. Fixation occurs whenever a situation creates an environment favorable for maintaining that situation. For example, an FM tuner can be designed to center itself on the strongest signal in the vicinity of the tuning knob. Once a station is captured by this device, only a very strong change can get it off, be- cause every small tendency to change is met by a compensating action by the tuner. Such locking occurs in all sorts of systems—physiological, electronic, biological, but especially for our immediate purposes, social. One typical computing example of social fixation is the adoption of one programming language by an installation. Once the language has been adopted, a new language has more difficulty making an entry, because with most of the people using the old language, advantages accrue to following the beaten path. If one needs advice, it is more easily found. If one needs subroutines, they are more likely to exist. Scheduling of computer runs may favor the commonly used language, keypunchers will make fewer errors punching familiar coding, and procedures for using the old language will be smoother and better developed. In the same way that an installation fixates on a programming lan- guage, it can establish a general social environment which either en- courages or discourages egoless programming. When a new programmer

The Programming Group 61 enters the milieu, his attitudes may be shaped by the reactions of the others already there. If he goes to somebody for advice and he is ridiculed for the stupidity of his errors, he is less likely to seek assis- tance the next time. If, however, someone comes to him and asks for help in looking over a program, he is flattered by the implied compli- ment to his ability and may not feel so threatened when he has to seek advice. To a large extent, we behave the way we see people behaving around us, so a functioning programming group will tend to socialize new members to its philosophy of programming. Sometimes the group may have to maintain its philosophy in the face of a larger threat than the introduction of a new member or two. Ad- herents of the egoless programming philosophy are frequently subjected to threatening moves on the part of managers from higher levels in their organization. Managers tend to select themselves from the ‘‘aggressive’”’ component of society and have difficulty appreciating the fact that other people do not completely share their goals of money and prestige. They are especially at a loss to understand the smooth functioning of a pro- gramming group based on mutual respect for individual talent and co- operation in the common cause. Instead, they tend to view people as working for money or under threat—as they themselves do. A particularly pertinent example of the clash between aggressive man- agement and a compliant-detached programming group occurred in a software section of one of the computer manufacturers. One group in the section, acting as a team, had been particularly successful at producing an entirely new system, which promised to have much market potential. The achievement of this group was so evident that the management of the company decided to give them a cash award. In typical management fashion, they gave the award to the person who had been designated as the group’s manager. Imagine their bewilderment when he told them that he could not accept the award unless it was given to all. His reaction, in view of the way the group shared its work, was per- fectly correct, but was not understood by the management. Some man- agers thought that he was maneuvering for more money; others thought he was trying to set up a “prima donna” group. In any case, it was decided to force him to accept the award and also to break up the group—which seemed to have unhealthy ideas. He took the award and promptly split it equally among all the group members, after which the group left the company en masse and went to work for an independent software firm. In this case, the group protected itself against a great outside threat by picking up and leaving. Had the management been more aware of what this group had to offer, and had they been more flexible, they might have worked out a solution that would have permitted this group to

62 Programming as a Social Activity influence the work of other groups in a favorable way. But this is not easily done by managers, who tend to feel that when work gets done it is the direct result of the actions of some leader of outstanding ability. Even when the manager appreciates the work of the group, it is not consistent with his own philosophy to see the productivity of the group as a property of the group, not as a sum of the contributions of the individual members. In one interesting case, a group of ten programmers had come to work in the programming section of a large airframe manufacturer. They had worked together in another firm for about two years, but that firm had decided to centralize its data-processing facilities on the other side of the country. These programmers had been unwilling to move. After each had received attractive offers from several firms, they decided to go with the one that would hire them all. Mass movements of groups of this type are not rare, and though management tends to see them as some sort of conspiracy, they are usually motivated more by the desire to continue receiving the fulfillment of working together than any idea of enormous material gain—such is the powerful influence of a truly recep- tive working environment. Some months after this group had moved to the airframe manufac- turer, their new manager happened to meet their former manager at a computer conference and asked him if he had any more people like those. Upon being told that he had the entire group, he inquired about the secret that had been used in finding these people. Their old man- ager could think of nothing special—one girl had been a new college graduate majoring in Italian, one man had taught mathematics in a high school for seven years, one man was a professional engineer, one girl had been a business school graduate who had worked for several years as an executive secretary and accountant. Why, he wanted to know, had the other manager asked? “| don’t know what it is,” came the honestly puzzled reply, “but since those people have come to our place, I’ve discovered that whenever there is a job that really has to be done right and on time, | give it to one of them. And | have 300 other programmers, but if | want it done right, that’s who | ask to do it. They must be some kind of geniuses.” His perception was so obviously colored by what he expected to see that he could not bring himself to understand that whenever he gave a job to one member of the group, it was worked on by all of them in their usual fashion. When they tried to explain their methods to him, he understood them to be covering up the fact that a few of the members were doing all the work and carrying the others. Fortunately, he was not so rigid that he had to break up the only satisfactory operation he had merely because he didn’t understand how it functioned. Unfortunately, he was unable to

The Programming Group 63 see how their successful methods could be transmitted to others in his group, so the group remained an isolated pocket until the time it moved on—again as a group—to a more understanding environment. Of course, groups that follow the individualistic school of programming also have a way of preserving themselves—as did the remainder of the programming section at this airframe manufacturer. A single new member, or even a single new group within so large a group, really has no chance of converting the social system, even if he is firmly convinced of the correctness of his way of doing things. If he comes into an estab- lished group, he will probably change his ways to theirs, eventually, though after experiencing more psychological hardship than one might like. If the group is newly forming, however, aS programming groups often are, and if it is forming from disparate elements, he may struggle to shape the group to his image and then leave if unsuccessful. A case in point was Jim A., who was brought onto a newly forming project in Chicago from a programming center in New York. The group to which he was assigned was headed by two people who had been firmly brought up in the egoless programming tradition and who were determined to propagate that tradition in this project. The group con- sisted of these two, Jim, and four trainees. On the first day the group assembled, the group leaders began the indoctrination of the others into their method of working. It was decided at the beginning that each of the group members was to have the signature of one of the other members on his run request before going on the computer with any job. By this slightly formal method, they hoped to ensure that the group members would get in the habit of doing what they would come to do spontaneously later on. During the meeting, Jim said nothing, but when the trainees had left, he approached the group leaders. “That’s an interesting idea you have,” he began, ‘to help those trainees learn the ropes.” “Well,” it was patiently explained to him, “it’s not just for the trainees. It’s for all of us, so we don’t start slipping into bad habits.” “You can’t be serious,’ Jim laughed. ‘“‘Why | have more than two years of experience. / certainly don’t need anyone looking over my work. What could those trainees possibly teach me?” Like most prophecies, this one had a way of fulfilling itself, and Jim managed to evade the falling of other eyes upon his sacred programs through one device or another. Before very long, his presence in the group became clearly counterproductive. As he saw the trainees ad- vancing to do difficult and challenging assignments while he struggled on alone, he tried ridiculing them for their lack of independence and ability to think for themselves. His own programs were not up to the standard of quality which the rest of the group was producing. When

64 Programming as a Social Activity the group leader finally felt forced to turn over one of his programs— which Jim claimed was debugged, or “essentially debugged’—to one of the trainees to clear up, Jim had more than he could take and re- signed. In this case, the social environment of the group had been strong enough to shape the behavior of the trainees; but it was not strong enough to counteract Jim’s ‘“‘two years of experience.” As his personality was not strong enough to carry the group in the direction he felt was correct, the situation eventually became intolerable. Perhaps if the group leaders had been more wise and experienced, they would have excused him from the group from the beginning, but the temptation of “two years of experience” proved their undoing—as it has to many others in a business which so sorely lacks experience. SUMMARY The environment in which programmers work is a rich and complex environment, full of human involvement, change, and misleading ap- pearances. To understand that environment, one must understand the difference between formal and informal structures and the many factors that shape it, ranging from the physical surroundings to the individual ego. In an ongoing programming shop, the richness of this environment gives it a self-maintaining quality which resists changes imposed from the outside—especially changes imposed without an understanding of the difference between the formal and the informal. This self-maintenance is manifest on all social levels, and is neither inherently good nor in- herently bad. It is merely a fact of programming life. QUESTIONS For Managers

1. Do you have an organization chart showing the organization below you and around you? Try taking a copy of this chart and marking—with wiggly lines—interactions that occur in your organization. Do the wiggly lines match the straight lines? If so, get out from behind your desk and find out what is really happening out there.
2. When was the last time you moved peoples’ work locations? Can you recall any changed behavior from that move which was not part of the direct intention of the move? What would you have done differently if you were planning the move now?
3. Looking back over your interactions with programmers, can you think

The Programming Group 65 of things you have said that might have forced them into dissonant situations—situations in which their ego had to be defended? In those situations, was the resolution of the dissonance always in the direction you intended, or did you experience such reactions as covering up errors or schedule delays, rather than correcting for them? How could you have approached those situations so as to lessen the dissonance, or to direct the resolution of the dissonance in directions more useful to the overall goals of your organization? . What would you have to do to introduce egoless programming into your shop? What resistance would you expect to meet, and how would you deal with it? How long do you think it would take, and what are the chances of success? What is your honest opinion of people who are not trying to “move up” in your organization, but who seem satisfied with the kind of work they do and the amount of money they get? To what extent is your view influenced by your own feelings for yourself? For Programmers ¥ lf a computing center had perfectly consistent turnaround, there would be no need for an informal organization to produce information on when jobs are ready. In what other ways do the variations induced by the complexity of programming lead to the growth of informal social structures? Give some examples from your own experience. . If you use a terminal system regularly, how do you exchange informa- tion with other users of the terminal system? Does your terminal system have an operation which enables you to exchange messages with other terminal users? If so, how valuable is this facility for real communication, as opposed to the other methods you use? . Do you refer to your work as “my” program? Try passing one week without using the personal possessive in reference to programs, and take notes on the effects you observe. . Have you ever blamed other people for errors in ‘“‘your”’ program? Have you ever blamed inanimate objects, such as keypunches or magnetic tapes? How many times were you right in blaming these people or things? . Have you ever blamed ‘bad luck” for errors in ‘“‘your’ program? How often? Are other programmers as unlucky as you? If not, why do you think the fates have singled you out for such ill treatment? What sort of rituals do you think you might follow to appease their anger with you? BIBLIOGRAPHY Lynch, Kevin, The Image of the City, Cambridge, M.I.T. Press, 1960. In this small and insightful book, Lynch explores the ways in which our image of

66 Programming as a Social Activity our physical surroundings influences our lives. Although cast on the level of cities, the book contains a mine of information for anyone involved in changing or pre- serving the physical environment in which people work. Wright, Frank Lloyd, An Organic Architecture: The Architecture of Democracy, London, Percy Lund, Humphries & Co., Ltd., 1939. Wright, the greatest of all the American architects, expounded the theory that “form follows function’—that physical surroundings had to be planned to fit the tasks performed in them, just as a suit has to be tailored to fit its wearer. Wright’s ideas may have become ossified into cliches by now, but in these times of ready- to-wear clothing and ready-to-work buildings, the sensitive manager will refresh his thinking about physical surroundings by reading a bit of Wright. Goffman, Erving, The Presentation of Self in Everyday Life, Garden City, N.Y., Doubleday, 1959. Just as workers are shaped by their physical surroundings, they are shaped by the image of the social surroundings. But working groups also tend to shape their image, which is one of the reasons why managers have such a hard time perceiving their true structure. Goffman explores the ways in which individuals and groups work at shaping the image they will present to outsiders and new- comers--something that managers and programmers alike should know. Hall, Edward T., The Silent Language, Garden City, N.Y., Doubleday, 1959. Hall takes another point of view on the image of organizations and describes how we acquire our views of the formal and informal structure of the groups in which we live. Hall’s approach yields many insights into the ways programmers are so- cialized, and also into the ways in which we acquire specific programming prac- tices that are never taught in courses or books. Festinger, L. A., A Theory of Cognitive Dissonance, Evanston, Ill., Row, Peterson, 1957. Festinger’s work on cognitive dissonance grew out of an earlier study of what happens when a group which prophesied the end of the world saw the day arrive and the world go on. (When Prophecy Fails). Obviously, dissonance theory has a lot to say to people who work in an environment where prophecy fails each and every day—especially the prophecy that the program is sure to work this time, now that the last bug has been removed. Haire, Mason, Psychology in Management, 2nd ed., New York, McGraw-Hill, 1964. Haire’s fine little book is a good starting place for managers who have a hard time understanding how nonmanagers are motivated. Fano, R. M., and Corbato, F. J., Time-Sharing on Computers, Scientific American, 215 (1966), pp. 128-140. In this popular article, the authors allow themselves the luxury of dropping some tantalizing hints about the society of users, which grows up with a particular com- puter system. They probably felt, however, that this was not a fit topic for a pro- fessional audience, and they never seem to have followed it up.

Silver Anniversary Notes pAb er ee Comments on Chapter 4: The Programming Group Although the batch-processing center has largely gone the way of the bron- tosaurus, the social functions of a common physical center will always exist. Today, however, we have ubiquitous e-mail—something that didn’t exist twenty- five years ago (I missed predicting that, too). E-mail, however, doesn’t replace all functions of proximity. One advantage of e-mail is its relative invisibility— insecure managers can’t so readily destroy a communication system they don’t happen to understand. Still, some of them try—the psychology of paranoia hasn’t changed much—using elaborate systems of spying on e-mail traffic. Or perhaps it’s not paranoia, but simple voyeurism. Abnormal psychology still isn’t my specialty. lf any one thing proves that psychological research has been ignored by work- ing managers, it’s the continuing use of half-partitions to divide work space into cubicles. | might have thought that DeMarco and Lister’s Peopleware would set that issue to rest once and for all.1_ That is, | might have thought that if | hadn’t learned about the managerial psychology that puts social status above produc- tivity. Brian Pioreck commented on this observation: | believe the issue is even deeper than social status. | don’t know how Peopleware became a best-seller. . . . | hardly run into any managers who read about their industry, manage- ment theory, or psychology, period. | used to believe that they 1 Tom DeMarco and Timothy R. Lister, Peopleware: Productive Projects and Teams (New York: Dorset House Publishing, 1987).

ES Silver Anniversary Notes were overloaded with information regarding the specifics of their job, but frankly, managers still aren’t trained, or do not educate themselves, to do their jobs. As for social status, IT managers have been status-deprived in their organizations since they were developers, so this is even more important to them than to their peers in other lines of business. | am amazed at some of the corner-office kingdoms that ClOs cre- ate for themselves. Like many kings, some managers use divide-and-conquer tactics to rule their subjects, but programmers need contact with other programmers. When | pre- dicted in 1971 that remote systems would worsen programmer isolation, | was only half correct. Such isolation happens in some poorly managed organiza- tions, but | greatly underestimated the human need for human contact. Programmers may not want to spend much time in the company of non-pro- grammers, but they always manage to find dozens of excuses to get together face-to-face. Today, | would make the same arguments about error and ego that | set forth in Psychology, but not in terms of the rather judgmental “compliant-aggressive- detached” system of personality description (p. 53). Now | would use the much more descriptive Myers-Briggs Type Indicator (MBTI), a personality inventory system that wasn’t known to the public (certainly not to me) twenty-five years ago. I’ve found the MBTI system most helpful in understanding certain tenden- cies in programmer/manager behavior, some of which I’ve developed in my Quality Software Management series. The concept of “egoless programming,” first described in this chapter, is prob- ably the most cited, most misunderstood, and most denied of all concepts expressed in the original book. I’ve often wondered if | could have written this section with more persuasive power. Perhaps there would have been no contro- versy had | used the term “less-ego programming.” Perhaps | needed more examples, or better examples. Perhaps | needed more experimental evidence. Writing about egoless programming, | said, “Another reason these methods are not better known is that nobody has ever experimented on the difference in quality of work produced by this method and the method of isolated individual programmers” (p. 58). Here’s an area where twenty-five years have corrected the situation, and there is now no shortage of evidence that, for example, techni- cal reviews (inspections or other forms) lead to more reliable code produced more cheaply and consistently.2 And, indeed, more software organizations 2 See, for example, Daniel P. Freedman and Gerald M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd ed. (New York: Dorset House Publishing, 1990).

Silver Anniversary Notes AS Cee today regularly use some form of technical review as a standard part of the process. But not all—not by any means. So, I’ve learned something: If your reasons for not wanting your code reviewed are not based on logic, you'll never be convinced by logical arguments to change your ways. And, if you’re not using logic about your professional life, your professionalism is severely limited. Unfortunately, the decades-old material on creating and maintaining the pro- gramming environment doesn’t seem to have become dated at all. Some man- agers still clash with effective programming teams, breaking them up for all sorts of irrelevant reasons. Some managers still are mystified by what teams do, but have the wisdom to leave them alone. And, when it comes to the value of teams in software work, some individuals still don’t get it. Or, maybe they do understand, but are motivated in a contrary direction by a self-perpetuating dynamic. Many software managers are still judged largely on deliverables, not on their ability to create teams that can deliver, or on the quality of what they deliver. Under this kind of pressure, managers may use any num- ber of incongruent coping styles to cajole short-term results out of their subordi- nates. Some subordinates figure out the game and do the same thing on a smaller scale, all the while honing the skills to become another manager who doesn’t believe in building teams, doesn’t produce quality results, and creates still more subordinates who become the next generation of similarly misguided managers.

tei ' iC

ae

ee

aa

pi tert sth

a te i i

ey. tune

al

§ “¢” tia

sir “

is Oe

. i a sat equines: foseh

|

Peis 10 eco teaagio yeh ty

NOOR ahah ns eR

ON

8

be

eit Yeas gerger: suas 96 on dalsicz:*

l

ay

‘

™”

!

ue ta Seat phe In Ot

miei

“Ny SAN rina

nalighat ana EN

nace grin

iano

acnoned evan of irate

arr pre rod QU ripe) cinipiaent! énnaory TE

tid chy uah onic

yet ath coe nena hay

tal

\ fe sew de eerie tt eseelyy peielspelo ests

bs a eye sven? tr

.

ey

aboeieny yidetsetey vineadenan ine or vale

'

PS yteia) Seni Ae ete eat Sawa ose

VATeth a SMI

1s aA A Tan PR OI POT INR.

HOMBRE IO

tow

mirage hae wb) eareetendgguranene seen

Wir stat eet han US ete SY

SAD

ee:

ign

Oe

Ment tO hye etvest.<met-node siojso of eatyie orion Ineuigne 03 i

foe

DOOR Sawer tre

fete dene Sr SU Gg

eS

MNOS sche de

WE TM PIS

TY ead eh miyisaet 6) Sua. ‘nerve arFep oe AB

“aaa Crt URS RP SsubOdp fedeb Famebronibned et

He!

Th sapere fo ROwaIOr

vf onder erttcangesSy Or

Wt aS

“Ne

et ihe public (ee tsinhy met ep mg) wants

we

ee

a

ee

Maipiul wy wndansti’ CEN conan

its

an

luis?

watavlor, sore ta why "

Rha

RATIOS

,

.

a

|

facial |. ie era ry first dewestier! ‘ty 4 a caplet, ne

1

Mee vogd, and most dened vit all ¢

ie 1 } aL ‘y b rf aa © *.., d We if =) wandered if f cca hee ‘ Re on ith iia. Puna Tat Wieiy | hen ban tne Ne a Oe say, Sabie GeO” Qi Daren.” Porraps 1. umnetnd os weber eoleghny, Fraps | neaded More experighentad @ Witw Meare weRng, | pad, “Angthet re wene Ang ny oo yt contke da ee onedly tyee giver axpetirnested cH. ihe d uanty deere VNR Re See coetied wns the naathgs of | oy pe Oegrewaitvera’ (a. et Si ne, wh ae wiry sda yea eit Wed abc Se shorn of avin thal, tor ax a, | “Gat hr Le tinte oh aera nguene) wad mi events aatia 0 rer HE OOSROly er ay tay pee ateitty ! ‘Aes nisi dase mane 8 ' . fivAvn! paw oe tai 4 Red, [as Preawwue, _ See mem a ithe _ nics ce ai: pees oir cm ary 2 Se ears i. Ati o. a ry