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

The Psychology of Computer Programming — Chapter-05: The Programming Team

• Source: /library/The Psychology of Computer Programming/source-file.pdf
• PDF pages: 107–138
• 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.

---

as IME i PROGRAMMING TEAM he lack of experience in programming becomes more evident as the size of the system to be produced increases. Although we have seen that the programmer does not, ideally, work in isolation, even when the problem is small, there is a social difference between small programs and large ones. As long as the work of the entire group—from its purpose and general organization to the last coding detail—can be held in the mind of one person, there is no need for coordination of programming effort. The interaction of two program- mers looking over a program that either one of them could have worked out is entirely different from the interaction of two program- mers working on separate parts of a whole, which is too great for either one to produce. The difference lies in the way conflicting de- mands are resolved. In the first case, resolution of conflict is the think- ing process of one person—aided perhaps by other people, but always 67

68 Programming as a Social Activity under his control. In the second case, conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them. HOW A TEAM FORMS A programming team, then, should be formed in response to a work requirement that cannot be met by a single person. This need relates not simply to the specifications of the work to be done, but also to the abilities of the people available to do the work and the amount of time allotted to doing it. Both factors—ability of the team members and time available—have the characteristic of requiring minima in order that the work be feasible. For example, certain programming work cannot be done by a team of trainees, no matter how large, so that doubling the number of “warm bodies’’—as they are so often called in the trade— still will not get the work done. Schedule is similarly limiting—we need only cite the apocryphal experiment which tried to make a baby in one month by putting nine women to work on the job as a team. Conceptually, there is a minimum expertise and a minimum time necessary to produce a given system. Because these quantities cannot be clearly defined—and because of the uncertainties involved in pro- gram estimation—managers often form a team which any reasonable judgment would indicate cannot perform the designated task in the allotted time. Inevitably, the team is given an extension when the time limit is reached and the reality must be faced. Had it been faced earlier, the work could probably have been organized differently—in recognition of the longer schedule—and thus produced, in the end, more quickly. This far too common programming situation illustrates the com- plementary relationship between ability and schedule. The minimum schedule can only be achieved by putting the best team to work on the project; and the minimum work team can only be used if we are willing to let the project stretch out for a longer time. In other words, almost any program can be produced with less programming talent—if we are willing to allow a stretching of the schedule, and if we have not dropped below the minimum competence. Such situations also illustrate an important relationship between sched- ule and work structure. Although we must always be on our toes against Parkinsonianism (work expands to fill the time allotted), too tight a schedule will inevitably lead to the temptation to take shortcuts. These shortcuts might succeed in getting the system working on time—but only if everything goes right, which it rarely does. So many failures to meet programming deadlines can be traced back to an initial schedule and plan of attack which assumed the most optimistic conditions—no days

The Programming Team 69 lost through illness, no machine trouble, no compiler problems, no ‘‘im- possible” bugs. Because each of us has had the experience of, say, a six-month period in which everyone on the team was in top health or there was no machine trouble or there were no compiler problems or there were no “impossible” bugs, we can easily slip into imagining—if the price is right—that we can have a six-month period in which all of these fortunate circumstances happen at once. If, on the other hand, we try to cover for the possibility of trouble, we have to supplement our team with extra members. Also, if the total work must be divided among more people, the amount of coordinating effort is increased relative to the total work. As a rough rule, three programmers organized into a team can do only twice the work of a single programmer of the same ability—because of time spent on co- ordination problems. Moreover, three groups of three programmers can do only twice the work of a single group—or four times the work of a single programmer—for the same reason. Thus, an eight-month project for a single programmer might be done in four months if we are willing to put three people to work on it or in two months if we are willing to allocate nine. Notice that two months would probably be the minimum time for this program to be produced with programmers of this ability, for it is doubtful whether nine programmers can do anything useful in less than about two months, considering the time it will take them to get organized. If we have to have the program faster, we shall have to hire a better man for the job. In any case, the basic rule for size and composition of programming teams would seem to be this—for the best programming at the least cost, give the best possible programmers you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do a programming project is to hire a horde of trainees and put them to work under pressure and without supervision— although this is the most common practice today. When thrown into the breach as raw trainees, many people do not learn as effectively as they could from their programming experiences. Even the proper organization of teams for the maximum current produc- tion is not usually the best way to produce maximum /ong-range produc- tion, for to accomplish that training must be taken into account. There- fore, we may wish to place one or more relatively green programmers on a team, even though we anticipate that they will contribute little to the current effort. When the team has such members, the goal of the team becomes multiple—both production and training—and the organiza- tion of the work is affected. In programming, the way a team organizes for work is most strongly

70 Programming as a Social Activity determined by two factors—the organization of the target system and the composition of the team. Because there are frequently several ways of approaching the structure of a system but rarely more than one group of programmers available to do the work, the structure is often chosen to accommodate the strengths and weaknesses of the team members. Ideally, of course, the choice would be made the other way around—the ideal program structure would be planned and then a group would be assembled who could handle this work in an optimal way. But, given the present shortage of programming talent—or even “warm bodies’—such planning is honored more in the breach than in the observance. As an example of the relationship between system structure and team organization, consider first Figure 5-1, which shows how a team com- posed of one experienced programmer and four relative trainees might organize a system. Part a shows how the program might be set up as one fairly large main program which calls upon relatively small—perhaps input-output-free—subroutines to provide some of its functions. Here, ie ie oe a. PROGRAM STRUCTURE b. TEAM ORGANIZATION Figure 5-1 Program structure vs. team organization.

The Programming Team 71 as shown in part b, the experienced programmer would act as a con- ventional leader of the team, programming the main section himself and allocating the subroutines to the trainees in a manner hopefully calculated to give each the experience appropriate to his level of competence. Now consider how the same work might be organized by a team of three programmers of relatively equal experience, as shown in Figure 5-2. In part a, we see that the program is now organized into phases, one following the other, rather than into subroutines. Of course, the main program of Figure 5-1 might also have been organized into phases ac- cording to the conception of programmer leading the group, but we would probably find less interface coding in that version than in the second. On the other hand, the second group could also use subroutines within—and possibly even among—the phases, but in this situation we would be likely to find less interface material in the finished product. The structure of the programming team itself would be more a matter of communication among equals, as indicated in part b of the figure, though member II would probably spend more of his time in “teamwork” than either of the others because of the position of his section between the other two. Member Il, in a situation like this, may actually have the easiest programming job, especially if the first and third phases take a. PROGRAM STRUCTURE b. TEAM ORGANIZATION Figure 5-2 Program structure vs. team organization.

