The Mythical Man-Month – Extracts II

Source: The Mythical Man-Month

How to take forward really big projects

Small sharp team concept is not a viable solution because it is too slow. So we have to find other options.

The dilemma

For efficiency and conceptual integrity, one prefers a few good minds doing design and construction.
For large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance.
So how can these two needs be reconciled?

Harlan Mills's Proposal

Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team and not a hog-butchering team.

Surgical team

One does the cutting and the others give him every support that will enhance his effectiveness and productivity.

Hog-butchering team

Each member cutting away on the problem.

Surgical Team - Roles and work division

The following are the roles of 10 people that contribute in well differentiated and specialized roles on a programming team built on the surgical model:

The surgeon

Mills calls him a chief programmer. He needs great talent, ten years experience, and considerable systems and application knowledge, whether in applied mathematics, business data handling, or whatever.

His main responsibilities are:

• Defines the functional and performance specifications .
• Designs, codes  and tests the program.
• Writes its documentation.

He needs to have 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.

The copilot

He is the alter ego of the surgeon, able to do any part of the job, but is less experienced.
His main responsibilities are:

• Shares in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.
• Knows all the code intimately.
• Researches alternative design strategies.

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. He can serve two teams.

The editor.

The surgeon is responsible for generating the documentation; for maximum clarity he must write it. This 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 mechanics 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.

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.

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 sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team.

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, catalogued 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 the 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 very 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 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.

How It Works

The team just defined meets the desiderata in several ways.
Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind—or at most two, acting uno animo.

Notice in particular the differences between a team of two programmers conventionally organized and the surgeon-copilot team.

• First, in the 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. This saves the labor of allocating space, disk accesses, etc. It also ensures the conceptual integrity of the work.
• 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—e.g., whose space will be used for a buffer. In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally.

These two differences—lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo. Yet the specialization of function of the remainder of the team is the key to its efficiency, for it permits a radically simpler communication pattern among the members.