Programming teams as surgical teams

An interesting idea from Fred Brooks' The Mythical Man-Month:

"At computer society meetings one continually hears young programming managers assert that they favor a small, sharp team of first-class people, rather than a project with hundredsof programmers, and those by implication mediocre. So do we all. But this naive statement of the alternatives avoids the hard problem--how does one build large systems on a meaningful schedule?" (30)

"In one of their studies, Sackman, Erikson, and Grant were measuring performance of a group of experienced programmers. Within just this groug the ratios between best and worst performances averaged about 10:1 on productivity mesurements and an amazing 5:1 on program speed and space measurements! In short, the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and performance. (I doubt if this is universally true.)" (30)

"I have earlier argued that the sheer number of minds to be coordinated affects the cost of the effort, for a major part of the cost is communication and correcting the ill effects of miscommunication (system debugging). This, too, suggests that one wants the system to be built by as few minds as possible...the problem with the small, sharp team concept: it is too slow for really big systems." (30-31)

"The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can those two needs be reconciled?" (31)

"Mills proposes that each segment of a large job be tackled by a team, but that team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him ever support that will enhance his effectiveness and productivity." (32)

"The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation. He writes in a structured programming language such as PL/I, and has effective access to a computing system which not only runs his tests but also stores the various versions of his programs, allows easy file updating, and provides text editing for his documentation. He needs great talent, ten years experience, and considerable systems and application knowledge, whether in applied mathematics, business data handling, or whatever.

The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. His main function is to share in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice. The copilot often represents his team in discussions of function and interface with other teams. He knows all of the code intimately. He researches alternative design strategies. He obviously serves as insurance against disaster to the surgeon. He may even write code, but he is not responsible for any part of the code.

The administrator. The surgeon is boss, and he must have the last word on personnel, raises, space, and so on, but he must spend almost none of his time on these matters. Thus, he needs a professional administrator who handles money, people, space, and machines, and who interfaces with the administrative machinery of the rest of the organization. Baker suggests that the administrator has a full-time job only if the project has substantial legal, contractual, reporting, or financial requirements because of the user-producer relationship. Otherwise, one administrator can serve two teams.

The editor. The surgeon is responsible for generating the documentation--for maximum clarity he must write it. The is true of both external and internal descriptions. The editor, however, takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several versions, and oversees the mechanism of production.

Two secretaries. The administrator and the editor will each need a secretary; the administrator's secretary will handle project correspondence and non-product files.

The program clerk. He is responsible for maintaining all the technical records of the team in a programming-product library. The clerk is trained as a secretary and has responsibility for both machine-readable and human-readable files. All computer input goes to the clerk, who logs and keys it if required. The output listings go back to him to be filed and indexed. The most recent runs of any model are kept in a status notebook; all previous ones are filed in a chronological archive. Absolutely vital to Mills' concept is the transformation of programming 'from private art to public practice' by making all the computer runs visible to all team members and identifying all programs and data as team property, not private property. The specialized function of the program clerk relieves programmers of clerical chores, systematizes and ensures proper performance of those oft-neglected chores, and enhances the team's most valuable asset--its work product. Clearly the concept as set forth above assumes batch runs. When interactive terminals are used, particularly those with no hard-copy output, the program clerks functions do not diminish, but they change. Now he logs all updates of team progress copies from private working copies, still handles all batch runs, and uses his own interactive facility to control the integrity and availability of the growing product.

The toolsmith. File-editing, text-editing, and interactive debugging services are now readily available, so that a team will rarely need its own machine and machine operating crew. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be the sole judge of the adequacy of service available to him. He needs a toolsmith, responsible for ensuring this adequacy of basic service and for constructing, maintaining, and upgrading special tools--mostly interactive computer services--needed by his team. Each team will need its own toolsmith, regardless of the excellence and reliability of any centrally provided service, for his job is to see to the tools needed or wanted by his surgeon, without regard to any other team's needs. the tool-builder will often construct specialized utilities, cataloged procedures, macro libraries.

The tester. the surgeon will need a bank of suitable test cases for testing pieces of his work as he writes it, and then for testing the whole thing. The tester is therefore both an adversary who devises system test cases from the functional specs, and an assistant who devises test data for the day-by-day debugging. He would also plan testing sequences and set up scaffolding required for component tests.

The language lawyer. By the time Algol came along, people began to recognize that most computer installations have one or two people who delight in mastery of the intricacies of a programming language. And these experts turn out to be very useful and widely consulted. The talent here is rather different from that of the surgeon, who is primarily a system designer and who thinks representations. the language lawyer can find a neat and efficient way to use the language to do difficult, obscure, or tricky things. Often he will need to do small studies (two or three days) on good technique. One language lawyer can service two or three surgeons.

This, then, is how 10 people might contribute in a well-differentiated and specialized roles on a programming team built on the surgical model."

" (34)

"Notice in particular the differences between a team of two programmers conventionally organized and the surgeon-copilot team. First, in a conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all of the design and all of the code...Second, in the conventional team the partners are equal, and the inevitable differences of judgment must be talked out or compromised. Since the work and resources are divided, the differences in judgment are confined to overall strategy and interfacing, but they are compounded by differences of interest...In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally."(34)

Obviously some of these concepts are dated and can be replaced by computer functions, such as the program clerk. But has this style of teach ever been effectively implemented in the literature?