72 Programming as a Social Activity care of the input and the output for the system. In his position in the structure, ability to work closely with the others is probably more im- portant than programming ability, and he might actually be the least talented programmer—as programmer—in the group. These structures, of course, are idealizations. They do not reflect, for example, whatever inner structure comes about because of the general programming philosophy of the larger group to which these team members belong. The organization in Figure 5-1 might in practice be far less hierarchical if the group practices egoless programming; while the team in Figure 5-2 might be far less egalitarian if its members did not. Status of members of a team evolves in a manner influenced by a number of factors, and the factor of who criticizes the work of whom is one of the strongest. Thus, if egoless programming is used, everyone in the group will have the opportunity to examine the work of everyone else at some time, thereby tending to prevent the establishment of strong hierarchy. In programming, the status of a team member is usually strongly influenced by his abilities as perceived by the others. When programs are passed around for shared criticism, the speed at which the “cream” will come to the top is enhanced. On the other hand, if the team members work secluded in cells like monks, the reputations previously established are more likely to remain as determinants of prestige in the team—at least until it is too late to do anything about a misappraisal. Again, the particular piece of work assigned may lend status to a team member—or take it away. Programming jobs seem to carry status just as do carpets in offices, and in organizing a team one must tread gingerly among the sensibilities of the members when passing out the work. Writing auxiliary programs, for example, such as test data gen- erators seems to carry low prestige in some circles, perhaps because the work will not be physically present in the final system. Subroutines— though they may present far greater difficulties—are often thought to place the writer in a subservient position to the programmer who writes the routine which calls them, perhaps by analogy, to the role of the subroutine itself. These anthropomorphisms do not have to represent rational thinking in order to be important factors in determining team Satisfaction with work assignments. They can be quite real—perhaps all the more so for being irrational. ESTABLISHING AND ACCEPTING GOALS Suppressed feelings by a team member about the inferiority of his assignment can be surprisingly damaging to a team effort. Egoless programming tends to moderate such feelings, since each programmer

The Programming Team 73 feels that he has a share in a larger part of the system. Still, if a team sets to work too quickly—before establishing a real consensus about the structure of the project and the division of work—trouble will mani- fest itself in one way or another. Social psychologists have verified in other contexts that failure of one or more members to share the group goals affects the group per- formance—not only through that member’s share but through a reduced performance on the part of the others, for they invariably perceive the division within the group or the indifference of one of the members. A rather fantastic example of the cost of achieving only a surface con- sensus arose in a system that was organized as shown in Figure 5-3. As we might guess from the system organization, the original team had consisted of seven relatively equal programmers, one of whom was designated to write the input/output package to provide a common inter- face for data which were passed from one phase to another. This system had been in existence on the IBM 704 for about four years when it was decided to convert the 704 to a 709. From a program- ming point of view, the 709 was almost compatible with the 704—except for the input-output, which was entirely different. Since this system had all input-output confined to one section, a simple conversion was antic- ipated. The input-output routines were converted so as to use the 709 system while preserving the interface to the various phases. Once the new routines had been tested, they were mated with the old phases and all went well—until the system blew up in phase V. The input-output routines were double-checked, and phase V was Figure 5-3 Organization of a system.

74 Programming as a Social Activity checked for any deviations from the standard interface. Absolutely noth- ing was found. Then phase IV was checked to see if the data it had passed on to phase V had somehow been distorted by the new system, but the output of phase IV matched the previous output for the same test bit for bit. Other theories were pursued, but several weeks went by without a clue as to what had gone wrong. In the meantime, of course, pressure was building up to remove the 704 and stop paying rental on two systems. None of the original programmers of the system were still around, so one of them was brought in to see if he could provide a clue as to the trouble. After a day of unrewarding speculation, he was having a beer with one of the new programmers and reminiscing about the good old days when the original crew had been together. At one point, he chanced to recall that Joe R. had been very disturbed not to get the assignment of writing the input-output routines, as he thought he was much more capable than the one who got the job. “Joe was really sore for about a week,” the old-timer recalled, “but then he seemed to get over his hurt pride. He wound up doing a darn good job on his section, too.”’ “And which section was that?” the youngster asked, beginning to sense a wisp of suspicion. “Section Il, if | remember correctly. But why do you ask?” The young programmer said he just had a hunch, and then excused himself to head back to the computing center. He got a listing of section ll—which nobody had looked at, attention having been focused on sec- tions IV, V, and the input-output routines—and started to go through it Step by step. He didn’t have far to look. Right at the beginning, the program fetched a word from the region of storage reserved for the input-output routines, which were resident in core throughout the entire run. Then phase II replaced that word with a branch to part of its own code, diverting the flow from input-output routines. At the end of its processing, it returned the saved word, leaving everything as it had been upon entry. What had happened, of course, was that Joe—not accepting the team decision at all but merely stopping his open opposition to it—had written his own version of the input-output functions needed by his phase. He said nothing to anybody about this, but merely short-circuited part of the standard routines when his phase was in operation. When the new input-output system was created, however, the part formerly oc- cupied by the branch was now being used to hold some variable which kept track of the position of an intermediate tape. Inasmuch as this vari- able was changed in the course of executing phase II, but changed back to its original value at the end, the input-output routines effectively lost

The Programming Team 75 track of the tape’s position. Since the values on this tape were not used again until phase V, it was only then that the blowup occurred. The cost of this nonconsensus was slow in being exacted; but when its time came, it was paid, and paid handsomely. We should stress here that the consensus we are talking about con- cerns the goals of the group, not such matters of fact as could be settled by other means. Consider, for example, the case of a team producing an on-line system for a bank. While undergoing final acceptance testing of this duplex system, they suddenly saw each on-line printer print a line of absolute garbage, right in the middle of the normal output. The two lines were identical, even though the two systems operated entirely free of influence from each other—in order to ensure that trouble in one would not affect the proper functioning of the other. Of course, the same program was used in the two systems, so all indications were that some sort of program bug existed. Indeed, it would be hard to attribute a probability to the occurrence of two machine errors in the two independent machines—they even had separate power supplies—which would lead to the same line printed at the same time on both. One of the team members was given:the job of tracing down the bug, but after a week of studying the evidence, he was no closer to the source of trouble than he had been at the start. Another team member joined him for a second week, with no better results. The scheduled date for putting the system into operation was only a week away and, since the system seemed to be operating correctly in every other aspect, a meeting was called to decide what to do about this intractable bug. The discussion among the eleven members of the team was heated, and no conclusion was reached, although one large contingent was pressing for the group to agree to label the incident as a freak—a double machine error! No amount of appeal to the statistics of the situation would sway this group from their position—for although it was physically absurd, it was psychologically satisfying. They wanted the system to be ready on time; and in a second meeting, they succeeded in persuading the others to sign off on the system. The system was cut over on schedule and functioned quite well for about a week. Then, in the middle of a banking day, and just when operations were beginning to rely on it, the system just stopped—both machines at once. After about an hour, during which the bank was completely paralyzed, the system was restarted. Nobody dared to estimate how much business had been lost, but auditing the files for the effects of the restart was a gargantuan labor which stretched out over several months. In the meantime, the entire programming crew worked frantically to locate the bug before another failure might occur. Needless to say, when the bug—a certain timing coincidence which

