03. The Surgical Team

Dated Oct 1, 1974; last modified on Sun, 12 Feb 2023

The Dilemma

There are wide productivity variations between good programmers and poor ones. Sackman et. al. found 10:1 ratios. The data showed no correlation between experience and performance.

The idea of a 10x developer is mostly ridiculed in my online circles. That said, some jobs have X years of experience as a requirement. How can we resolve these contradictions?

The major part of the cost of large teams is communication, and system debugging to correct the ill effects of miscommunication.

A small (\(\le 10\)) sharp team, good as it may be, is too slow for really big systems.

We have probably come a long way from what Brooks was referring to as a big system. Tools like version control, CI, and libraries greatly enhance what a small sharp team can achieve.

The dilemma is thus: for efficiency and conceptual integrity, a few good minds should do design and construction; for large systems to be timely completed, one needs to incorporate a considerable workforce.

Harlan Mills’s Proposal: The Surgical Team

Instead of each member cutting away on the problem, one does the cutting, and the others give support.

The surgeon (chief programmer) personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes documentation.

The copilot, somewhat less experienced than the surgeon, shares in the design as a thinker, discussant, and evaluator. They know all the code intimately, and represents the team in discussions of function and interface with other teams.

The administrator handles money, people, space, and machines on behalf of the surgeon, who has the last word. They also interface with the administrative machinery of the rest of the organization.

The editor takes the docs drafted by the surgeon and critics it, rewrites it, cites and references it, and oversees the mechanics of its production.

Some teams (e.g. Chromium ) integrate the docs into the code base.

Other teams embed docs within the source files. Such embedded docs might then be parsed by a documentation generator and built into a site (e.g. ), or the source code itself may be made navigable (e.g. ).

In either case, the docs are part of the code base, and go through review in the same pipeline as the source files.

The administrator and the editor each has a secretary who handles project correspondence and non-product files.

The program clerk maintains the team’s technical (machine-readable and human-readable) records in a programming-product library. All computer runs should be visible to all team members, and the artifacts are a team property.

Version control combined with continuous integration pipelines have redefined the clerk’s role. I store the source code in Git, and CI pipelines build and store the resulting artifacts.

The toolsmith ensures tools (e.g. editors, debuggers) are adequate, as per the surgeon’s requests. They often construct specialized utilities, catalogued procedures, macro libraries, and so forth.

Would this be the current-day “Engineering Systems” team that is responsible for tooling?

The tester devises test cases from functional specs, and devises test data for day-by-day debugging. They also plan testing sequences and set up scaffolding required for component tests.

Some companies (e.g. Microsoft ) do not have a dedicated tester role. Instead, developers are responsible for writing [automated] tests. Testers now test full-on programs without getting into its implementation.

The language lawyer delights in the intricacies of the programming language (unlike the surgeon who is primarily a system designer), and finds neat and efficient ways to use the language.

How It Works

Of the ten people, seven of them work on the problem, but the system is a product of one mind - or at most two, acting uno animo.

In a team of equal partners, differences of judgment must be talked out or compromised, while in the surgical team, the surgeon settles differences unilaterally.

Some teams have a “Benevolent Dictator for Life” (BDFL) who has the final say.

references the Homesteading the Noosphere article, which expounds on the “benevolent dictator” in open-source communities.

The specialization of function permits a radically simpler communication pattern:

Communication pattern in the surgical team. Source: Brooks, 1974.
Communication pattern in the surgical team. Source: Brooks, 1974.

References

  1. The Mythical Man-Month: Essays on Software Engineering. 03. The Surgical Team. Brooks, Jr., Frederick P. Oct 1, 1974. ISBN: 0201006502 .
  2. How Microsoft dragged its development practices into the 21st century. arstechnica.com . Aug 5, 2014. Accessed May 26, 2022.
  3. docs - chromium/src.git - Git at Google. chromium.googlesource.com . Accessed May 26, 2022.
  4. How to Write Doc Comments for the Javadoc Tool. www.oracle.com . en.wikipedia.org . Accessed May 26, 2022.
  5. Code Search | Google Developers. developers.google.com . Accessed May 26, 2022.
  6. Kythe. kythe.io . Accessed May 26, 2022.
  7. Benevolent dictator for life. en.wikipedia.org . Accessed May 26, 2022.