The Effect of Programming Team Structures on Programming Tasks Marilyn Mantei the University of Michigan

COMPUTING PRACTICES

The Effect of Programming Team Structures on Programming Tasks Marilyn Mantei The University of Michigan

1. Introduction SUMMARY: The literature recognizes two group structures Two philosophies for organizing programming teams have achieved a for managing programming projects: Baker's chief program- moderate amount of popularity, if mer team and Weinberg's egoless team. Although each struc- not utilization, in the data processing ture's success in project management can be demonstrated, field. These are the egoless program- this success is clearly dependent on the type of programming ming team proposed by Weinberg task undertaken. Here, for the purposes of comparison, a [28] and the chief programmer team third project organization which lies between the other two in proposed by Mills [18] and imple- mented by Baker [1]. In Weinberg's its communication patterns and dissemination of decision- structure, the decision-making au- making authority is presented. Recommendations are given thority is diffused throughout project for selecting one of the three team organizations depending membership; in Baker's team, it be- on the task to be performed. longs to the chief programmer. Com- munication exchanges are decentralized in Weinberg's team and centralized in the chief programmer organization. Neither structure is totally decentralized, democratic, central- alyze Weinberg and Baker's organi- ized, or autocratic, but both Wein- zations. In Section 4, a third, com- Permission to copy without fee all or part of this material is granted provided that the cop- berg and Baker present arguments monly encountered team organiza- ies are not made or distributed for direct on why their methods will lead tion is presented for the purposes of commercial advantage, the ACM copyright to superior project performance. comparison. The fifth section con- notice and the title of the publication and its date appear, and notice is given that copying Baker's project succeeds with a spe- ducts this comparison, recommend- is by permission of the Association for Com- cific, difficult, and highly structured ing which of the three structures puting Machinery. To copy otherwise, or to task. Weinberg's recommendations should be selected for a given prop- republish, requires a fee and/or specific permission. have no specific task in mind. erty of a programming task. Key words and phrases: chief programmer Research conducted in small team, project management, software engineer- group dynamics [7, 23, 27] suggests ing, group dynamics, programming team 2. An Analysis of Weinberg's structures that a decision to use either team CR Categories: 3.50, 4.6 structure is not clear-cut and that Team Structure Author's address: M. Mantei, Graduate there are strong task dependencies Weinberg is a promoter of the School of Business Administration, The Uni- versity of Michigan, Ann Arbor, MI 48109. associated with each group's per- egoless programming concept. His © 1981 ACM 0001-0782/81/0300-0106 75¢. formance. The next two sections an- teams are groups of ten or fewer

106 Communications March 1981 of Volume 24 the ACM Number 3 oJ°\o/ Individual programmers have varying skill levels and areas of expertise. 0 0 C (a) Management Structure (b) Communication Channels

Fig. 1. Egoless Team Structure. Authority is dispersed and communication linkages decentralized.