76 Programming as a Social Activity could be expected to occur about once every week or so—was finally found, it turned out to be the same bug which had earlier caused the two garbage lines. In that case, a fortunate—or unfortunate—coincidence had permitted the system to go on essentially undamaged, but the next time it happened, things turned out rather badly. The lesson in this example is the lesson of false consensus—that is, not an apparent consensus as in the other case, but a true consensus on a falsehood. Things are bad enough in programming without adding this type of problem, but it is a psychological problem which we shall have to face. We shall have more to say on the subject under the topic of “opinions and social pressure.’’ For the moment, the main lesson is the difference between this kind of consensus—which stifles the healthy disagreement essential to unbiased appraisal of programming work— and consensus on the goals of the team—which smooths the way for productive functioning. To achieve true consensus on group goals, there is no better method than having the group set the goals itself. For one thing, participating in setting the goals ensures that the goals will be more clearly under- stood. For another, it gives each group member a chance to commit himself publicly to the group’s goal, and this type of public commitment— perhaps because of cognitive dissonance—has been shown to enhance goal acceptance. But participation itself, quite independent of these other factors, seems to be an important determinant in whether an individual truly accepts the working goals of the team with the pursuant increase in productivity. To be sure, not every programming team can be permitted to set whatever goals it happens to fancy at any moment. A team is usually constituted to accomplish some task which has probably been set down before the team was even assembled. But programming tasks are not usually specified too precisely until much later than team formation, so that unless the upper management is very overbearing, much meaningful and interesting goal setting can be done by the team members in concert. The greatest danger is the manager who has come up through the programming ranks and wants to define every bit and byte before the team even sees the problem. Nothing is more sure to dampen the team enthusiasm and make them feel that they are ‘‘mere coders.” When a team does work from this sort of “bit-picking” specification, other troubles arise simply because what the group is trying to ac- complish is not clear. Precision and clarity are not the same. To be clear—and goal clarity is one of the most critical factors in goal ac- ceptance—the task outlined must be placed in a framework of the meaning of what is being done. The programmer wants to know why, not just what.

The Programming Team 77 Problems of unclear goals become more acute when the programming team is working not to produce a specific system, but to provide some service or support function to other programming groups. At least when there is a package to produce, you can have an image of what is to be done, even if you don’t understand why. But a support group must be constantly reminded of their contribution, lest they drift into doing things more concrete but less productive. For example, many installations have a systems programming team. The tasks of such a team are rather diverse, held together by the common thread of service to the other users of the installation. We know how frequently such a team drifts off into fascinating but useless little projects simply for lack of a clear and persistent image of what they are trying to do. This tendency is exaggerated by incompetence of other users in systems matters, for they feel unable to evaluate the work being done by the systems programmers. In one case—not atypical—the three systems programmers in an installation were fascinated with the problem of producing an improved loader—possibly useful in some con- texts, but definitely not in their installation. Each request from the other users for some service, such as creating a new cataloged procedure or incorporating a new system in the library, was met with the statement that it could not be done in their system. In fact, it was asserted, they could be done, but only after this new loader was finished. The statement itself was true enough, because as long as the entire team was working on the loader, there was nobody with the competence to do these other jobs. But the loader itself had nothing to do with them, other than sucking off the labor which could have been more gainfully employed. Users were too intimidated by their own lack of knowledge of the system (most of them were not even sure what a loader was) to complain. Eventually, the whole party was broken up when someone had the nerve to call in an outside expert to do a small systems job for him. The loader never worked anyway, but a change in the system gave the team the excuse they needed; they saved face by claiming that their loader could not work under the new system. There is no remedy for such drifting away from group goals unless there is competence in the installation to evaluate whether or not the group is working according to their mandate. Perhaps even more dif- ficult situations arise when a group has reasonably clear goals, but has more than one at a time. In addition to the previously mentioned potential conflict between production and education as goals, other con- flicts arise, for example, when a team has two distinct programs to produce. Somehow, the relative importance of the two projects must be made clear initially and must be reclarified regularly, lest the quite nat- ural drift in favor of one or the other should occur.

78 Programming as a Social Activity Of course, it is best if each team can have a single clearly defined goal, but the world is seldom so simple. Even if the goal is a single program or subroutine, there is the possibility of conflict between empha- sis on speed, space, or schedule. When a team is not fully apprised of the emphasis to be placed on each factor, the members of that team may very well be working at cross purposes. One team member may be spending most of his effort trying to save time, only to discover that this time has been squandered by another team member who was trying to compress the program into the smallest possible space. When such conflicts come out in the open—especially after the involved parties have a considerable investment in one approach or the other—serious con- flicts are sure to result. The resolution of conflicting ideas on team goals is, surprisingly, often most critical when the differing views are almost indistinguishable. Gul- liver’s attempts to settle the wars over which end of the egg to break are as nothing compared with the energies too often spent arguing over whether to use one subroutine with two entries or a single entry and an extra parameter. The persistence of this kind of argument among team members can reliably be taken as a sign of some deeper conflict— perhaps for ‘‘leadership’”’ of the team—and should not be ignored simply on account of its triviality. TEAM LEADERSHIP AND TEAM LEADERS The word “leader,” to many people, conjures up an image of Adolph Hitler sending millions of goose-stepping soldiers to their death with a tweak of his tiny moustache. And, indeed, Hitler was the ‘‘Fuhrer,” or Leader, to millions of his people. But understanding such a phenomenon as Hitler would be easier under the title of “followership” than “leader- ship,” for there is a certain type of leading which is only a crystallization of deep-seated desires shared by many onto the personality of one. In programming, this is scarcely the type of leadership which is needed —or which would usually be tolerated. Try to imagine the reaction of a typical programming team to a supervisor standing over them with a whip or issuing commands like a lieutenant leading his squad in a charge on the enemy machine-gun emplacement. The reaction to even milder forms of authoritarian ‘leadership’? need not be imagined, for we have numerous examples of unenlightened executives trying this approach on programmers. One typical reaction is ‘‘working to rule.’’ One instance of working to rule occurred in a project that had a change in manager halfway through its life. The new manager was appalled at seeing some

The Programming Team 79 of the programmers come in to work at ten-thirty—so appalled that he didn’t bother to find out that they had been working on the machine until two the previous night. A directive was issued stating that working hours must be strictly observed, and that time-clock punching was to be enforced according to the official rules of the company. The programmers simply responded by working exactly the normal working hours—emptying the office pre- cisely at five-fifteen every evening, and queueing up at the time-clock to do it. Since the project had been operating essentially on a staggered shift basis as an adaptation to limited machine time, productivity im- mediately fell by half. Programmers were idle during the day waiting for machine runs, and the machine closed down promptly after one shift each day. A similar case occurred when a manager discovered that the con- sumption of supplies was running over budget. He immediately ordered a lock put on the supply room, with only the supply clerk having a key. The programmers responded by coming one at a time to the supply clerk all through the day, so that he had no time to perform his other duties. Finally, the manager issued a directive that supplies could only be obtained between ten and ten-thirty or three and three-thirty. This continued until he came upon one programmer staring at the wall and asked what he was doing. “My pen ran out,” was the reply, ‘‘so | have to wait until tomorrow at ten before | can write any more code.” The manager reddened noticeably. “‘Why don’t you use a pencil?” he demanded. “Because | always use a pen. The keypunch operators won’t accept work written with a pencil. It smudges.” “Then why don’t you borrow a pen?” “But then we wouldn’t be keeping accurate track of supplies usage, would we?” Needless to say, this was not a very productive shop until the manager was promoted on to some more elevated position in the hierarchy. Of course, he might have fired the programmer for insubordination or some other such militaristic charge, but he knew very well that bad managers are easier to find than good programmers. Indeed, the chronic shortage of programmers has led to an interesting situation in the entire field with respect to programming leadership. In studying the factors which go into the satisfaction of working groups, social scientists have isolated four major areas:

1. The material rewards and opportunities.
2. The challenge and the interest of the work itself.

