4.2.1 Analysis of the Democratic Team Approach
A major strength of the democratic team approach is the positive attitude toward the fi nding of faults. The more found, the happier are the members of a democratic team. This positive attitude leads to more rapid detection of faults and hence to high-quality code. But there are some major problems. As pointed out previously, managers may have diffi culty accepting egoless programming. In addition, a programmer with, say, 15 years of experience is likely to resent having his or her code appraised by fellow programmers, especially beginners.
Weinberg feels that egoless teams spring up spontaneously and cannot be imposed from outside. Little experimental research has been done on democratic programming teams, but the experience of Weinberg is that democratic teams are enormously productive. Mantei [1981] has analyzed the democratic team organization using arguments based on theories of and experiments on group organization in general rather than specifi cally on program-ming teams. She points out that decentralized groups work best when the problem is dif-fi cult and suggests that democratic teams should function well in a research environment.
It has been my experience that a democratic team also works well in an industrial setting when a hard problem must be solved. On a number of occasions I have been a member of democratic teams that have sprung up spontaneously among software professionals with research experience. But, once the task has been reduced to the implementation of a hard-won solution, the team must then be reorganized in a more hierarchical fashion, such as the chief programmer team approach described in Section 4.3.
4.3 Classical Chief Programmer Team Approach
Consider the six-person team shown in Figure 4.2 , with 15 two-person communication chan-nels. In fact, the total number of two-, three-, four-, fi ve-, and six-person groups is 57. This multiplicity of communication channels is the major reason why a six-person team structured as in Figure 4.2 is unlikely to be able to perform 36 person-months of work in 6 months; many hours are wasted in meetings involving two or more team members at a time.
Now consider the six-person team shown in Figure 4.3 . Again, there are six program-mers, but now only fi ve lines of communication. This is the basic concept behind what now is termed the chief programmer team . A related idea was put forward by Brooks [1975], who drew the analogy of a chief surgeon directing an operation. The surgeon is assisted by other surgeons, the anesthesiologist, and a variety of nurses. In addition, when
sch76183_ch04_107-123.indd 110
sch76183_ch04_107-123.indd 110 04/06/10 12:49 PM04/06/10 12:49 PM
necessary, the team uses experts in other areas, such as cardiologists or nephrologists. This analogy highlights two key aspects of a chief programmer team. The fi rst is specialization : Each member of the team carries out only those tasks for which he or she has been trained.
The second aspect is hierarchy : The chief surgeon directs the actions of all the other members of the team and is responsible for every aspect of the operation.
The chief programmer team concept was formalized by Mills [Baker, 1972]. A classical chief programmer team, as described by Baker some 40 years ago, is shown in Figure 4.3 . It consisted of the chief programmer, who was assisted by the backup programmer, the programming secretary, and from one to three programmers. When necessary, the team was assisted by specialists in other areas, such as legal or fi nancial matters, or the job control language (JCL) statements used to give operating system commands to the mainframe com-puters of that era. The chief programmer was both a successful manager and a highly skilled programmer who did the architectural design and any critical or complex sections of the code. The other team members worked on the detailed design and the coding, under the direction of the chief programmer. As shown in Figure 4.3 , no lines of communica-tion existed between the programmers; all interfacing issues were handled by the chief programmer. Finally, the chief programmer reviewed the work of the other team members, because the chief programmer was personally responsible for every line of code.
The position of backup programmer was necessary only because the chief program-mer was human and could therefore become ill, fall under a bus, or change jobs. Therefore, FIGURE 4.2
Communication paths between six software professionals.
FIGURE 4.3 The structure of a classical chief programmer team.
Programmer Programmer
Backup programmer Chief
programmer Programming
secretary
Programmer
112 Part A Software Engineering Concepts
the backup programmer had to be as competent as the chief programmer in every respect and had to know as much about the project as the chief programmer. In addition, to free the chief programmer to concentrate on the architectural design, the backup programmer did black-box test case planning (Section 15.11) and other tasks independent of the design process.
The word secretary has a number of meanings. A secretary can be a person who assists a busy executive by answering the telephone, typing correspondence, and so on. But when we talk about the American Secretary of State or the British Foreign Secretary, we refer to one of the most senior members of the Cabinet. The programming secretary was not a part-time clerical assistant but a highly skilled, well-paid, central member of a chief programmer team. The programming secretary was responsible for maintaining the project production library, the documentation of the project. This included source code listings, JCL, and test data. The programmers handed their source code to the secretary, who was responsible for its conversion to machine-readable form, compilation, linking, loading, execution, and running test cases. Programmers therefore did nothing but program. All other aspects of their work were handled by the programming secretary. (Because the pro-gramming secretary maintained the project production library, some organizations used the title librarian .)
Recall that what is described here are Mills’s and Baker’s original ideas, dating back to 1971, when keypunches still were widely used. Coding no longer is done that way. Pro-grammers now have their own terminals or workstations in which they enter their code, edit it, test it, and so on. A modern version of the classical chief programmer team is described in Section 4.4.
4.3.1 The New York Times Project
The chief programmer team concept was fi rst used in 1971 by IBM to automate the clip-ping fi le (“morgue”) of The New York Times. The clipclip-ping fi le contains abstracts and full articles from The New York Times and other publications. Reporters and other members of the editorial staff use this information bank as a reference source.
The facts of the project are astounding. For example, 83,000 lines of code (LOC) were implemented in 22 calendar months, an effort of 11 person-years. After the fi rst year, only the fi le maintenance system consisting of 12,000 LOC had been implemented. Most of the code was implemented in the last 6 months. Only 21 faults were detected in the fi rst 5 weeks of acceptance testing; only 25 further faults were detected in the fi rst year of operation. Principal programmers averaged one detected fault and 10,000 LOC per person-year. The fi le main-tenance system, delivered 1 week after coding was completed, operated 20 months before a single fault was detected. Almost half the subprograms, usually 200 to 400 lines of PL/I, a language developed by IBM, were correct on the fi rst compilation [Baker, 1972].
Nevertheless, after this fantastic success, no comparable claims for the chief program-mer team concept have been made. Yes, many successful projects have been carried out using chief programmer teams, but the fi gures reported, although satisfactory, are not as impressive as those obtained for The New York Times project. Why was The New York Times project such a success, and why have similar results not been obtained on other projects?
One possible explanation is that this was a prestige project for IBM. It was the fi rst real trial for PL/I. An organization known for its superb software experts, IBM set up a team comprising what can only be described as its crème de la crème from one division. Second,
sch76183_ch04_107-123.indd 112
sch76183_ch04_107-123.indd 112 04/06/10 12:49 PM04/06/10 12:49 PM
technical backup was extremely strong. PL/I compiler writers were on hand to assist the programmers in every way they could, and JCL experts assisted with the job control lan-guage. A third possible explanation was the expertise of the chief programmer, F. Terry Baker. He is what is now called a superprogrammer , a programmer whose output is four or fi ve times that of an average good programmer. In addition, Baker is a superb manager and leader, and his skills, enthusiasm, and personality could be the reasons underlying the success of the project.
If the chief programmer is competent, then the chief programmer team organization works well. Although the remarkable success of The New York Times project has not been repeated, many successful projects have employed variants of the chief programmer approach. The reason for the phrase variants of the approach is that the classical chief pro-grammer team as described in [Baker, 1972] is impractical in many ways.
4.3.2 Impracticality of the Classical Chief Programmer Team Approach
Consider the chief programmer, a combination of a highly skilled programmer and suc-cessful manager. Such individuals are diffi cult to fi nd due to a shortage of highly skilled programmers as well as a shortage of successful managers; and the job description of a chief programmer requires both abilities. Also, the qualities needed to be a highly skilled programmer appear to be different from those needed to be a successful manager; there-fore, the chances of fi nding a chief programmer are small.
If chief programmers are hard to fi nd, backup programmers are as rare as hen’s teeth.
After all, the backup programmer is expected to be as good as the chief programmer but has to take a backseat and a lower salary while waiting for something to happen to the chief programmer. Few top programmers or top managers would accept such a role.
A programming secretary also is diffi cult to fi nd. Software professionals are notorious for their aversion to paperwork, and the programming secretary is expected to do nothing but paperwork all day.
Therefore, chief programmer teams, at least as proposed by Baker, are impractical to implement. Democratic teams also were shown to be impractical but for different reasons.
Furthermore, neither technique seems to be able to handle products that require 20, let alone 120, programmers for the implementation workfl ow. What is needed is a way of organizing programming teams that uses the strengths of democratic teams and chief pro-grammer teams and can be extended to the implementation of larger products.