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 decentral- ized in Weinberg's team and central- ized in the chief programmer orga- nization. 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 per- mission. 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.