80 Programming as a Social Activity 3. The general conditions in the larger organization, such as employee benefits, working conditions, and organization status among similar organizations. 4. The competence of supervisors and leaders. In programming as it is today, the first three of these wants are satisfied with such regularity that they ordinarily do not play a major role in de- termining programmer satisfaction. To be sure, there are instances of underpayment in this generally high-salaried profession, there are dull jobs, and there are bad companies. But these are exceptions, whereas bad supervision and leadership is more common than we would like to imagine. Thus, the attitude of a programmer toward his ‘“‘superiors’’ is more likely to be the cause of his dissatisfaction—with consequent loss of productivity—than perhaps all the other three put together. Leadership, in the sense that social scientists use it, means the ability to influence people. Programmers, being people who tend to value crea- tive work and professional competence, tend to put their stock in people whom they perceive to be good at the things they do. Thus, it is easier to exert leadership over—to influence—programmers by being a soft- spoken programming wizard than by being the world’s fastest-talking salesman. When nonprogramming leaders are brought in to be in charge of programming teams, trouble usually brews unless the appointed leader explicitly and implicitly recognizes his incapacity on technical matters. The very worst he can do—and this goes also for a former programmer who has lost touch with the field—is to try to match program- ming wits with the other members of the team. Although a team might come to respect a leader who openly admitted his programming in- experience, they could only come to ridicule one whose pretense at knowledge was revealed to be a sham. In one case, Arnold C. was appointed to replace a promoted leader of a team within a larger project. Arnold’s qualifications were mainly in the area of data-processing sales, but he affected an air of programming expertise. He even went so far as to suggest an algorithm to solve a crucial problem facing the project, although it was evident to his two most experienced team members that he didn’t know what he was talking about. Instead of showing him the flaw in his scheme when he presented it to them in private, they encouraged Arnold’s wish to as- semble key programmers on the project to hear him present his idea. At the meeting, they gave him about five minutes to get himself solidly enmeshed in his own snare. Then they began to tear his algorithm apart —in detail as well as in grand plan. Arnold finally left the blackboard amidst the combined laughter of the assembled group, and within two months he received a requested transfer to another post.

The Programming Team 81 Such problems frequently arise because the leader who is designated as such by an outside force is not capable of exerting the influence required inside the team. This “formal” or “official” leader, because he represents the goals of the outside world, is always in a precarious position, especially if he sees his job as merely “selling” or otherwise imposing the “management view” on the team. Inasmuch as this view assumes that no compromise is possible with the management, the only possible resolution of a conflict between management and the team is that the team should “give in.” Even assuming that the team could be made to give in, nobody who has ever seen the performance of a programming group which has so knuckled under would desire this result. But forced labor—to the small extent that it does work—can only be made to work with relatively im- mature programmers who are not aware of other possibilities, or with relatively unskilled programmers who are quite aware that other possi- bilities are not open to them. The typical programmer, on the other hand, is aware of other possibilities and aware of his chances of getting them. Carried to an extreme, this awareness leads to the programming type whose career is an unending succession of job changes and very little accomplishment. Normally, however, it leads to programming teams which are run more democratically than typical work teams in many other fields. In a democratic group, leadership—or influence—is not confined to a Single person, but moves around the team from member to member as the needs become compatible with his abilities or ideas. People, however, are not all created the same—even though they may all be created equal. Thus, leadership in a democratic team is never spread uniformly, but falls more on some members than others. The important factor in demo- cratic group functioning is not that every member exerts equal leadership, but that the determinants of leadership are based on the inner realities of team life, not imposed from outside. Thus, when the team is in need of learning something, that team member who knows most about the sub- ject may rise to a position of leader in the form of teacher of the others. Or, when the team’s work enters the debugging stage, one of the members may emerge as a frequent leader because he has a peculiar talent for debugging. A truly democratic team is marvelously adaptable to changing circum- stances, and thus tends to be a more reliable production unit in the face of unanticipated difficulties. Managers, however, tend not to believe that a democratic team is superior in a crisis. For evidence, they point to the speed and determination which a centrally organized group can muster when massed behind a single leader, and they are correct—if the leader happens to be the right one for the situation. It is true that Hitler’s forces,

82 Programming as a Social Activity for example, won great successes under this type of command—but then it is also true that his opponents were organized under the same type of system. Perhaps Hitler was the right man at the right time—until he lost. In a democratically organized group—given, of course, sufficient talent and intelligence to draw upon—the right man can be chosen for each time. The Swiss, for example, elect a general to head their armies when war threatens. When there is no war threat, there is no general— but there are other leaders chosen according to what needs there are for leadership. The Swiss, unlike certain other countries, are not bur- dened by generals trying to govern the country in peacetime. Unfortunately, no programming team can ever be completely democratic in the sense of always being able to choose the right man to lead them at each instant. For one thing, the right man may not exist in the team. For another, personality factors may intervene to preclude the selection of the correct man for the moment. Finally, the intrusion into the group of a designated leader from the outside always biases the group away from democracy. The designated leader is a carrier of information between the team and outside forces which would like to influence the goals which the team pursues. Ideally, he would be a perfectly neutral carrier, but this never happens. His contact with the outside group gives him access to special sources of information which the others do not share, and he may use these sources as leverage to elevate himself to a stronger posi- tion of leadership. If, for example, he has been told by management that they wish a particular program to be completed in ten weeks, he might tell the group that the management has asked for eight weeks. Then, giving the appearance of winning a compromise in favor of the group’s feeling that the work will take twelve weeks, he agrees to change the time to ten. The others have no way of finding out that he has used his special position to appear to be aiding the group, and his esteem as a leader may grow, even though he has been “management’s boy’’ all along. Of course, should the team members ever discover that he has been distorting the transmission of information from management in order to win favor for himself, he is finished as an effective leader of that team. But the temptation to be dishonest or manipulative with the team members is very great, because of the asymmetry of the designated leader’s posi- tion. His work is primarily with the team, but his rewards and punishments come from the higher management. Usually, by the time a programmer consents to accept an appointment as team leader, he has acquired aspirations for a career in management. Advancement in that career is no longer dependent on his programming abilities—which have probably carried him this far—but on his ability to please management.

The Programming Team 83 The shortsighted or insecure team leader may feel that the best way to please management is to promise them whatever they ask. But, ultimately, what the management wants is kept promises, and these can only be ob- tained if the team leader can win team acceptance of the promises as their goals. What the team leader must learn is that