programmers who exchange their berg's proposal is the risky shift phe- superior. March and Simon [16] code with other team members for nomena [5]. Groups engage in riskier point out that hierarchical structures error examination. In addition to behavior than individuals, both be- are built to limit the flow of infor- code exchanges, goals are set by cause of the dispersion of failure and mation, because of the human group consensus. Group leadership the high value associated with risk mind's limited processing capabili- is a rotating function, becoming the taking in Western culture. In the case ties. In the decentralized groups, as responsibility of the individual with of a group programming team, deci- investigated by Bavelas, although the abilities that are currently sions to attempt riskier solutions to twice as many communications were needed. Figure l(a) illustrates the a software problem or to establish exchanged as in centralized groups, basic management structure of an high risk deadlines would be more the groups often failed to finish their egoless team; Figure l(b) shows the easily made. In a software project task. Similarly, individuals within a communication exchanges that occur with a tight deadline or a crucial nonstructured programming group within this structure. The team pro- customer, a group decision might may be unable to organize project posed by Weinberg is acknowledged cause the project to fail. information effectively and many to be mythical in light of today's The democratic team structure suffer from information overload. organization practices, but Weinberg works best when the problem is dif- The structure and limited flow asso- feels that it is the appropriate orga- ficult. When the problem is simple, ciated with hierarchical control may nization for the best qualitative and performance is better in an auto- be assets to information assimilation. quantitative code generation. Using cratic highly structured group [12]. Decentralized groups exhibit the factors of amount of code pro- Ironically, democratic groups at- greater conformity than centralized duced, of time to produce code, and tempt to become more autocratic as groups [11]; they enforce a uniform- of error freeness to gauge program- task difficulty increases. In the de- ity of behavior and punish deviations ming performance, some task-related centralized group, the additional from the norm [20]. This is good if it problems occur with Weinberg's communication which aided in solv- results in quality documentation and team structure. ing the difficult problem is superflu- coding practices, but it may hurt ex- Bavelas [3] and Leavitt [14], in ous; it interferes with the simple perimental software development or their experiments on centralized and problem solution. Tasks such as re- the production of novel ideas. decentralized group problem-solving port generation and payroll pro- Despite the pressure to conform behavior, found that decentralized gramming fall into the category of and an apparent lack of information groups take more time and generate simple tasks--for these, a Weinberg organization, decentralized groups twice as many communications as group is least efficient. exhibit the greatest job satisfaction centralized groups. This suggests that The decentralized group is [23]. For long projects hurt by high a Weinberg group would function lauded for its open communication turnover rates, job satisfaction is a well in long-term continuing projects channels. They allow the dissemina- major concern. Job satisfaction is without time constraints (such as tion of programming information to also important for healthy relation- program maintenance). It would not, all participants via informal chan- ships with the public or a customer-- however, adequately perform a rush nels. By virtue of code exchanges and if indeed this is a necessary element programming project. open communication, Weinberg of the programming project. A second weakness of Wein- concludes that the product will be In summary, Weinberg's decen-

107 Communications March 1981 of Volume 24 the ACM Number 3 COMPUTING through a programming library sys- the effective chief programmer is a tem, which contains up-to-date in- rare individual and indicates that PRACTICES formation on all code developed. most so-called chief programmer The program librarian maintains the teams are headed by someone who library and performs clerical support is unlikely to adequately handle the for the project. Rigid program stan- communication complexity. tralized democratic group does not dards are upheld by the chief pro- Centralized groups exhibit low perform well in tasks with time con- grammer. morale [3]; this, in turn, leads to dis- straints, simple solutions, large infor- The Baker team is a centralized satisfaction and poor group cohe- mation exchange requirements, or autocratic structure in which prob- siveness. Members of highly cohesive unusual approaches. A difficult task lem solutions and goal decisions are groups communicate with each other of considerable duration which de- made at the top level. The task which to a greater extent than members of mands personal interaction with the the team undertakes is well-defined, groups with low cohesion [15]. With customer is optimal for a Weinberg but large and complex. Definite time a clearly defined problem that is split team. constraints exist. Baker concludes into distinct modules, this lack of that this compact highly structured communication will have little im- 3. An Analysis of Baker's Team team led to the successful completion pact, but an ill-defined problem with Structure of the project and that it has general many interfaces would suffer in a Baker describes the use of a applicability. chief programmer team environ- highly structured programming team Several weaknesses exist in ment. The two software modules (the to develop a complex on-line infor- Baker's argument. Shaw [21] finds interface systems) on this project mation retrieval system for the New that a centralized communication which might have served as indica- York Times Data Bank; the team is network is more vulnerable to satu- tors of this communication condition a three-person unit. It consists of a ration at the top level. Information are, as a matter of fact, developed as chief programmer, who manages a from all lower modes in this structure a joint effort between the chief pro- senior level programmer and a pro- flows upward to the parent mode. grammer and another team member. gram librarian. Additional program- Baker's team was intentionally small Communication in a status hier- mers and analysts are added to the and worked with a highly structured archy tends to be directed upward; team on a temporary basis to meet system for managing project infor- its content is more positive than that specific project needs. Figure 2(a) mation; both these factors were crit- of any communication directed illustrates the structure of the chief ical to the success of the project. A downward [27]. In a tricky, difficult programmer team; the communica- third, equally important factor was programming task, this favorable tion channels are shown in Figure the team leader's ability to handle one-way flow of communication 2(b). project communication. This ability denies the group leader access to a The chief programmer manages is closely related to the leader's soft- better solution or, at least, an indi- all technical aspects of the project, ware expertise. A less experienced cation of problems in the current reporting horizontally to a project leader or a more complex problem solution. Decentralized groups gen- manager who performs the adminis- might have changed the project's erate more and better solutions to trative work. Program design and as- success, even with staffing con- problems than individuals working signment are initiated at the top level straints and information manage- alone [25]--such as a chief program- of the team. Communication occurs ment. Yourdon [29] points out that mer. The major basis for the success