1. Managers—no matter how hard they press for promises—really want results.
2. Results will be far more easily obtained if they are obtained in the pursuit of goals set with full team participation. Keeping these facts in mind, the designated team leader may be able ‘to overcome the handicap of having been designated and become a leader:: in his own right. He may replace the “headship” with “leadership.” We would not be completely honest, however, if we failed to admit: ' that managers are not always aware that they want results. We frequently see a team leader removed from his post for refusing to promise achieve- ments which his team believes are impossible. The process of replace- ment then goes on until management comes up with a candidate with more desire to advance himself than brains to assess the true chances of success. Unfortunately, if the project is a long one, this candidate may be promoted for his cooperativeness before the project has reached the point where management can see that his promises will not be kept. What — ensues is a game of musical chairs, the object of which is not to be left in a position of responsibility at the moment the outside world be- comes aware that the project has failed. This game, played over and over, has put more than one programming manager in the position he has today. The designated team leader, however, can do no better than to resist attempts to coerce him into accepting goals his team cannot meet. Of course, he should remain receptive to new information which might change the situation—as when the management promises him additional people or a better machine schedule. He must assess for himself the chances of these promises being kept, however, for once he promises his managers, they are likely to forget the conditions he extracted from them. But when the management arguments turn to other factors besides the resources or the work specification, he must never let his judgment be swayed. The most typical case involves promises of special rewards if he succeeds, but he must not permit himself to confuse the value of the reward with the probability of achieving it. When the discussions reach the stage of reward offering, there is really no strategy left to the leader but to resist. He must be willing to stake his position as designated leader on the strength of his professional judgment. If he is a good programmer himself, he is doubly strengthened

84 Programming as a Social Activity in this struggle, for he has more confidence in his judgment and he knows that he will not be on the breadline if he loses this leadership post. If he doubts his own proficiency, however, he will fall easy prey to various sorts of threats veiled in a mist of wispy promises. As an illustration of the major points of this section, consider the case of Harold M., an outstanding programmer who found himself in the position of designated leader in the squeeze. He had accepted the job of leading a team to produce a compiler by a certain date, but now man- agement wanted to expand the specifications while retaining the same schedule. Harold discussed the matter with his team and the conclusion was reached that they could not do the work unless they got an extension of three months. When Harold carried this information back to his man- ager, he found that it was not accepted. When he insisted, his manager arranged a meeting among Harold, himself, and his own manager. Harold knew from the composition of this meeting that it would be an attempt to put him in the “hot box.” With this arrangement—conveniently private—Harold was supposed to get the feeling of importance in an atmosphere where threats and promises could be made but never ac- knowledged. But Harold had already experienced this situation often enough to anticipate each new move, and he was armed with the con- fidence in his own and his team’s judgment. The meeting went on for some time and, with each parried thrust, the atmosphere grew hotter. Finally, it reached the stage of the ultimate threat. “Harold,” his manager began, for the manager’s job was to do the dirty work and the manager’s manager’s job was to play the role of the benev- olent father figure softening the manager’s harsh threats with sweet promises. ‘Harold,’ he began again, because he had paused to pull his chair forward a significant three inches, ‘“‘you’re not cooperating with us. To be a manager, you have to learn to cooperate, to compromise. Per- haps you don’t have what it takes to be a manager.” Harold caught the implication, and instead of letting it pass, dragged it fully into the open. “I think you may be right. Why don’t you get someone else to do this job—someone who knows how to cooperate.” The manager’s manager saw that Harold had been pushed over his limit and tried to swing back onto the positive tack. “But Harold,” he flattered, “there isn’t anyone else. You’re the only one who knows how to do this job. We’re depending on you.” “Then,” said Harold, with a note of mock triumph in his voice, “if I’m the only one who can do the job, why don’t you believe me when | tell you it can’t be done in that much time?’ “Because you don’t really understand the problem,’’ his manager shot back, but Harold was already out of his seat and at the door. “Look,” he said, just before leaving the deadlocked meeting. ‘‘Make

The Programming Team 85 up your minds. If I’m the only one who understands, then I’m the only one who really understands and you'll have to do it my way. If not, then you won't have any trouble replacing me. It’s your problem, not mine, SO if you’ll excuse me, I'll get back to work.” Did Harold lose his job? He didn’t, in this case; but that wasn’t really important, for he knew he could get another at least as good. If it had been important, he wouldn’t have been able to do what he did. One of the paradoxes of leadership is simply this: only the leader who is ready to step down has a real chance of success. THE TEAM IN CRISIS The life cycle of a team starts with recruitment, moves through goal setting and organizing to doing the work, and finally may end with a dissolution of the team when the work is finished or with the accep- tance of new goals. This path, however, is so studded with crises of one sort or another that the life story of a typical programming team would make the subject of a fairly interesting—if slightly unbeliev- able—novel. Indeed, it is useful to consider the work of the team in two categories—work directed at accomplishing the team goals and work directed at maintaining the effective functioning of the team in the face of the crises it meets. To social psychologists, these activities are designated as “task-oriented” and “maintenance-oriented” and have been the subject of much research. In certain types of groups, and often in programming teams, the group tends to choose two complementary leaders—a task-specialist who sets, allocates, and coordinates the work; and a maintenance-specialist, who irons out conflicts among group members or between individual goals and group goals. The designated leader, because of his role in carrying external goals into the group, is most often in the task-specialist posi- tion, although, as we know, he may be replaced by the group if he does not display the necessary competence. The maintenance-specialist —who will more often be the best-liked person in the group—can come from anywhere. He may not be a particularly good programmer in his own right, though he may well be. Very often, he will be a she. In one cross-cultural study of nuclear families—father, mother, and their children—this same division into task and maintenance activities was usually found at least in the cultural ideal. In most cultures, including ours, but not in all, the ideal father was the task-specialist and the ideal mother the maintenance-specialist. Perhaps this role for a female pro- grammer is quite a natural one in our culture. In any case, it seems quite frequent that when there is a woman on a programming team, she as-

» 86 Programming as a Social Activity sumes the role of ‘‘team-mother,” although no studies have been made to verify sex as a significant factor in choosing the maintenance-spe- cialist. There have been at least several teams where one of the women was openly referred to as the ‘“team-mother’” or “den-mother,” and there is the persistent joke in computing circles which defines “software” as “a girl programmer.” Softness is one of the terms which has been used to characterize the maintenance task, whereas hardness seems to char- acterize the one who must direct the work. Whether or not this male-female division of leadership is ultimately shown to have social-psychological validity, there is sufficient anecdotal evidence to make it a worthwhile experimental practice to place at least one woman programmer on each team, though probably not in the role of designated leader. Of course, there is no reason why a woman, as in many families, cannot take the task-specialist role; but managers should be wary of promoting a woman to be designated leader simply because she seems to be second-in-command in a team. In fact, there is no need to limit this caveat to women: if it is possible to identify the maintenance- specialist in a team, one should consider carefully before making a pro- motion which by its official nature may prejudice the leadership per- formance in that role. The replacement of a leader—or any team member—is probably the most frequent and typical crisis in the life of a team. The effect of adding or removing a member depends quite sensitively on the group structure, and many a manager has been unpleasantly surprised at the change in performance resulting from the removal or addition of an “insignificant” group member. Of course, when higher management reaches into a team to remove a member, it is often by reason of that member’s demonstrated competence, so it should not be surprising if his loss affects team per- formance. But not all lost performance can be attributed to the loss of individual talent—just as all team performance cannot be attributed to a simple sum of the team members’ work. The “democratically” organized team tends to be better able to with- stand the shock of loss of a group member—whether by promotion, resignation, illness, death, pregnancy, or a call to the cloth. Since the work is shared among the members and since there is much communi- cation among them, the hole left by the parting may hardly be noticed as team members step in as needed and apply the knowledge they had gained in working with the departed one. Conversely, it may prove more difficult for the democratically organized team to accept a new member, for there is no clearly delineated position in the structure for him to occupy. Paradoxically as it may seem to some, the democratically or- ganized team may present to outsiders a rather cold and unfriendly

The Programming Team 87 facade, whereas the members of an authoritarian team may be most warm and friendly toward a newcomer. In the authoritarian team, to the extent that all work is organized through and guarded exciusively by the leader, holes are left when a member leaves. Only the leader has the necessary information to make the new division of labor among the remaining members. If the leader is busy or away, the loss of a member can be a disaster. Gaining a member, on the other hand, can be relatively simple, for the new member merely has to go to the leader to be assigned to do “this and this and that’—each of which tasks is presumably taken from some other member. Replacement of a member is probably also easier, if the new member’s abilities closely match those of the old, for all that is required is a reassignment of specific tasks from one to the other. Nevertheless, we seldom find such neat one-for-one replacements, if only because the departing member knows a great deal about the project from his work on it. In the typical mismatch, the democratic team will probably be better equipped to reorganize the work to fit the realities of the situation. Another sort of crisis appears when the team members begin to be aware that one of their number is not able to carry his share of the load. In the democratic team, the most probable outcome is a gradual shifting of the work off of this member and onto the others. If the team is more centrally organized with a strong Single leader, removal of the member is more likely. This is not the whole picture, however, for by the time the trouble is recognized, removal may not solve anything, since there is not sufficient time to secure and train a replacement. In the democratic group, however, incompetence is not likely to go long unnoticed, because each member has many opportunities to review the work of each other member. Thus, only if the incompetence is really glaring is the authori- tarian approach likely to prove more effective. Even then, blunt removal of an incompetent member is not likely to have the most warming effect on the team morale, for even the most incompetent member may be well liked by the others. A member who is competent but who does not get along with the others can be an even more serious problem for the democratic group than an out-and-out incompetent. In an authoritarian group, such a mem- ber would not have much contact with others on a working basis anyway, so as long as he gets along adequately with the leader, he presents no particular problem. Indeed, some programmers prefer to work under a strong, centralized leader in order that they do not have to socialize with their fellow workers. But in a democratic team, an antisocial member cuts lines of communications and is a constant impediment to consensus in team meetings.

88 Programming as a Social Activity There are many means by which a team can “socialize’”’ one of its members, just as there are many possible reasons for antisocial behavior. One potential source of such behavior is a team member who is indeed much more talented than the others, for he may be unable to surpress his impatience. They, on the other hand, may be unable to appreciate or implement the types of suggestions he makes. It is possible to be too smart for programming—if the person is not smart enough to use his intelligence to modify his social behavior and methods of communication. George G. was a trainee who was brought into a diagnostic program- ming group with all signs pointing to an outstanding programming career. He had just received a Master’s degree in Mathematics with honors, and only two of the other seven team members had even gone to a university. The team was working on real-time diagnostics for a military computer, and George was assigned to write the diagnostics for a high-speed drum, which was a critical part of the system. Although this was his first real program, he developed an ingenious scheme in which the program wrote all ones on the drum and then, by analyzing the patterns of zeros read back, could indicate the exact circuit that was failing. George received high praise for this work, praise that he didn’t need because he was fully aware of how superior it was to the unimaginative work of his fellows. Indeed, George lost no opportunity of telling them about their shortcomings, as reflected in the clumsiness of their program when compared with the grace of his. In a very short time, a serious crisis was brewing in the team, and several members began to look for a way to push George out—while several others, of a different bent, began to seek new positions for themselves. Then fate intervened in the form of a visit from some military brass to inspect the new hardware. Great preparations were made for the inspection, but when the brass arrived, the computer could not be made to function. The diagnostics had all been run successfully, but the other software would not work at all. The diagnostics were rerun, but again they worked and the regular pro- grams did not. At this point, the military was getting rather petulant, and management was growing furious. Then, somebody chanced to walk behind the main frame and noticed a cable lying loose. When he casually inquired what it was, the problem was solved. The drum had not been connected to the system! The drum was hooked on, and the military was soothed with a fine demonstration and a lunch well oiled with martinis. Long after they were gone, however, the programmers on the team were still getting theirs back at George. He had failed to take into account the behavior of the drum interface when the drum was not on-line. The system was designed to give an interrupt if an unattached device was selected, but George

The Programming Team 89 had masked that off. If the interrupt was masked, a write was simply ig- nored and a read produced a string of all ones. Thus, George’s marvelous program had simply indicated that all was well with the drum, even though it was not even attached. It was a blunder that any programmer could make, and it was easily patched up. Not so George’s ego, for the other programmers took every possible opportunity to rib him. Perhaps if he hadn’t claimed such in- fallibility, his fall from the heights might not have hurt so much; but as it was, George couldn’t take it. After two weeks, he simply failed to show up one Monday morning, and that was the last that anyone ever heard of George G. It was harsh, but it was effective; and the group soon returned to its former happy state—producing unimaginative, but sound, diagnostics. Crises in a team’s life need not be associated with any particular person, but may emerge at any stage in the team life as more or less normal ‘growth stages” or in response to changed external conditions. For example, we can expect that the formation of the team will be a Critical point in its life, for it passes from a stage of no organization to some organization. Ordinarily, the team structure develops down from the top and up from the bottom, like ice cubes in a tray. This is an empiri- cal observation, but we can guess what might be the cause, since the extremes of ability in the team will be more easily recognized and sorted out from the rest. Nevertheless, there are times when, for instance, there are two potentially powerful leaders in the same team and the formation from the top goes unresolved for a long time. Ordinarily this situation will be counterproductive, but it should be easy to avoid by selecting teams properly. It may be necessary, if there are many potentially strong leaders in a project, to make more divisions into teams than when there are few—to avoid such formation conflicts. Who is a potentially strong leader? That depends, as we have seen, on the work demands placed on the team. Since these demands change throughout the life of the team, leaders may rise and fall. If there are personality difficulties in accepting such changes in team structure, inter- personal conflict will develop whenever a new stage of work is reached. Thus, the problems of setting the team structure are not solved once and for all soon after the formation of the team. Since we cannot predict exactly who will be the natural leader at which times, the ideal team would be chosen as much for interpersonal skills as programming skills, but this is rarely done. Thus, we usually find conflict manifested in numer- ous ways—but all leading to temporary decrease in productivity. The change from phase to phase of work may be rather gradual and thus mollify the conflict arising from changing structure, especially if

90 Programming as a Social Activity there is rich interaction among team members giving many small oppor- tunities for conflict resolution. Sometimes, however, changes come more quickly—perhaps instigated by some outside agency or event. Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team. Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis— leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively. We can see, then, why the democratic—or perhaps we should say “technocratic’’—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership Opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside— not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning. Indeed, once the team is selected and operating, the wise manager placed above it will adopt a “hands-off” policy with regard to its internal Structure and structure change. When, as so often happens, team mem- bers come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right. “You're right,” said the rabbi, and the man left the house beaming. Soon, however, the man’s wife appeared—even more distraught than the man had been. “What do you mean,” she insisted, “saying that my husband was right?