\ Chief Programmer 0/(,~ ~ \ \ \ \ \\ \ \ \ Librarian Special Problems O o "o Consultant "o Programmers

(a) Management Structure (b) Communication Channels Fig. 2. Chief ProgrammerTeam Structure. Authority is vested in the chief programmerand communicationis centralizedto this individual.

108 Communications March 1981 of Volume 24 the ACM Number 3 (~) ProjectLeader

0 SeniOrPrOgrammers /IX 0 0 0 0 0 0 JpU°ig°rrmmers

(a) ManagementStructure (b) CommunicationChannels Fig. 3. Controlled DecentralizedTeam Structure. Authority is vested in the project leader and senior programmers, but communication at each level of the managementhierarchy is decentralized.

of the New York Times Data Bank that draws from both Weinberg's The CD team possesses control project was the team's ability to meet egoless team and Baker's chief pro- over the goal selection and decision- the delivery date. A centralized grammer team. A third, frequently making aspects of the Baker team structure completes tasks more used organization which we will call and the decentralized communica- quickly than any decentralized form the controlled decentralized (CD) tion aspects of the Weinberg team. of control [14], but perhaps a more team is described in this section. Setting project goals and dividing creative solution might have resulted The controlled decentralized work among the groups are the tasks from a different approach. Propo- team has a project leader who gov- of the project leader. More detailed nents of good software management erns a group of senior programmers. control over the project's functions is stress concern for the software life Each senior programmer, in turn, assigned to the senior programmers. cycle [8, 9, 13]. This implies that manages a group of junior program- Within each programming subgroup, consideration be given not only to mers. Figure 3(a) illustrates the or- the organization is decentralized. project completion schedules but to ganization of this group; Figure 3(b) Problem solving is a group activity the software's usability, cost to the indicates the flow of communication as is checking for code errors. Each customer, and modifiability. that takes place in this type of group group leader serves as the sole recip- In summary, communication ex- structure. ient or gatekeeper of project infor- ists to a much lesser degree in cen- Metzger [17] describes this orga- mation for the subgroup and acts as tralized groups and is directed to- nization as a reasonable manage- a liaison with the leaders of the other ward the manager. Both difficult ment approach. He makes two rec- groups. The communication and tasks requiring multiple inputs for ommendations: First, he suggests control problems of the egoless and solution and unstructured tasks re- that intermediate levels of manage- chief programmer teams do not dis- quiring substantial cooperation fare ment are preferable to requiring all appear in a CD structure but occur poorly in this kind of communication senior programmers to report to the in the subgroups of the controlled environment. Group morale and, project leader and, second, he rec- decentralized team that correspond thus, goal motivation are low in such ommends that the programming to the Weinberg and Baker teams: a hierarchical structure. A simple, groups be partitioned not according Thus, the properties of the subtask well-structured programming task to code module assigned, but in allocated to any of the subgroups with rigid completion deadlines and terms of the type of role played in interact, in a similar fashion, with little individual interface with the the project, e.g., test, maintenance, the subgroup structure. client is perfect for the chief pro- etc. Shneiderman [24] lists this struc- The decentralized subgroups of grammer team. ture as the most probable type of the CD team work poorly with project organization. Like Yourdon highly structured or simple tasks. 4. An Analysis of a Controlled [29], he suggests that the individual Group solutions are best directed at Decentralized Team Structure subgroups in the project participate difficult problems. Much of the cre- In practice, programming team in structured walkthroughs and code ative and difficult part of program- structures vary considerably. Most exchanges in the manner of Wein- ming is planning the design and par- take on some form of organization berg's egoless teams. titioning the work. In the CD struc-

109 Communications March 1981 of Volume 24 the ACM Number 3 COMPUTING Programming tasks that are not A data management system for the easily subdivided suffer in a CD same purpose has a low degree of PRACTICES team. Note in Figure 3(b) that com- modularity. munication between groups occurs at (5) Reliability. Some tasks such as the senior programmer level. Proj- patient monitoring systems have severe failure penalties, while other ture this work is completed by the ects requiring micro-decision com- tasks, such as natural language pro- project leader. The senior program- munication about code interfaces cessing experiments, need not be as mers then take on their portion of cannot expect this communication to reliable, although working programs the task and develop a group solu- be conveyed effectively through a are always desirable. The reliability tion. Ironically, when the task is most liaison person functioning at a macro measure depends on the social, fi- difficult, the team structure is least level in the project. nancial, and psychological require- effective. A poll of programming In summary, the controlled de- ments of the task. managers and academics indicated centralized team will work best for that the area they believed needed large projects which are reason- (6) Time. How much time is re- the most attention in software engi- ably straightforward and short-lived. quired for task completion? Is the neering was the planning and design Such teams can be expected to pro- time adequate or is there time pres- stage [26], the work carried out by duce highly reliable code but not sure? The penalty for not meeting a the CD team project leader. necessarily on time or in a friendly deadline strongly affects this mea- With small problems, the CD manner. They are ill-suited for long- sure. team is unnecessary since its very term researchlike projects. (7) Sociability. Some program- structure presumes the existence of a ming tasks require considerable Team Structure and larger project. As Brooks [6] points communication with the user or with Programming Task Relationships out, even though adding individuals other technical personnel, such as to a project increases the communi- This section describes seven sa- engineers or mathematicians, while cation problems and, thus, the effec- lient properties of programming other tasks involve interaction with tiveness of the project's members, it tasks and compares the performance the team alone. Computer center is still necessary to have large teams of each team structure discussed in consulting groups that develop user for those programming tasks which relationship to these task properties. aids have higher sociability require- are so large they could not be accom- The relevant properties are: ments than groups programming plished in a reasonable length of time (1) Difficulty. The program re- their own set of software tools. by a few programmers. quired to solve the problem can be Throughout this paper, the labels Although control over projects is complex, consisting of many decision egoless programming team and chief exercised from above, the group points and data interfaces, or it may programmer team have prevailed. problem-solving approach at lower be a simple decision tree. Distributed For the purposes of comparison, levels will take longer, and projects processing systems and projects with these terms have been changed to will be more likely to fall behind in severe core or rapid response time names reflecting the decision-mak- meeting deadlines. The structure of constraints fall into the difficult cat- ing authority and communication the CD team would tend to centralize egory. Much of the scientific pro- structure of the teams. The three the egoless programming subgroups. gramming would come under the teams are: Because of the senior programmer's simple category heading. gatekeeper role, he or she would 1. Democratic Decentralized (2) Size. Programs may range emerge as an informal leader in (DD). This group is like Weinberg's from ten to hundreds of thousands group sessions. This, in turn, would proposed team; it has no leaders, but of lines of code for any given project. lower individual satisfaction with the appoints task coordinators for short project and generate the ensuing (3) Duration. The lifetime of the durations. Decisions on problem so- problems of a high job turnover rate programming team varies. Mainte- lutions and goal direction are made and group socialization difficulties. nance teams have a long lifetime; by group consensus. Communication Because of this strong tendency to- one-shot project teams have a short among members is horizontal. ward centralization, shorter projects lifetime. 2. Controlled Decentralized ( CD). are best for the CD structure. (4) Modularity. If a task can be The CD group has a leader who A controlled decentralized team completely compartmentalized into coordinates tasks. Secondary man- is an effective error-purge mecha- subtasks, it is highly modular. Most agement positions exist below that of nism. The code walkthroughs and programming problems can be split the leader. Problem solving remains group input at the code generation into subtasks, but the amount of a group activity but partitioning the level will filter out many errors. Code communication required between problem among groups is a task of generated in this fashion is more re- the subtasks determines their modu- the leader. Communication is decen- liable than code coming from a chief larity rating. A tape system for pay- tralized in the subgroups and cen- programmer team operation. roll reports is a highly modular task. tralized along the control hierarchy.

!!0 Communications March 1981 of Volume 24 the ACM Number 3 Table I. Recommended Team Structures for Programming Task Features.

Programming Task Characteristics Difficulty Size Duration Modularity Reliability Time Required Sociability

Group Structures High Low Large Small Short Long High Low High Low Strict Lax High Low Democratic X X X X X X X Decentralized Controlled Decentralized X X X X X X X Controlled Centralized X X X X X X X

3. Controlled Centralized (CC). DD group performs better because solutions to problems. A CC group of its high level of communication. is more error-prone and probably This group is like Baker's team. Both For very small tasks, the CC group is should never be used for projects in problem solving and goal directions best because it does not require the which relatively simple errors can are generated by the team leader. additional communication of demo- result in disaster. Communication is vertical along the cratic groups; but then, a group is path of control. A decentralized group takes unnecessary. An individual will do. longer to complete a problem than a The expected interaction of each The duration of the task interacts centralized group. If tasks have se- of these team structures with the fac- with group morale. Short tasks may vere time constraints, a CC team is tors governing program tasks can be not require high group morale, best. When time is not crucial, the drawn from experimental research whereas long tasks will suffer from low motivation of CC groups can on small group dynamics. To assess high personnel turnover if morale is interfere with task completion. performance quality, team structures low. DD groups have high morale Therefore, the more democratic are assumed to be evaluated on the and high job satisfaction. This groups are preferred, with the DD quality of generated code and the should be the preferred group struc- structure being the best choice. time in which the code generation ture for ongoing tasks. The CC and If a task requires high sociability, was completed. CD groups are effective for short- the DD team structure is best. Table I lists recommended group term tasks. Groups learn faster than individuals structures for each task variable. Un- If task modularity is low, the DD (such as the team leaders of CC der the category task difficulty, sim- group performs best because of its groups). Therefore, a DD group ple problems are best performed by higher volume of communication. would understand a user's interface a centralized structure which com- Cooperative (read DD) groups have problem in a shorter period of time. pletes tasks faster. Decentralization higher orderliness scores than com- DD groups are higher in social inter- works best for difficult problems. petitive (read CC) groups [10]. This action and morale than CD or CC Groups are found to generate more orderliness is essential for maintain- groups. These traits will enhance and better solutions than individuals. ing the interfaces of a low modularity their social relationships with the Unfortunately, the CD team is cen- task. Nondirective leadership has task contacts. tralized precisely where the problem been found to be most effective when is difficult. The DD team is the best a task has a high multiplicity of so- 6. Conclusion solution for difficult problems. For lutions. Directive leadership is best Many programming task features simpler programming tasks, a CC or for tasks with low multiplicity solu- interact with each other, e.g., a large CD structure is recommended. tion choices [22]. ADD group can project is often a difficult one. Group As programming tasks increase be characterized as having nondirec- structures that are effective for one in size, the amount of cooperation tive leadership, CC and CD groups aspect of a task may be totally wrong required among group members in- as having directive leadership. High for another. In selecting a team struc- creases. Group performance is neg- modularity tasks have a low multi- ture, it is important to use a decision- atively correlated with the coopera- plicity of solutions, and thus the CD making algorithm to prioritize, tion requirements of a task. As tasks and CC groups can be expected to weight, or combine the crucial task become very large, the DD group is exhibit the best performance given variables. no longer viable because of its co- such tasks. Little experimental work on pro- operation requirements. CC and CD CC and CD groups perform well gramming team and task interaction groups can be effectively regrouped when confronted with high reliabil- has been carried out. Basili and Rei- into smaller structures to handle the ity requirement problems. Decen- ter [2] found relationships between task. When the task size requires a tralized groups have been found to the size of a programming group and smaller number of programmers, the make less errors and produce better several software metrics. They also

111 Communications Lrch 1981 of v olume 24 the ACM Number 3 3. Bavelas, A. Communication patterns in group influence on group members in three COMPUTING task-oriented groups. J. Acoustical Soc. organization structures: a star, a fork, and a America 22 (1950), 725-730. Bavelas de- chain. Individuals holding central positions PRACTICES scribes an experiment in which the commu- were influenced less than other group mem- nication structures of a circle, wheel, and bers. chain were imposed on small groups by the 12. Guetzkow, H., and Simon, H.A. The im- physical arrangement of cubicles and mes- pact of certain communication nets upon or- found cost differential behavior aris- sage slots. Each structure was then measured ganization and performance in task-oriented ing from the software development for its problem-solving efficiency. groups. Mgmt. Sci. 1 (1955), 233-250. The 4. Becker, H. Vitalizing sociological theory. authors establish three communication struc- approach taken, with structured Amer. Sociological Rev. 19 (1954), 377-388. tures: all-channel, wheel, and circle; they techniques being notably cheaper. Becker refers to the small group laboratory then examine their effect on solving a rela- Only one programming task was per- studies as "cage studies" and recommends tively simple communication problem. The their use by sociological theorists only for an restrictions of the wheel organization aided formed by the experimental groups. awareness of such studies' limiting condi- the solution process, whereas those of the Weinberg's suggestions on group or- tions. circle hindered it. The lack of restrictions in ganization are anecdotal and Baker's 5. Bem, D.J., Wallace, M.A., and Kogen, the all-channel case also hurt the solution process. conclusions are confounded by the N. Group decision making under risk of adversive consequences../. Personality and So- 13. Jensen, R.W., and Tonies, C.C., Eds. team personnel and the program- cial Psyehol. 1 (1965), 453-460. This paper Software Engineering. Prentice-Hall, Engle- ming methods selected. demonstrates, in a context of adversive con- wood Cliffs, N.J., 1979. Here, several break- Most of the research on group sequences (loss of money, induced nausea, downs of what constitutes a software life cy- etc.), that unanimous group decisions con- cle are presented. The authors indicate that if problem-solving behavior was con- cerning matters of risk shift toward greater the customer-use phase is included in this ducted in a laboratory setting with risk-taking than individual decisions. More- breakdown, the time spent on the code de- students and tasks of short duration. over, the authors provide evidence that the velopment constitutes a relatively small por- underlying process for the risky shift is a tion of the project. A problem exists in trying to apply diffusion of the responsibility among group 14. Leavitt, H.J. Some effects of certain these conclusions to the external members. communication patterns on group perform- work environment. In particular, 6. Brooks, F.P., Jr. The Mythical Man- ance. J. Abnormal and Social Psychol. 46 programming tasks generally involve Month: Essays on Software Engineering. Ad- (1951), 38-50. Leavitt compares problem- dison-Wesley, Reading, Mass., 1975. This solving effectiveness in both wheel and circle an entirely different time span than work is a lyrical, enjoyable, and sage discus- communication structures. The wheel struc- laboratory experiments. Becker [4] sion of the problems and pitfalls that beset a ture was faster but the circle structure ac- scathingly criticizes these "cage" ex- mammoth software project--developing the counted for fewer errors. IBM 360 operating system. 15. Lott, A.J., and Lott, B.E. Group cohe- periments. Rogers [19] suggests sub- 7. Cartwright, D., and Zander, D., Eds. siveness, communication level, and conform- stituting network analysis field work Group Dynamics: Research and Theory. 3rd ity. J. Abnormal and Social Psychol. 62 to understand the effects of group edition, Harper and Row, N.Y., 1968. This (1961), 408-412. This paper describes an experiment in which groups were scored on structures. serves as an excellent compendium of the spurt of group dynamics research activity in cohesiveness and then tallied for the amount None of these task/structure rec- the late 1950s which laid the groundwork for of communication generated in a discussion ommendations have been tested in a what we know about group behavior today. session. Highly cohesive groups communi- cated more. software development environment. 8. Cave, W.C., and Salisbury, A.B. Con- trolling the software life cycle--The project 16. March, J.G., and Simon, H.A. Organiza- Despite all these shortcomings, the management task. 1EEE Trans. Soft. Engr. tions. Wiley, New York, 1958. March and application of a body of research on SE-4, 4 (July 1978), 326-334. This paper de- Simon focus on the members of formal orga- group dynamics to the organization scribes project management methods for nizations as rational men. From this, they controlling the life cycle of large software point out that the basic features of organiza- of personnel on a programming proj- systems distributed to multiple users. It em- tional structure and function derive from ect is a step forward from the hit- phasizes responding to user satisfaction and characteristics of the human problem-solving and-miss guessing that is the current user requirements and suggests methods to process and rational choice. establish and maintain control in an ex- 17. Metzger, P.W. Managing a Programming state of the art. tended dynamic environment. Project. Prentice-Hall, Englewood Cliffs, 9. De Roze, B.C., and Nyman, T.H. The N.J., 1973. Metzger suggests a project organi- References soft(rare life cycle--A management and zation constrained in terms of the types of 1. Baker, F.T. Chief programmer team technological challenge in the department of tasks that are undertaken in the development management of production programming. defense. IEEE Trans. Soft. Engr. SE-4, 4 of a software system. He goes on to describe IBM Syst. J. 1 (1972), 57-73. Baker presents (July 1978), 309-318. De Roze and Nyman how these tasks should be managed via this a case history of a program project manage- describe the software life cycle management hierarchical arrangement. ment organization, the chief programmer policy and practices that have been estab- 18. Mills, H.D. Chief programmer teams: team. This compact management strategy lished by the Department of Defense for im- Principles and procedures. IBM Rep. FSC coupled with top-down program develop- proving the software development process. 71-5108, IBM Fed. Syst. Div., Gaithersburg, ment methods achieves above average suc- 10. Deutsch, M. The effects of cooperation Md., 1971. Mills suggests that the large team cess in terms of productivity and error-free and competition upon group process. Human approach to programming projects could code. Relations 2 (1949), 129-152, 199-231. eventually be replaced by smaller, tightly or- 2. Basili, V.R., and Reiter, R.W., Jr. The Deutsch describes an experiment which es- ganized and functionally specialized teams investigation of human factors in software tablishes two forms of group relationships, led by a chief programmer. development. Comptr. 12, 12 (Dec. 1979), cooperative and competitive. Besides better 19. Rogers, E.M., and Agarwala-Rogers, R. 21-38. This paper examines the impact of a communication, increased orderliness and Communication in Organizations. Free Press, programming team's size and program devel- higher productivity result when the coopera- N.Y., t976. The basic research on group opment approach, disciplined or ad hoc, on tive group relationship exists. structures in small group network communi- the software product. The disciplined ll. Goldberg, S.C. Influence an d leadership cation is summarized and critiqued in a thor- method resulted in major savings in develop- as a function of group structure. J. Abnormal oughly readable manner. ment efficiency and smaller groups built and Social Psychol. 51 (1955), 119-122. The 20. Schachter, S. Deviation, rejection and larger code modules. experiment described in this paper compares communication. J. Abnormal and Social Psy-

112 Communications March 1981 of Volume 24 the ACM Number 3 chol. 46 (1951), 190-207. This article de- 24. Shneiderman, B. Software Psychology. rated as unimportant; planning received the scribes an experiment in which three group Winthrop, Cambridge, Mass., 1980. Shnei- highest ratings. members were paid to respectively 1) deviate derman discusses the good and bad points of 27. Thibaut, J.W., and Kelley, H.H. The So- from, 2) follow, and 3) change over to the the Weinberg and Baker teams and a third cial Psychology of Groups. Wiley, N.Y., 1959. group position taken on an issue. Groups conventional team. He notes that an egoless The second section of this book presents a with high cohesiveness scores produced team may be difficult to maintain and a general theory for group formation and greater rejection only of the deviant individ- competent chief programmer hard to find, group dynamics--in particular, the status ual. concluding that the currently existing con- systems within groups, conformity require- 21. Shaw, M.E. Some effects of unequal dis- ventional organization has strong chances for ments, group goal setting behaviors, and the tribution of information upon group per- successful projects--especially with a compe- roles played by individuals within the group. formance in various communication nets. J. tent manager. In all, not light reading for the nonsociolo- Abnormal and Social Psychol. 49 (1954), 547- gist. 553. In this paper, the amount of indepen- 25. Taylor, D.W., and Faust, W.L. Twenty questions: Efficiency of problem solving as a 28. Weinberg, G. The Psychology of Com- dence and, thus, individual satisfaction are puter Programming. Van Nostrand Reinhold, examined in various group structures. Low function of the size of the group. J. Experi- mental Psychol. 44 (1952), 360-363. Taylor N.Y., 1971. Weinberg provides homilies, ad- centralization in groups led to member satis- vice, and some wisdom about the psychologi- faction. compares individual problem-solving to group problem-solving in a game of 20 ques- cal considerations of the programming pro- 22. Shaw, M.E., and Blum, J.M. Effects of tions. Even after several days of practice, cess. It is here that he suggests the egoless leadership styles upon performance as a groups of two and four individuals asked less approach to programming and discusses its function of task structure. J. Personality and questions to discover an answer than sole potential advantages--Weinberg is short on Social Psychol. 3 (1966), 238-242. Shaw and participants. supportive research, but the book is fun to Blum describe an experiment in which they read. manipulated the leadership of two groups to 26. Thayer, R.H., Pyster, A., and Wood, 29. Yourdon, E. Managing the Structured be nondirective or directive. Given three R.C. The challenge of software engineering Technique. Prentice-Hall, Englewood Cliffs, tasks of varying solution multiplicity, direc- project management. Comptr. 13, 8 (Aug. N.J., 1976. Yourdon discusses the chief pro- tive leadership performed best with low mul- 1980), 51-59. The three authors report on a grammer team and Weinberg's egoless de- tiplicity tasks. survey of software project management ex- bugging techniques in a complete scenario 23. Shaw, M.E. Group Dynamics: The Psy- perts who were asked to indicate the most for project management. He labels the chief chology of Small Group Behavior. McGraw- important issues facing software engineering. programmer team impractical because of the Hill, N.Y., 1971. The structure of programming projects was dearth of true chief programmers.

113 Communications March 1981 of Volume 24 the ACM Number 3