The Programming Team 91 You haven’t heard my side of the story.” And she proceeded to relate her side, finishing with a demand for a new judgment. “You're right,” said the rabbi, and the wife left satisfied. The rabbi’s own wife, however, was not satisfied, for she had overheard both stories and both answers. “How can you do that?” she demanded. “You told the husband that he was right and the wife that she was right. They can’t both be right.” “You’re right,” said the rabbi. SUMMARY In many programming situations, the primary working unit is a team, not an individual. Although a vast amount of experimental data about “small group behavior’ has been inherited from the social psychologists, we at present have no real studies of programming teams other than highly suggestive anecdotal material. When linked with results from social psychology, this anecdotal material can give us strong impressions of the factors affecting the life and performance of a team, factors such as:

1. Variation in individual strengths and weakness.
2. The way in which goals are set.
3. The structure of the program being produced.
4. The leadership structure imposed from the outside.
5. The gender of certain members, and the attitudes of other members about that gender.
6. The communication link between the team and the rest of its en- vironment.
7. The technical competence or incompetence of the team leader. In viewing the anecdotal material in contrast to the experimental situa- tions, we find there is one difference which should put us in a state of extreme caution. In the programming situations, the span of time and the complexity of the task performed are each orders of magnitude different from anything ever attempted in an experiment by social psychologists. Tasks in social psychological experiments take an hour or a day or a week. People may be able to suppress strong feelings if they know the time period will be short; on the other hand, they may not think it impor- tant to suppress what they feel, since they will never again see the people in their group. From comparisons between teams composed of strangers and teams composed of co-workers, we do know that short-term group behavior is influenced both by past experience with team members and the expectation of having to work with them in the future. Thus,

92 Programming as a Social Activity meaningful experimentation on programming teams is going to be a difficult job, at best. However, even the observations of ongoing teams in other areas will be of questionable application to programming unless they, too, involve ongoing intellectual work of great complexity, often under stress of time and strange working conditions. Here we have the advantage of several sources in which recent work has been done—such teams as are found in hospitals and research laboratories. But even here there is something that we have that they do not—that all-wise machine sitting there like a god in judgment of our work. When a patient recovers, it is the work of the doctor; when a patient dies, it is an act of God. But when a com- puter program doesn’t work, everyone knows—and everyone knows who is to blame. QUESTIONS For Managers

1. Are your hiring practices such that you get more uniformity on teams than you would like? When making up teams, do you try to see that a good ‘mix’ of people is on each one, or do you Strive in the opposite direction?
2. What are your feelings and practices about putting women on teams? About making women designated team leaders? Can you back up your feelings and practices with any empirical evidence?
3. In your organization, how much decision making is left to the working team members? How much “bit-picking” is there by managers? By yourself?
4. Do you ever do things to try to inflate the appearance of your technical competence in front of the people who work for you? Describe some of these incidents, and also some incidents in which it was discovered that your technical competence was in at least one respect inferior to one of the people who work for you. What were the consequences of that discovery, and do they justify attempting to cover up?
5. In setting your own working goals, what part is set by what is passed down from above, and what part is set by what comes up from below? Are you Satisfied with this arrangement, or would you like to alter it in some ways?
6. Have you ever promoted the ‘‘second-in-command” of a team to be a team leader? If so, explain your reasoning in doing so, and describe any effects you noticed afterward?
7. Have you ever been asked to serve as judge in internal team disputes? If so, describe the incident—what you did and what happened.

The Programming Team 93 For Programmers

1. What part of programming work do you do best? Are you permitted to contribute that best part of your work to your team, and is it gener- ally recognized that it is the best part of your work?
2. What part do you play in setting the goals of your team? What part would you like to play? What part would you like others to play?
3. Has your manager ever done anything to make you doubt his honesty? If so, describe the incident, what ultimately happened to your doubt, and how your work was affected.
4. Does your team have a task specialist and a maintenance specialist that you can identify? Does your team have a “team-mother?”’ If you are the “‘team-mother,” describe your experiences in that role.
5. Draw a diagram or diagrams representing the structure of your team, both formally and informally. Can you relate this diagram to the struc- ture of the program you are working on? Can you relate it to other factors? |
6. Give an account of an incident in which: a. A team leader was changed. b. A member was added to your team. c. A member left your team. d. Some crisis began to affect your team socially. Describe the reactions of the team members when the change or crisis first became known and as it happened through time. Describe any per- manent changes in team behavior—either for better or worse—that came about as a result of the change or crisis. BIBLIOGRAPHY The reader interested in further exploration for insights from social psychology could consult any of the following books with profit: Allport, F. H., Social Psychology, Boston, Houghton Mifflin, 1924. Asch, S. E., Social Psychology, Englewood Cliffs, N.J., Prentice-Hall, 1952. Lindzey, G., ed., Handbook of Social Psychology, Reading, Mass., Addison-Wesley, 1954, . Krech, D., R. S. Crutchfield, and E. L. Ballachey, /ndividual in Society, New York, McGraw-Hill, 1962. Jones, E. E. and H. B. Gerard, Foundations of Social Psychology, New York, Wiley,

Parkinson, C. Northcote, Parkinson’s Law, Boston, Houghton Mifflin, 1957. Parkinson is often cited by those who fear that making a longer schedule will simply lengthen the time it takes to do a project. Those who claim him for the

4 Programming as a Social Activity benefit of their pet idea should take the time to read the entire book and see what else there is to learn from it. Kohn, Hans, Nationalism and Liberty: The Swiss Example, London, George Allen and Unwin Ltd., 1956. A little introduction for those who have become disillusioned with the possibilities of democracy, those who have forgotten them, or those who never knew them in the first place. After reading the book, another step in re-education is to go there. Mills, H. D., Chief Programmer Teams: Techniques and Procedures, |BM Internal Report, January 1970. Hopefully, Mills will publish his ideas on Chief Programmer Teams in the general literature, so they can be compared, say, with the concept of egoless program- ming and also subject to experimental and observational tests. Briefly, the Chief Programmer Team is patterned after a ‘‘surgical team,” with the master programmer replacing the master surgeon and surrounded and supported by a Backup Pro- grammer, a Programming Librarian, and possibly additional programmers, analysts, technical writers, technicians, or other specialists. Mills claims that such an organi- zation ‘permits the application of new management standards and new technical Standards to programming projects,” but one wonders at the validity of the analogy to surgery, which is acknowledged to be one of the most backward specialties in a backward (technologically) field. Also, anyone who has known a few surgeons personally may wonder about how great a social contribution such an organization would be—it may be fine for those who fancy themselves Chief Programmers, but what about the rest of the workers? Mendelssohn, Kurt, A Scientist Looks at the Pyramids, American Scientist, V. 59, No. 2 (March-April 1971). Social structure has evidentally always been influenced by project structure, and vice versa. In this intriguing article, Mendelssohn explores how 5000 years ago_the building of the pyramids led to the invention of the state as a social structure, and how the invention of the state led to building pyramids. All project managers should take note of this message.

Silver Anniversary Notes xT Comments on Chapter 5: The Programming Team A programming team, then, should be formed in response to a work requirement that cannot be met by a single person. (p. 68) | still agree with this statement | made back in the Dark Ages, but | now inter- pret “work requirement” more broadly, to include the development of capability in the team and team members. Over the years, I’ve observed that the require- ment to develop capability cannot be met adequately by a single person. We learn much faster and much better with the active cooperation of others. “These shortcuts might succeed in getting the system working on time—but only if everything goes right, which it rarely does” (p. 68). The wisdom of age has made me ashamed of this statement. “Rarely” is pussyfooting; something always goes wrong. Shilly-shallying like this by authors like me has perpetuated the myth of the “optimistic” estimate—how long a project would take if everything went right. Such “estimating” might just as well be based on the assumption that the Laws of Thermodynamics will be repealed during the project. “In any case, the basic rule for size and composition of programming teams would seem to be this—for the best programming at the least cost, give the best possible programmers you can find sufficient time so you need the smallest number of them” (p. 69). The wisdom of that rule has been supported by all my subsequent experience, with three amendments:

Se) Silver Anniversary Notes The smallest number is never a single programmer. “Sufficient time” must include time for team formation. Therefore, there is often a great advantage to choosing an existing team with a track record. 3. It’s often an even greater advantage to get your teams started before you have a really critical problem for them to work on. No — “., the worst way to do a programming project is to hire a horde of trainees and put them to work under pressure and without supervision—although this is the most common practice today” (p. 69). Nowadays, there are more experi- enced people around, so the total-trainee project is not as common. More com- mon today is the second worst way to do a programming project: Hire a miscel- laneous horde of contractors (who may actually be trainees in disguise) and put them to work under pressure and without supervision. Or, with over-supervision. “In programming, the way a team organizes for work is most strongly deter- mined by two factors—the organization of the target system and the composition of the team” (pp. 69-70). This is still as true as it was twenty-five years ago, but | think | have learned that matching the product to the composition of the team is not as illogical as | believed back then. By composition of the team, | don’t gen- erally mean the individual skills, but the individual personalities. Individual skills are not so important on a real team that shares work all around. Even so, the number one mistake I’ve seen in team formation over the years is that of adding members to a team based on some presumed skill, rather than on compatibility of the new members with the rest of the team members. Skill may be hard to come by, but it’s always easier to buy or train than compatibility. a The example concerning establishing and accepting goals in the conversion from the IBM 704 to the IBM 709 is now, of course, ancient history. Nevertheless, over the years, I’ve heard the same story about many other conversions. In 1993, | was asked if | was really writing about conversion of an application from Microsoft PC-DOS to Microsoft Windows. My interrogator was convinced he had been on the project | described, and that | had substituted the names of old machines to protect the guilty party. Achieving consensus on a team’s goals. is as essential in 1998 as it was in 1971, or will be in 2021. That doesn’t mean that each person must have all the same goals as all other persons on the team, but that the overlapping portion must cover all the work they are doing. | guess the clearest proof | can offer about the importance of the leadership sections is that Becoming a Technical Leader—my book expanding on the con- cept of technical leadership—continues to sell well, after a dozen years. Or, per- haps the proof would be even clearer if | tell you that our Problem-Solving Leadership Workshop has put our leadership concepts to the test with thousands

Silver Anniversary Notes Pies : of leaders in software organizations all over the world for more than twenty years. In the section on team leadership, however, there is one especially shocking, politically incorrect, statement: “. . . place at least one woman programmer on each team” (p. 86). To put this sexist-sounding section in context, | must explain that more than twenty-five years ago | conducted a survey of the women pro- grammers in my advanced software development class. When | asked these students about their experiences working on teams with other women, none of them could answer—because none had ever worked on a team with another woman programmer. Twenty years ago, our typical PSL class might have had as many as four women out of twenty participants; today, it’s more likely to be eight-to-twelve out of twenty. One of my students made this telling observation about the transition period: “Even twelve years ago, programming teams were largely all male. | can still remember the first woman developer who joined the programming team | worked on. There were only two or three male team members who would even talk to her. Some of the male developers complained that having a woman program- mer around hurt their concentration. | later concluded that for most of them, hav- ing a woman around in any situation hurt their concentration and that they did not talk to her because women had stopped talking to them in junior high school.” When women programmers were rare, it was easy to make stereotypes of them. But once women became less of a novelty on programming teams, they found themselves able to assume any role that fit. Sometimes, a woman was

task leader; sometimes, a maintenance leader; sometimes, a subject-matter expert. The only deviation that | still see from this ideal of merit-driven place- ment is when managers appoint official leaders for teams. Here, unfortunately, there still remains at least a two-to-one bias toward males, a bias that keeps many teams from finding their best possible structure. Back then, | didn’t know as much as | know now about handling teams in cri- sis. Studying with family therapists such as Virginia Satir was an essential step for me, and much of what I’ve learned about dealing with crisis is captured in the third volume of the Quality Software Management series. Still, the most impor- tant lesson is that preventing a crisis is generally a lot easier than handling one—my subject in the fourth volume.

vient? Revit

haa a ¢ tena” ne er a namaw oro Jest | | nies apa yt nunotaee gabouse te eng namnew ef m yewue © betoubnco | oe a aes Capes, | a, eer Ana ths ay 19 AOR, CIR IPA, PATER OR how, SSaRRN RE 2 Ne AMBRE aE ny 1h TN APBD B f By, NG, YANG 6 Say ange 4 aber ur ‘ me bi iis re be a alae: HP “eo i SORE O och se 21081 FL NRE oh ORE ME ee BR Mi Na ee OGIO NT, Cay moneehy tye. &:

) a ae penny notice Sabyvous, Pratteynag dg, pot at, my ea eh tee Ate We svi: 1... en Shy QV, 8° ON, SIN seersisry RE OB FRR, PAP tte ‘ show } pet ey AME OOF, alt poaidjortw racolevel.s fain s/h et hal Colle neve bivow aw gedenam, tant 19% earl W048 ino aha, Cuno. BAA KEtsa A DaRiRIAAD, ppaglayad: Satentabiy > ely antsatth tea, SR HN i tacit pein 79 _peupmnnanee, test 1 mi» york tad os soiiptthannsa zat uel QORPYIR JE Re SiS Aut FOINULT ger iy a ony at isi pahint b AY HOMO: agutsed vs oa ' ' os foreiatton over tha vere i ebay lo aan ino? ate BAHN th me pon $i. 2081, OM, SABA DOIG IE , Yar, 2p Sei, QMIMMED gO 1G 10, salnyon. B io att STPRRBS NATROYE. Be | ARM, ER OW, £5 POR ORINOT Shier, pigs an mraaa, asian wan pais ans) -T G6 sal iia, BOhse] 9PHISI MEDS pio aonie iDsiathonn ‘oleae pig eee. Hite! kal negitarer, xin pena iia y met _.2opmel, ol anebael JRTo, mR, peanil Rao tertt as it > .@akern Daw, asic aor oh A ARAM {4 8 3 . | _genurqu ia, gidiaggg, sead ipa polbal oeameghy “ND 5a, amaat ‘ooiored rodgnon enti es, coum ea wet TO det gohe JApOBEs 1G 2 Tipe Binh nice ping <n by! BA, 7! nenssts 2, 4 eg -99 hogan Jam. auth fli pichagent-t arated ivdbeili COL AMGAE HB rey Hina atl et Paty we Td ory nwt or ck b quae: the hanna | ots ate alvevut dhs weotarce of 9 ranula ond Sec aretey ot Pat eras toadenaty: bak alah ned ng Swett kh site Man, fh) oan wees ; ee ern Cn ne Py Kaleb) Neuse age anil hearse a vero une 2 fs ¢ 8 bial ah {T.